[LLVMdev] git

[jo at durchholz.org]

> - git allows easy backtracking of decision points, allowing one to
>   explore a line of development and then reformulate the set of commits
>   made before actually sending them upstream to master.  For me, it is
>   more helpful to be able to just code up a feature and once it's
>   working, go back and break out the individual patch sets into logical
>   groups.  I tend to poorly anticipate how a feature/fix should be
>   presented to upstream before I've actually implemented it.  git
>   decouples those two activities.

This is actually one of the major points why I'm in the process of moving
my own (LLVM-unrelated) development process from svn to git.

Currently, I tend to break out small incremental changes to they're easier
to review, but this works only up to a certain point.
What happens is that I find I need some "enabler" change. Adding a data
structure to carry enough context to the place where my new code needs it.
The other thing is "sideline work": while reviewing code for my change, I
find something unrelated that should really be fixed right away.
Low-hanging fruit and such.
I commit enablers and sideline changes, but I find I can't do so if there
is already main-task work done in that file.

With git, I can single out individual changes in a file and send them off
as a preparatory commit.
With SVN, I have to set up a separate workdir, start the IDE, do the
change, and commit it; then merge it back into my mainline workdir. That's
so much more work that it disrupts the flow of work, so I don't do it and
end with a jumble of unrelated changes in a single patch.
Anybody I'd be sending the patch to would probably reject it as "too many
unrelated changes". I'd probably end up redoing any change twice: once
just to get a clean base, then doing it "right" as a series of
individually applicable small patches.
Which is raising the entry barrier for contributing to LLVM considerably.
At least for people with a workflow similar to mine.