From: Junio C Hamano <junkio@cox.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: "Brown, Len" <len.brown@intel.com>,
"Luck, Tony" <tony.luck@intel.com>,
Martin Langhoff <martin.langhoff@gmail.com>,
"David S. Miller" <davem@davemloft.net>,
linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org,
akpm@osdl.org, git@vger.kernel.org
Subject: Re: git pull on Linux/ACPI release tree
Date: Mon, 09 Jan 2006 12:06:50 -0800 [thread overview]
Message-ID: <7vu0cdjhd1.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0601090835580.3169@g5.osdl.org> (Linus Torvalds's message of "Mon, 9 Jan 2006 08:47:39 -0800 (PST)")
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.
next prev parent reply other threads:[~2006-01-09 20:06 UTC|newest]
Thread overview: 59+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-01-09 8:05 git pull on Linux/ACPI release tree Brown, Len
2006-01-09 16:47 ` Linus Torvalds
2006-01-09 16:57 ` Linus Torvalds
2006-01-09 22:51 ` Luben Tuikov
2006-01-09 23:07 ` Linus Torvalds
2006-01-09 23:34 ` Martin Langhoff
2006-01-10 2:50 ` Linus Torvalds
2006-01-10 6:33 ` Kyle Moffett
2006-01-10 6:38 ` Martin Langhoff
2006-01-10 18:05 ` Kyle Moffett
2006-01-10 18:27 ` Linus Torvalds
2006-01-10 18:45 ` Johannes Schindelin
2006-01-10 19:01 ` Linus Torvalds
2006-01-10 19:28 ` Linus Torvalds
2006-01-13 23:35 ` Matthias Urlichs
2006-01-11 3:32 ` Luben Tuikov
2006-01-09 20:06 ` Junio C Hamano [this message]
2006-01-10 15:31 ` Alex Riesen
-- strict thread matches above, loose matches on Subject: below --
2006-01-09 7:34 Brown, Len
2006-01-09 10:11 ` Martin Langhoff
2006-01-09 12:31 ` Johannes Schindelin
2006-01-09 6:27 Brown, Len
2006-01-09 6:13 Brown, Len
2006-01-09 5:55 linux
2006-01-09 5:53 Brown, Len
2006-01-09 6:08 ` Martin Langhoff
2006-01-09 6:13 ` Linus Torvalds
2006-01-09 6:46 ` Junio C Hamano
2006-01-08 18:28 Brown, Len
2006-01-08 19:19 ` Martin Langhoff
2006-01-08 19:33 ` Junio C Hamano
2006-01-08 19:57 ` Linus Torvalds
2006-01-08 20:50 ` Tony Luck
2006-01-08 19:56 ` Linus Torvalds
2006-01-08 20:35 ` David S. Miller
2006-01-08 21:20 ` Luben Tuikov
2006-01-09 1:13 ` Linus Torvalds
2006-01-08 19:41 ` Linus Torvalds
2006-01-08 23:06 ` Adrian Bunk
2006-01-08 23:53 ` Willy Tarreau
2006-01-09 3:26 ` Linus Torvalds
2006-01-09 4:34 ` Martin Langhoff
2006-01-10 20:19 ` Adrian Bunk
2006-01-10 20:31 ` Linus Torvalds
2006-01-10 20:33 ` Martin Langhoff
2006-01-12 1:37 ` Greg KH
2006-01-12 16:10 ` Catalin Marinas
2006-01-13 14:50 ` Adrian Bunk
2006-01-08 7:47 Brown, Len
2006-01-08 8:16 ` Catalin Marinas
2006-01-08 8:16 ` David S. Miller
2006-01-08 19:10 ` Linus Torvalds
2006-01-09 0:48 ` Al Viro
2006-01-09 3:50 ` Linus Torvalds
2005-12-01 8:05 Len Brown
2005-12-06 8:17 ` Len Brown
2005-12-23 5:42 ` Len Brown
2006-01-07 15:54 ` Len Brown
2006-01-07 18:22 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vu0cdjhd1.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=akpm@osdl.org \
--cc=davem@davemloft.net \
--cc=git@vger.kernel.org \
--cc=len.brown@intel.com \
--cc=linux-acpi@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=martin.langhoff@gmail.com \
--cc=tony.luck@intel.com \
--cc=torvalds@osdl.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).