[csw-maintainers] Fwd: git svn push, git dcommit leads to commit duplication?

[rupert THURNER]

for the interest of the ones using git as client and want to update both,
git, and svn: first dcommit to svn to enrich with svn information, then push
everything to the git server.

a little bit background info how i got in this situation:
i did it the other way round, i.e. push first to github, then dcommit to
svn. i ended up having duplicate commits, one with svn info, and one
without, locally. the effect was that i could not push any more to github
(without forcing it though). i removed the surplus commits from github via
  git reset --hard <commit-id>
hoping nobody of you pulled them beforehand.

rupert.

---------- Forwarded message ----------
From: Thomas Rast <trast at student.ethz.ch>
Date: Thu, Jul 21, 2011 at 12:25
Subject: Re: git svn push, git dcommit leads to commit duplication?
To: rupert THURNER <rupert.thurner at gmail.com>
Cc: git at vger.kernel.org


rupert THURNER wrote:
> we keep a svn clone of
> https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg on
> https://github.com/opencsw/pkg-all . usually i synchronize it with
> "git svn rebase" and "git push" from a local clone created with "git
> svn clone https://gar.svn.sourceforge.net/svnroot/gar/csw/mgar/pkg".
>
> last time i changed something in this local clone and pushed it to
> github, and commited it to sourceforge via git svn dcommit. now the
> commits are there two times, different. my guess was that dcommit
> would add the svn related stuff to the existing git commits. what is
> the correct usage to keep svn and git in sync?

Your guess is mostly correct.  To best understand what is going on,
keep in mind that "you can never modify, you can only rewrite and
forget"[1].

Suppose you say 'git svn dcommit' on history that looks like

 1---2---3--(4)--(5)    SVN

 o---o---o    (svn/trunk)
          \
           a---b---c   (master)

where 4 and 5 are commits not yet fetched from SVN (if any).


1. git-svn will first fetch the new SVN history, let's call them N:

    1---2---3---4---5    SVN

    o---o---o---N---N    (svn/trunk)
             \
              a---b---c   (master)

2. Then it will rebase your own work on top of the new SVN stuff:

    1---2---3---4---5    SVN

    o---o---o---N---N    (svn/trunk)
             \
              a---b---c   (master)


3. Then it will rebase your own work on top of the new SVN stuff:

    1---2---3---4---5    SVN

    o---o---o---N---N    (svn/trunk)
                     \
                      a'--b'--c'   (master)

4. Then it will commit all of that to SVN:

    1---2---3---4---5---6---7---8    SVN

    o---o---o---N---N    (svn/trunk)
                     \
                      a'--b'--c'   (master)

5. Then it will annotate your commits o' with the info coming back
  from SVN (such as author, etc.) and "replace" your master with it:

    1---2---3---4---5---6---7---8    SVN

    o---o---o---N---N---A---B---C    (svn/trunk, master)

  From the point of view of 'master', this is also much like a
  rebase, except that authors and timestamps change too and (unless
  disabled) git-svn-id: lines appear in your commit messages.


Does that clarify what happens?

[For the sake of completeness, I should point out that this is a
simplification.  Steps 3--5 are actually all done in one go *per
commit*, and step 3 does not use 'git-rebase' but a variant on the
theme that preserves merges of side branches.]


As for

> what is the correct usage to keep svn and git in sync?

the only way I know of that avoids constantly rebasing branches is to
never push anything before it has been dcommitted.


[1] Quoting Tv; he said it much better than I can.

--
Thomas Rast
trast@{inf,student}.ethz.ch
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opencsw.org/pipermail/maintainers/attachments/20110721/187757af/attachment.html>