Re: git pull on Linux/ACPI release tree

Linus Torvalds <torvalds@osdl.org> writes:

I had to do something like that last night, when I hacked on gitweb. gitweb as shipped does not work for anybody but kay (e.g. it has /home/kay hardcoded in it). So I did:

	$ git clone git://git.kernel.org/pub/scm/git/gitweb gitweb
        $ cd gitweb
        $ git checkout -b custom
        $ edit gitweb.cgi ;# adjust /home/kay -> somewhere else etc.
        $ git commit -a -m "customization for junio's home"

Then I started preparing a proposed fix for Kay:

	$ git checkout -b symref master
        $ edit gitweb.cgi
        $ git commit -a -s -m "make it work on symref repository"

Now the thing is that I cannot test symref branch as is. I deliberately omitted the change necessary to make the upstream work on my local machine from that branch, because I want to keep my home-machine customization separate from what I will eventually feed Kay. So I do a throwaway test branch:

	$ git checkout -b test master
        $ git pull . custom symref ;# an octopus ;-)
        # I could have done two separate pulls, custom then symref.

The interesting part starts here. Inevitably, I find bugs and bugs and bugs in the test branch, and I fix them in the working tree, without committing. Eventually things starts working. I did not commit here in the test branch, because the symref branch is where I intend to keep this set of changes. So instead, I did this:

	$ git diff HEAD >P.diff
        $ git checkout -f symref
        $ git reset --soft HEAD^
        $ git apply P.diff
        $ git commit -a -C ORIG_HEAD

Usually I strongly discourage people to use "checkout -f" because it will leave files that are in the current branch but not in the new branch behind in the working tree. Here I used "checkout -f symref" because I knew this is a one-file project.

Instead of fixing the symref commit in place like this, I could have committed P.diff as a separate "fixup" commit on top of the symref branch, in which case the above sequence would have been:

	$ git diff HEAD >P.diff
        $ git checkout -f symref
        $ git apply P.diff
        $ git commit -a -m 'fixup bugs in the previous.'

but I did not --- it would have been more disgusting than honest.

And after that, the usual format-patch:

	$ git format-patch origin..symref

In either case, this *was* cumbersome. And I did it twice for two independent topics. Admittedly, these topic branches were both single-commit topics, and in real life your subsystem maintainers must be facing bigger mess than this toy experience of mine, but the principle is the same.

I think there are a couple of ways to improve what I had to do. I'll think aloud here. The fictitious transcripts all start after I got things working in the test branch working tree, with a clean index file (i.e. changes are in the working tree only).

1. Make a commit in the "test" branch, and then cherry-pick the
   commit back to the topic branch:

	$ git commit -a -m "Fix symref fix"
        $ git checkout symref
        $ git cherry-pick -r test

2. Fix "git checkout <branch>" so that it does a reasonable thing
   even when a dirty path is different in current HEAD and
   destination branch.  Then I could:

	$ git checkout symref ;# this would not work in the current git
	    # it would die like this:
            # $ git checkout symref
            # fatal: Entry 'gitweb.cgi' not uptodate. Cannot merge.
	$ git diff ;# just to make sure inevitable automated merge
		    # did the right thing
        $ git commit -a -m "Fix symref fix"
	    # I could collapse them into one instead, like this:
	    # $ git reset --soft HEAD^
	    # $ git commit -a -C ORIG_HEAD

To retest (possibly with latest from Kay), we can rebuild the test branch from scratch since it is by definition a throwaway branch and never is exposed to public:

        $ git fetch origin
	$ git checkout test
        $ git reset --head origin
        $ git pull . custom symref

Obviously I prefer to have #2 work well, but #1 would work today.

I am not sure if making "git-apply" to take different branch is a sane approach. It might make sense to teach git-applymbox and git-am about branches, though. So is teaching git-merge about merging into different branch.