Re: git pull on Linux/ACPI release tree

[Junio C Hamano <junkio@cox.net>]

Linus Torvalds <torvalds@osdl.org> writes:

> One thing we could do is to make it easier to apply a patch to a 
> _non_current_ branch.
>...
> And one way to do that might be to teach "git-apply" to apply patches to a 
> non-active branch,...
>
> 	git diff | git-apply -b development
>
> or something similar..)
>
> Then you could always do "git pull . development" to pull in the 
> development stuff into your working branch - keeping the development 
> branch clean all the time.

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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/