[Bf-committers] Git issues and workarounds

[Sergey Sharybin]

Accidents with staging wrong files might always happen, even if you always
staging files manually with `git add path/to/file`.

The things is, while i agree `git commit -a` is not the best thing to do,
`git commit .` is not better in any respect. If you really want to prevent
accidents from happening, stage files individually with `git add`.

For now (and the is the keyword, read: for until git stages changes to
ignored submodules with `git add .`) i would strongly recommend not use
`git commit .` and `git add .`. Using `git commit -a` is safer from the
respect of keeping repository in a consistent state (no unwanted changes to
submodules).

This is the main purpose for now and please stop threads like "in an ideal
world you should not use A and you should use B instead". World is not
ideal and such a suggestions will confuse people even more, giving us more
unwanted accidents.

Can we agree on this and go back to work?


On Wed, Nov 27, 2013 at 4:14 AM, Julien RIVAUD (_FrnchFrgg_) <
frnchfrgg at free.fr> wrote:

> Le 26/11/2013 22:25, GSR a écrit :
> > Was 50fbebe0 done with "git commit -a"? That explains 780459e4. ;) It
> > was just cosmetic, but other errors can be compile breaking (half
> > edited files with true syntax errors, eg), and in any case, using
> > something like git, there is no reason for such noise. There is a need
> > to "change gears" and use the tools with more precision. There are
> > status, diff, log, --amend, "squash"... to check and solve issues
> > before pushing.
> I totally agree with that; it is time to learn how to take advantage of
> the "commit != publish" specificity of distributed VCSs to author high
> quality commits. When we converted the SVN history from git we fixed a
> lot of commit series where all but the first were to (incrementally)
> correct mistakes found in the first commit. The hope was that with git
> such mistakes should happen a lot less, not because people get it right
> the first time, but because they can look at their commit *after doing
> them* but before it is too late to fix them.
>
> We need to make blender devs learn not to commit + push in the same
> breath. You can have your work wait even a day or two in your repository
> before pushing, as long as they are committed you won't mix all your
> changes in a single commit.
>
> The COMMIT OFTEN adage hasn't ever been more true, but it doesn't equate
> to "push often".
>
> git commit --amend is your friend, and even more is git rebase
> --interactive origin/master
>
> For instance: you write a small change, then commit it (commit A). Then
> you make another unrelated change that you also commit (commit B,
> because you have a healthy commit habit). And now you find a mistake in
> your first change !
> No problem: write the fix, and commit it (commit C). Your history is now:
>
> X --- A --- B --- C <- master is here (where X is last commit on
> origin/master)
>
> When you do git rebase --interactive origin/master, git will open an
> editor, allowing you to reorder your commits, and even to ask that C's
> changes are integrated into A, so that your history now looks:
>
> X --- A' --- B' <- master
>
> where A' has changes of A and C, and B' is just B (but its SHA1 changed
> due to the way git works)
>
> That enables pushing high quality commits. You can even use that to
> write a feature with history that matches your train of thought and your
> mistakes and progressive understanding... When it's time to integrate
> into blender, you rewrite the series so that it appears that your
> changes are all smart with a vision, with seemingly small
> non-controversial changes but whose cumulative effect amount to a total
> rewrite. In short, you can pretend you are a smart guy that never
> wandered and found from the beginning the best way to gradually
> introduce a disruptive change so that it is smooth instead.
>
> That is good; if people reading blender history think of you that you
> are geniuses who never fail, you'll have less regressions, easier
> bisecting because all commits compile, etc...
>
> ALSO, git has a specificity that you don't find in other VCSs (or not as
> good anyway): the staging area (a.k.a. the index); you can have a lot of
> changes in your working directory, but only commit parts of them.
>
> "git add -p" is almost as good a friend as "git rebase -i"
>
> It will present you with patch hunks of all changes in your work dir,
> and you can select those that are relevant to your next commit. A good
> way to write and commit a small fix while you were writing a feature.
>
>
> _FrnchFrgg_
>
>
> P.S: Sorry for the huge mail
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
>



-- 
With best regards, Sergey Sharybin