Re: [PATCH] Don't create the $GIT_DIR/branches directory on init

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

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