[LLVMdev] git Status Update?

[David A. Greene]

Francois Pichet <pichet2000 at gmail.com> writes:

>> Because you're missing so much.
>
> I am not very familiar with GIT so I have a question:
> Let's say I don't fork and I work 1 patch at the time. Then what are
> the advantages of GIT over svn?

Yes, the previous response was a bit too pithy.

You _do_ want to fork with git, in the sense of cloning a repository and
creating local branches.  It requires a small shift in development
mindset but that shift will keep things much more organized, IME.

Here's a set of notes I've collected over the last year as I've
experienced using git in a production environment:

Places git can improve svn process
----------------------------------
Day-to-day development

  - local branches allow developers to share code before committing
    it to the main repository.  Work groups can make progress without
    impacting others.

  - local branches allow feature development and proper source code
    change tracking without impacting others.  One can develop the
    feature naturally, take wrong paths, etc. without worry.

  - git rebase -i allows the developer to clean up history on a branch
    (to account for mistakes, backtracks, etc.) before it goes into
    the main history.

  - The stash model makes it trivial to work in an interrupted state.
    It is common to be working on a project only to have a critical bug
    come in that needs immediately attention.  git has full support for
    suspending current work and restarting it after the interruption.

Pulling code from upstream

  - git is by nature distributed.  It is designed to share code in
    this manner.  A git pull does all of the proper merging and
    conflict identification and makes all of the upstream history
    available to the developer.

  - Having upstream history makes it possible to back out individual
    changes after a pull to do regression isolation, etc. on
    third-party code.

Sending Code to upstream

  - git aids the review process with git format-patch, git send-email

  - Restructuring patches is easy-ish with git-rebase -i (split,
    squash, reorder, fixup, etc.).

Debugging/Release

  - git's ability to track which changes are in one branch but not
    another is useful for making sure all changes to be pushed into
    release actually made it there.

I believe all of these are benefits in the environment you describe.
There are even more benefits if you want to keep a private/modified
version of LLVM (or any project) separate from the official one.  This
is in fact that the LLVM license encourages so it's a natural fit to use
an SCM that directly supports that model.

                                 -Dave