[LLVMdev] git

David A. Greene greened at obbligato.org
Thu Jul 28 15:35:01 PDT 2011

Jason Kim <jasonwkim at google.com> writes:

> On Wed, Jul 27, 2011 at 8:59 PM, Mark Lacey <641 at rudkx.com> wrote:
>         Besides, the git-svn readonly bridge is a great solution for those who want to use git
>       It seems to be a reasonable solution for those individuals who
>     want to use git, but in my experience not for organizations that
>     want to use git, e.g. have a local server with local branches,
>     with many people banging on that while at the same time
>     continuously merging the LLVM mainline in.
>     Perhaps your experience has been different - I have limited
>     experience with git-svn and git-p4, but have found both to be
>     useful only for me working individually.
>     Mark
> Have you considered mercurial?
> I am not as "current" on git wizardry as I am on mercurial, but at I
> least verified that branched development and rebasing to tip, r-w-
> works on the mercurial-svn bridge (i.e. you can commit directly to svn
> via hg and gain all of the benefits of using a dvcs)

git-svn allows commits to svn directly from git.  But you need to make
sure the history in the branch you dcommit from is "linear."  As you
say, a rebase is always necessary while with "normal" git it is

The practical consequence of this is that the developer has to keep some
sort of special "upstream" branch that only takes merges from other git
branches and always does a rebase against the current upstream svn.
That rebase should NEVER be made public to other users of the git mirror
(or any clones) for the same reasons that rebases should never be done
against publicly-visible changes.

In addition, the dcommit produces a history divorced from that in the
git mirror because by definition the hash produced in the git-svn mirror
is different from the hash produced when you committed the change
locally.  This is so because you had to do a rebase before the dcommit.
Thus on subsequent updates from master, it is not unusual to see
conflicts in code you just dcommitted.

I don't know whether Mercurial handles this better but I don't see how
it possibly could given svn's limitations.  But then I am a DVCS newbie.


More information about the llvm-dev mailing list