Re: git-svn and repository hierarchy?

On Thu, Mar 05, 2009 at 02:48:14PM -0500, Peter Harris wrote:

On Thu, Mar 5, 2009 at 1:05 PM, Josef Wolf wrote:

quoted

Well, actually it allows the changes for a very limited user group (that
is: only me 8-).  While I agree that author/date should not be changed,
I like to be able to fix silly typos in the log.  After all, we all do
typos now and then ;-)

True, but in my experience it happens considerably less often with
git. I find and fix most of my typos when reviewing my change-set
before doing a "git push" or "git svn dcommit".

So you are rewriting yourself but not accept rewrites by svn ;-)

quoted

Maybe there's room for more improvement:  Since the merge is done on a
scratch branch anyway, why not letting the clones _push_ into branches
with random names: cloneX-`uuidgen` or something.  So the clones could
do the push whenever they have net access.  The actual merge can be done
completely decoupled from the push operation.

Indeed. Or even not-so-random names, such as cloneX/topic-name if you
prefer.

That would have the risk of multiple clones pushing to the same branch.
I am not sure I am prepared to resolve such conflicts (yet).  But you
are right, the branch name should contain the topic-name.  So here's my
current favorite of the workflow:


     # work on clone
     #
     (
       cd clone$clone

       # first move commits from subversion to clone
       #
       git checkout master
       git pull --rebase

       # do some work
       #
       git checkout -b topic-branch
       for commit in 1 2 3; do
         echo change $clone $commit >>test
         git commit -a -m "commit $clone $commit"
       done

       # push the work
       #
       git push ../git-svn-repos topic-branch:clone-topic-branch-`uuidgen`
       git checkout master
       git branch -D topic-branch
     )



     # Integrate commits from clones an move them to subversion
     #
     (
       cd git-svn-repos
       for scratch in `git branch | grep ' clone-'` ; do

         # merge client's work
         #
         git checkout $scratch
         git svn rebase trunk

         # resolve possible conflicts
         #
         grep change test >test.resolved
         if diff test test.resolved ; then
             rm test.resolved
         else
             mv test.resolved test
             git add test
             git commit -m "merge"
             git rebase --skip
         fi

         # sync with svn repository
         #
         git svn dcommit
         git checkout master
         git svn rebase -l     # fast-forward master to where scratch is

         # clean up
         #
         git branch -d $scratch
       done
      )



Does that look sane?

The benefit is that work on clones and work on git-svn-repos is
decoupled.