[Bf-committers] Git issues and workarounds

[Julien RIVAUD (_FrnchFrgg_)]

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