[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH] Don't create the $GIT_DIR/branches directory on init
From:       Junio C Hamano <gitster () pobox ! com>
Date:       2009-10-31 19:32:40
Message-ID: 7vmy377413.fsf () alter ! siamese ! dyndns ! org
[Download RAW message or body]

"Shawn O. Pearce" <spearce@spearce.org> writes:

>> This patch alone breaks tests in the t55?? series quite a lot,
>
> Drop the patch.

Ok, I missed that the unstated goal was "we will eventually drop support
for reading from branches and remotes".  I think it is a worthy goal, but
also agree that should be done at 1.7.0 or 1.8.0 boundary.

If this were Andrew alone, I personally do not think it is such a big
deal.  My understanding is that an eventual goal over there in the kernel
land is to grow 'linux-next' tree even more so that akpm tree will shrink
in the longer term, anyway.  I consulted Andrew in early days while he was
fighting with git to get his scripts to do what he needs them to do, and I
can do that again to bring them up-to-date if necessary.

In order to better support "massive integrator" workflow
that involves interacting with dozens of remote branches, we need to admit
that some of the things you can do if you are set up like Andrew are less
convenient to do via "git remotes" managing .git/config file.  E.g.

    : add new
    $ echo "$korg:/home/rmk/linux-2.6-arm.git#master" >.git/branches/arm-current
    : remove stale
    $ rm -f .git/branches/powerpc
    : find source
    $ grep -r $something .git/branches
    : make random small changes, e.g. change branch name only
    $ vi .git/branches/sparc

and we _might_ need to improve "git remote" interface before dropping
support for reading branches and remotes files.

Admittedly, managing integration trees like -mm and linux-next needs not
just nickname-to-repo-branch mapping but also involves the correct merge
order anyway, and people like Andrew and Stephan Rothwell (linux-next)
maintain a text file to describe them that git does not know about.

E.g. http://linux.f-seidel.de/linux-next/pmwiki/pmwiki.php?n=Linux-next.IncludedTrees

We do not have any infrastructure support for that kind of thing.

To manage 'pu' and 'next', I use specialized scripts (in my 'todo' branch,
look for Reintegrate script) myself, even though the number of topics I
manage is far smaller than what we are discussing here[*1*].  In that
sense, the difference between the remotes sections in .git/config file and
.git/branches/* files is not such a big issue in the larger picture.

As long as we keep the UI to deal with bare URL and branch names from the
command line properly working, the "massive intergrator" workflow might be
better done without _any_ remote definition, either in the config nor
branches/remotes files.  Two integrator scripts might read like these:

	#!/bin/sh
	# fetch-all script
        # fetch from repositories
        failed=
	while read nickname url branch
        do
        	git fetch -q "$url" "+$branch:refs/remotes/$nickname" ||
		failed="$failed$nickname "
	done <merge-order
        test -z "$failed" ||
        echo "Failed to fetch from $failed"

        #!/bin/sh
	# merge-all script
	# git reset --hard remotes/linus-tip
        while read nickname url branch
        do
        	git merge -m "Merge from $url#$branch" "remotes/$nickname" ||
		accept_rerere ||
                break
	done <merge-order

where accept_rerere is something like what my Reintegrate script (in
'todo' branch) has in it.  Then the workflow for the integrator would
become:

  1. to run "fetch-all" once;
  2. reset to Linus's tip of the day;
  3. run "merge-all";
     3.a fix up conflicts;
	 edit && git commit
     3.b decide to drop the day's tree and use previous day's:
	 git reset --hard &&
         git update-ref refs/remotes/$nick refs/remotes/$nick@{1.day}
     3.c decide to drop the tree:
	 git reset --hard &&
         edit merge-order
     and go back to step 3.


[Footnote]

*1* I do not keep a "merge order" file, but existing merges on 'pu' for
that purpose.  The Reintegrate script figures it out by looking at what
was in 'pu'.  One cycle of my git day looks like this, in this order:

    : record what topics are in 'next' and 'pu'
    : 'jch' is a shadow of 'next' that merges all the topics in 'next'
    : on top of 'master'.
    $ Meta/Reintegrate master..jch >/var/tmp/redo-jch.sh
    $ Meta/Reintegrate jch..pu >/var/tmp/redo-pu.sh

    : queue a new topic
    $ git checkout -b xx/topic master
    $ git am -s $patch

    : update a topic
    $ git checkout xx/topic
    $ git am -s $patch

    : fix a topic (that is not in 'next' yet)
    $ git checkout xx/topic
    $ git rebase -i $(git merge-base master HEAD)

    : decide to graduate a topic to 'master'
    $ git checkout master
    $ git merge xx/topic

    : apply directly to master
    $ git checkout master
    $ git am -s $patch

    : update 'next' with what's new in 'master'
    $ git checkout next && git merge master
    : rebuild 'jch' (shadow of 'next')
    $ git branch -f jch master && git checkout jch
    $ sh /var/tmp/redo-jch.sh
    : at this point, 'jch' and 'next' must exactly match

    : add topics that are next-ready to 'jch' and test
    $ git merge xx/topic

    : merge them to 'next' as well
    $ Meta/Reintegrate master..jch >/var/tmp/redo-jch.sh
    $ git checkout next && sh /var/tmp/redo-jch.sh
    : at this point, 'jch' and 'next' must exactly match

    : rebuild 'pu'
    $ git branch -f pu jch && git checkout pu
    $ sh /var/tmp/redo-pu.sh
    : merge new topics
    $ git merge xx/topic
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]