Re: n-heads and patch dependency chains
- From
Andreas Ericsson <ae@op5.se>
- Date
- Apr 21, 2006, 08:50 UTC
- Message-ID
- <44489CE4.1050101@op5.se>
- In-Reply-To
- <7v4q0oyt3w.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
Show 32 quoted lines
> Jon Loeliger <jdl@freescale.com> writes: > > >>On Tue, 2006-04-04 at 06:47, Andreas Ericsson wrote: >> >> >>>No, I mean that this would commit both to the testing branch (being the >>>result of several merged topic-branches) and to the topic-branch merged >>>in. Commit as in regular commit, with a commit-message and a patch. The >>>resulting repository would be the exact same as if the change was >>>committed only to the topic-branch and then cherry-picked on to the >>>testing-branch. > > > To be consistent, I think the result should be "as if the change > was commited only to the topic-branch and then the topic-branch > was *merged* into the testing-branch", since you start your > testing branch as "being the result of several merged topic-branches". > > I do that (manually) all the time, with: > > $ git checkout next > $ hack hack hack > > $ git checkout -m one/topic > $ git commit -o this-path that-path > $ git checkout next > $ git pull . one/topic > > Giving a short-hand for the last four-command sequence would > certainly be nice. >
Ah. That's easier than what I originally looked at doing.
Show 8 quoted lines
> >>I am your number one fan! If I finish reading these 600+ >>messages, will I find out you have already implemented it, >>it's committed, and you just need me to test it now? :-) > > > Likewise... ;-) >
Sorry to disappoint you so far. I'll see if I can turn up my shell-skills a notch or two and get the hang of the commit-script enough to implement it.
-- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231