12 Matching Annotations
  1. Sep 2017
    1. Other popularattempts include GitHub’s desktop client8, legit9, and Easy-Git10.

      Clientes como o SourceTree muitas vezes possuem opção de verbose para mostrar os comandas que estão executando e isto é extremamente positivo para aprender a usar melhor o git.

    2. Gitless has no staging are

      Que horrível. Isso só incentiva as pessoas fazerem commit de tudo indiscriminadamente, criando problemas. Fora dificultar você fazer pequenas mudanças que não são agrupáveis em um único commit[, mas que podem ser feitas num mesmo passo de um fluxo de trabalho] em paralelo.

    3. The workaround is to add a token file in eachdirectory, which will allow you to create a commit with yourdirectory structure, and then push it so that your collaboratorscan see it

      Poderia ter um .gitdirectories similar ao .gitignore a fim de forçar a criação de diretórios vazios? Acho que seria uma solução mais elegante da comumente usada citada pelo autor (de se criar arquivos escondidos ".gitkeep").

    4. Suppose there’s a database configurationfile committed in the repository and you now want to editthis file to do some local testing. This new version of thefile should not be committed.

      Por que você gostaria de esconder que isto está no seu working directory? Provavelmente a resposta seria que você estaria usando o git de forma errada. Versionando código de aplicação e configuração juntos. Então ao invés de fazer uma gambiarra o correto seria separar as duas coisas. Dificilmente você vai querer ter algo com 'assumed unchanged' se fizer esta separação corretamente.

      Eu diria que o fato de ficar aparecendo na lista do status do working directory é bem vindo neste caso, pois força você a fazer a coisa certa.

    5. How would you do that?

      git stash save --keep-index

      Difícil lembrar de usar isso na prática...

    6. File TrackingSuppose you create a new file and then youadd the file to start tracking changes to it. You keep workingon the file making new modifications and then you makea vanillacommit. You might be surprised to find out thatwhat actually got committed is the old version of the file(representing its state the last time the file was staged), andnot the most recent one

      Comportamento esperado. Fazer o contrário seria perigoso. Você poderia perder informação. No mais, você quer track de linhas e ver cada coisa que entra ou não em um commit, não de arquivos em seu último estado[, seja ele qual for].

    7. To workaround this, you have to be diligent about creating a commitwith the rename only, and only then creating a new commitwith the modifications. This, however, likely creates a boguscommit that doesn’t correspond to a logical group of changes.

      Isso é difícil de resolver. Eu fazia isso que o autor faz sempre, apesar de hoje em dia fazer menos, visto que no pior caso você pode verificar o histórico passado (não se perde o histórico, como o autor diz; só fica mais difícil ver) e, se as mudanças forem tão grandes talvez seja melhor mesmo uma mudança em partes.

    8. You might be surprised to discover that these newcommits you’ve been working on belong to no branch at all.To avoid losing them you need to create a new branch or resetan existing one to point to the last commit

      Como esperado. A pessoa deveria estar trabalhando numa branch, não em cima de um commit.

      Se as mudanças nunca foram publicadas, a pessoa pode fazer um reset. Se já foram, o adequado é fazer um revert para reverter as mudanças. Se o git bloqueasse isso outros problemas apareceriam.

    9. Alter-natively, you can use stashing to save your changes, but whenusing multiple branches it becomes difficult to remember andapply the stash that corresponds to the branch you want.

      This is a common issue given that the most basic commands "git stash" and "git stash pop" doesn't show the power "git stash" offers, and so many people don't realize it is a list you can access randomly.

    10. Unlike abranch, however, a tag does not get spontaneously updatedoncommit.

      Indeed. They are pointers to commits. And any published tag SHOULD NOT be updated.

  2. Aug 2017
    1. In addition, each merge commit has two parents — here wecall them left and right revision

      Incorrect. You can have more parents on a merge commit if using a git octopus strategy.

      https://git-scm.com/docs/merge-strategies#merge-strategies-octopus

    2. For example, when different developers make changes to thesame artefact without being aware of the other changes —the so-calleddirectortextualconflicts — or when there areconcurrent modifications in different artefacts, leading to buildor test failures — theindirectconflicts [2, 3].

      There is no indication on the text about what an artifact is.