* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-09 14:02 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git, Junio C Hamano
In-Reply-To: <20091209131945.GB30218@atjola.homenet>
On Wed, Dec 09, 2009 at 02:19:45PM +0100, Björn Steinbrink wrote:
> On 2009.12.08 22:00:17 +0200, Michael S. Tsirkin wrote:
> > On Tue, Dec 08, 2009 at 08:11:07PM +0100, Björn Steinbrink wrote:
> > > So you can already do what you want to do, but wrapping it in a single
> > > porcelain might still be useful because it's obviously a lot easier and
> > > safer that way. That said, I wonder what kind of workflow you're using
> > > though, and why you require that feature. I've never needed something
> > > like that.
> >
> > I need this often for many reasons:
> > - Imagine developing a patchset with a complex bugfix on master branch.
> > Then I decide to also apply (backport) this patchset to stable branch.
>
> Hm, I'd also imagine that you want a separate branch then, and not
> directly mess up the stable branch,
Well, directly working with a stable branch is easier, so yes,
I want to mess it up: this is just my local tree, if anything
goes wrong I just don't push or "reset --hard origin/stable".
> so I'd do:
> git branch foo-stable foo # Create a branch for the backport
> git rebase --onto stable master foo-stable # Backport
>
> Now you got your backported version and can merge it to "stable".
The annoying thing is that merge step. I can create a merge
commit if I mistype things, and I do not want any
merge commits, I want to create linear history.
> Common wisdom is do things the other way around though. Create the
> bugfix for the oldest branch that it applies to, then merge it forward,
> either doing:
>
> "bugfix -> stable" and "stable -> master" merges, or
> "bugfix -> stable" and "bugfix -> master" merges.
>
> That approach has the advantage that you don't get multiple commits
> doing the same thing, which you get with rebasing/cherry-picking.
>
> IIRC the gitworkflows manpage describe that in some more detail.
I know. The advantage of making all changes to master first
is that this way a change gets more review and testing before
being applied to stable. Further, often different people
maintain master and stable branches.
> > - Imagine developing a bugfix/feature patchset on master branch.
> > Then I decide the patchset is too large/unsafe and want to
> > switch it to staging branch.
>
> Hm, so you have a topic branch "foo" based upon master, but it's too
> experimental so you don't want to merge it to master, but "staging". I
> don't see why you even have to rebase it then. "staging" is likely ahead
> of master, so the merge base of "foo" and "master" is also reachable
> through "staging", and simply merging "foo" to "staging" should work
> without any ill-effects.
Yes but I want my development history to be linear,
so that format patch rebase -i etc work well.
> > - I have a large queue of patches on staging branch, I decide that
> > a range of patches is mature enough for master.
>
> Basically, same deal as with the first two cases. If the series is
> directly on "staging" (i.e. you didn't create a topic branch), you can
> create one now:
> git branch foo $last_commit_for_foo
> git rebase --onto master $first_commit_for_foo^ foo
>
> And you got your backported topic branch for "foo".
>
> Or you already have a topic branch "foo-staging", but it's based upon
> some commit only in "staging" but not in "master", so a plain merge
> would mess things up. Same deal as with backporting from "master" to
> "stable"
Yes, I understand that creating a temporary branch and checking it out
then merging it will make rebase do what I want.
The only disadvantage is that I need to remember where I am in the
process, while an "atomic" command does this for me.
> And in this case it's also true that basing the topic branches on
> "master" instead of "staging" makes things easier. That way, you can
> merge to either "staging" or "master" without any ill-effects.
>
> Björn
As above, I do not want merges.
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-09 14:01 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Matthieu Moy, Junio C Hamano, git
In-Reply-To: <20091209134535.GK2977@redhat.com>
On 2009.12.09 15:45:36 +0200, Michael S. Tsirkin wrote:
> On Wed, Dec 09, 2009 at 02:30:06PM +0100, Matthieu Moy wrote:
> > Junio C Hamano <gitster@pobox.com> writes:
> >
> > > So perhaps a good way to move forward is to teach "git cherry-pick A..B"
> > > to be a thin wrapper that invokes a new hidden mode of operation added to
> > > "rebase" that is not advertised to the end user.
> > >
> > > I would suggest calling the option to invoke that hidden mode not
> > > "--revisions", but "--reverse" or "--opposite" or something of that
> > > nature, though. It makes "rebase" work in different direction.
> >
> > Intuitively,
> >
> > git rebase --reverse A..B
> >
> > would mean "take the range A..B, and start applying the patches from
> > B, going in reverse order up to A", like "git log --reverse". So, I'd
> > find it misleading.
> >
> > Perhaps "git rebase --cherry-pick A..B" would be a better name. No
> > objection for --opposite either.
>
> I relly like --cherry-pick. Junio, objections to that one?
Hm, there's also (the probably not so well known)
"git rev-list --cherry-pick A...B", which excludes commits that appear
on both A and B and have the same patch id. I'd rather call the rev-list
option a misnomer than the suggested hidden option for rebase, but I'd
call it --cherry-pick-mode or --cherry-picking (like am's hidden "git am
--rebasing"), just to make sure... Of course, it's not _that_ important,
as it's going to be a hidden option, so user confusion is probably not
that much of a concern.
Björn
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-09 13:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Junio C Hamano, git
In-Reply-To: <vpqiqcgp95t.fsf@bauges.imag.fr>
On Wed, Dec 09, 2009 at 02:30:06PM +0100, Matthieu Moy wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > So perhaps a good way to move forward is to teach "git cherry-pick A..B"
> > to be a thin wrapper that invokes a new hidden mode of operation added to
> > "rebase" that is not advertised to the end user.
> >
> > I would suggest calling the option to invoke that hidden mode not
> > "--revisions", but "--reverse" or "--opposite" or something of that
> > nature, though. It makes "rebase" work in different direction.
>
> Intuitively,
>
> git rebase --reverse A..B
>
> would mean "take the range A..B, and start applying the patches from
> B, going in reverse order up to A", like "git log --reverse". So, I'd
> find it misleading.
>
> Perhaps "git rebase --cherry-pick A..B" would be a better name. No
> objection for --opposite either.
I relly like --cherry-pick. Junio, objections to that one?
> --
> Matthieu Moy
> http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-09 13:41 UTC (permalink / raw)
To: Peter Krefting; +Cc: Michael S. Tsirkin, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0912091414460.470@ds9.cixit.se>
On 2009.12.09 14:20:23 +0100, Peter Krefting wrote:
> Björn Steinbrink:
>
> >Err, no. "git merge --squash foo" merges all changes from the
> >merge base of HEAD and foo up to foo. "git cherry-pick foo" takes
> >just the changes
> > from foo^ to foo.
>
> Exactly!
>
> What I meant to say in the original message was that conceptually,
> the difference between a "git rebase --reverse A..B", a "git
> cherry-pick A..B" and a "git merge --squash A..B" is minute.
>
> And when continuing the thought experiment, the step from "git merge
> --squash A..B" to "git merge A..B" is not very large either, just (a
> lot) more difficult to implement.
"git merge" is about merging histories. --squash and the A..B you
suggest make it degenerate into merging changes (and you can't record
that using the commit DAG). So that messes things up conceptually.
Implementing probably wouldn't be that hard, IIRC it should be a matter
of messing with the fake merge base that cherry-pick uses to get its job
done. While "git cherry-pick foo" uses foo^ as the merge base, you'd
just make "git merge --squash A..B" work like "git cherry-pick B" but
use A as the fake merge base. It's been a while since I looked at the
cherry-pick code though, so I might be off here.
(Kind of ironic though that I didn't think of that when I said that
"cherry-pick --squash" would be hard to do...)
Anyway, "git merge" with a range simply makes no sense at all given how
git's merge works (opposed to svn's idea of merging, which is about
changes, not about histories). If you want a squash flag, tell
cherry-pick to handle ranges and teach such a flag to it.
Björn
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Matthieu Moy @ 2009-12-09 13:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, git
In-Reply-To: <7vfx7lcj18.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> So perhaps a good way to move forward is to teach "git cherry-pick A..B"
> to be a thin wrapper that invokes a new hidden mode of operation added to
> "rebase" that is not advertised to the end user.
>
> I would suggest calling the option to invoke that hidden mode not
> "--revisions", but "--reverse" or "--opposite" or something of that
> nature, though. It makes "rebase" work in different direction.
Intuitively,
git rebase --reverse A..B
would mean "take the range A..B, and start applying the patches from
B, going in reverse order up to A", like "git log --reverse". So, I'd
find it misleading.
Perhaps "git rebase --cherry-pick A..B" would be a better name. No
objection for --opposite either.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Peter Krefting @ 2009-12-09 13:20 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Michael S. Tsirkin, Junio C Hamano, Git Mailing List
In-Reply-To: <20091209112237.GA27740@atjola.homenet>
Björn Steinbrink:
> Err, no. "git merge --squash foo" merges all changes from the merge base
> of HEAD and foo up to foo. "git cherry-pick foo" takes just the changes
> from foo^ to foo.
Exactly!
What I meant to say in the original message was that conceptually, the
difference between a "git rebase --reverse A..B", a "git cherry-pick A..B"
and a "git merge --squash A..B" is minute.
And when continuing the thought experiment, the step from "git merge
--squash A..B" to "git merge A..B" is not very large either, just (a
lot) more difficult to implement.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-09 13:19 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: git, Junio C Hamano
In-Reply-To: <20091208200017.GA827@redhat.com>
On 2009.12.08 22:00:17 +0200, Michael S. Tsirkin wrote:
> On Tue, Dec 08, 2009 at 08:11:07PM +0100, Björn Steinbrink wrote:
> > So you can already do what you want to do, but wrapping it in a single
> > porcelain might still be useful because it's obviously a lot easier and
> > safer that way. That said, I wonder what kind of workflow you're using
> > though, and why you require that feature. I've never needed something
> > like that.
>
> I need this often for many reasons:
> - Imagine developing a patchset with a complex bugfix on master branch.
> Then I decide to also apply (backport) this patchset to stable branch.
Hm, I'd also imagine that you want a separate branch then, and not
directly mess up the stable branch, so I'd do:
git branch foo-stable foo # Create a branch for the backport
git rebase --onto stable master foo-stable # Backport
Now you got your backported version and can merge it to "stable".
Common wisdom is do things the other way around though. Create the
bugfix for the oldest branch that it applies to, then merge it forward,
either doing:
"bugfix -> stable" and "stable -> master" merges, or
"bugfix -> stable" and "bugfix -> master" merges.
That approach has the advantage that you don't get multiple commits
doing the same thing, which you get with rebasing/cherry-picking.
IIRC the gitworkflows manpage describe that in some more detail.
> - Imagine developing a bugfix/feature patchset on master branch.
> Then I decide the patchset is too large/unsafe and want to
> switch it to staging branch.
Hm, so you have a topic branch "foo" based upon master, but it's too
experimental so you don't want to merge it to master, but "staging". I
don't see why you even have to rebase it then. "staging" is likely ahead
of master, so the merge base of "foo" and "master" is also reachable
through "staging", and simply merging "foo" to "staging" should work
without any ill-effects.
> - I have a large queue of patches on staging branch, I decide that
> a range of patches is mature enough for master.
Basically, same deal as with the first two cases. If the series is
directly on "staging" (i.e. you didn't create a topic branch), you can
create one now:
git branch foo $last_commit_for_foo
git rebase --onto master $first_commit_for_foo^ foo
And you got your backported topic branch for "foo".
Or you already have a topic branch "foo-staging", but it's based upon
some commit only in "staging" but not in "master", so a plain merge
would mess things up. Same deal as with backporting from "master" to
"stable"
And in this case it's also true that basing the topic branches on
"master" instead of "staging" makes things easier. That way, you can
merge to either "staging" or "master" without any ill-effects.
Björn
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-09 13:06 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Andreas Schwab, Peter Krefting, Junio C Hamano, Git Mailing List
In-Reply-To: <20091209120748.GI2977@redhat.com>
On 2009.12.09 14:07:48 +0200, Michael S. Tsirkin wrote:
> On Wed, Dec 09, 2009 at 01:06:10PM +0100, Björn Steinbrink wrote:
> > On 2009.12.09 12:48:24 +0100, Andreas Schwab wrote:
> > > Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> > >
> > > > Err, no. "git merge --squash foo" merges all changes from the merge base
> > > > of HEAD and foo up to foo. "git cherry-pick foo" takes just the changes
> > > > from foo^ to foo. For example:
> > > >
> > > > A---B---C (master)
> > > > \
> > > > D---E---F (foo)
> > > >
> > > > git cherry-pick foo # Tries to create a new commit with the changes from
> > > > # "git diff D F"
> > >
> > > Did you mean "git diff E F"?
> >
> > Ugh, yes, of course. Thanks.
>
> So this will be best written as
> git cherry-pick ..foo
No, "git cherry-pick ..foo" should pick the individual commits, and not
create a single big commit like "git merge --squash". So such a command
should make you end up with:
A---B---C---D'--E'--F' (master)
\
D---E---F
Not:
A---B---C---M (master)
\
D---E---F (foo)
[M being the "sqash-merge"]
"merge --squash" is one of the things I really dislike, because it turns
off the "history" part of the merge. You can say "Merging in git is about
histories, merging in svn is about changes only" to describe the major
difference for the merge commands in the two systems... "But then
there's --squash which turns git into svn".
I think a "cherry-pick --squash <range>" command would be nicer from a
conceptual point of view, but it's way too late for merge --squash to be
dropped. And I guess it wouldn't be trivial to add such a flag, and not
worth the effort, as you could as well use the interactive mode and
replace "pick" with "squash" manually. (An el cheapo implementation that
automatically replaces it would likely confuse the user, because he
asked for a single commit, but might get to fix conflicts for all the
individual commits).
Björn
^ permalink raw reply
* Re: help: bisect single file from repos
From: walter harms @ 2009-12-09 12:12 UTC (permalink / raw)
To: SZEDER Gábor
Cc: Nanako Shiraishi, Junio C Hamano, git, Christian Couder,
Michael J Gruber
In-Reply-To: <20091209094532.GS18686@neumann>
SZEDER Gábor schrieb:
> Hi,
>
>
> On Wed, Dec 09, 2009 at 05:27:37PM +0900, Nanako Shiraishi wrote:
>> Quoting SZEDER Gábor <szeder@ira.uka.de>
>>
>>> [1] - 'git cherry-pick' doc says the following:
>>>
>>> <commit>
>>> Commit to cherry-pick. For a more complete list of ways to spell
>>> commits, see the "SPECIFYING REVISIONS" section in git-rev-parse(1).
>>>
>>> What? "A _more_ complete list"!? Well, it's not very hard to be more
>>> complete than this, there is not a single way described here (;
>
>> I agree that "more" shouldn't be in that sentence, and I understand
>> your hesitation to read plumbing manual pages, but I don't think it
>> is a sane solution to the issue to repeat how to name a commit in
>> manual pages for every single command to bloat the two line
>> description you quoted into a half-page paragraph. Even within that
>> two lines, the real information that should be in the manual for
>> cherry-pick is only three words "Commit to cherry-pick" and the rest
>> is to help people who don't know.
>
> I agree, that's why I proposed "a _section_ about specifying these
> commits" in the more relevant part of my previous email you did not
> quote.
>
> The description of the "<commit>" option would remain almost the same,
> but it will now refer to a dedicated section about specifying commits
> below, but still in the same manpage. This new dedicated section
> would contain the list of three, five, N most common ways to specify a
> commit, avoiding the bloatage in the options section. And for those
> who really want to dig deep, this dedicated section will refer to 'git
> rev-parse' for the complete list.
>
> And this would not be the first time we document something in many
> places, think of '--pretty' and diff options, for example.
>
>
It would be no problem when you have the description multiple times.
Important is that they use the same words for the same things
and add examples. Most people that use git have a fair idea what they
want but not how to do it. git is new an you can not assume that
even basic principles are known to the general (programmer) community.
So you need to make extra effort to explain it all over again.
re,
wh
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-09 12:07 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Andreas Schwab, Peter Krefting, Junio C Hamano, Git Mailing List
In-Reply-To: <20091209120610.GA29430@atjola.homenet>
On Wed, Dec 09, 2009 at 01:06:10PM +0100, Björn Steinbrink wrote:
> On 2009.12.09 12:48:24 +0100, Andreas Schwab wrote:
> > Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> >
> > > Err, no. "git merge --squash foo" merges all changes from the merge base
> > > of HEAD and foo up to foo. "git cherry-pick foo" takes just the changes
> > > from foo^ to foo. For example:
> > >
> > > A---B---C (master)
> > > \
> > > D---E---F (foo)
> > >
> > > git cherry-pick foo # Tries to create a new commit with the changes from
> > > # "git diff D F"
> >
> > Did you mean "git diff E F"?
>
> Ugh, yes, of course. Thanks.
>
> Björn
So this will be best written as
git cherry-pick ..foo
--
MST
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-09 12:06 UTC (permalink / raw)
To: Andreas Schwab
Cc: Peter Krefting, Michael S. Tsirkin, Junio C Hamano,
Git Mailing List
In-Reply-To: <m2pr6ocqrb.fsf@igel.home>
On 2009.12.09 12:48:24 +0100, Andreas Schwab wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> > Err, no. "git merge --squash foo" merges all changes from the merge base
> > of HEAD and foo up to foo. "git cherry-pick foo" takes just the changes
> > from foo^ to foo. For example:
> >
> > A---B---C (master)
> > \
> > D---E---F (foo)
> >
> > git cherry-pick foo # Tries to create a new commit with the changes from
> > # "git diff D F"
>
> Did you mean "git diff E F"?
Ugh, yes, of course. Thanks.
Björn
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Andreas Schwab @ 2009-12-09 11:48 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Peter Krefting, Michael S. Tsirkin, Junio C Hamano,
Git Mailing List
In-Reply-To: <20091209112237.GA27740@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Err, no. "git merge --squash foo" merges all changes from the merge base
> of HEAD and foo up to foo. "git cherry-pick foo" takes just the changes
> from foo^ to foo. For example:
>
> A---B---C (master)
> \
> D---E---F (foo)
>
> git cherry-pick foo # Tries to create a new commit with the changes from
> # "git diff D F"
Did you mean "git diff E F"?
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Björn Steinbrink @ 2009-12-09 11:22 UTC (permalink / raw)
To: Peter Krefting; +Cc: Michael S. Tsirkin, Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0912091150470.470@ds9.cixit.se>
On 2009.12.09 11:52:41 +0100, Peter Krefting wrote:
> Michael S. Tsirkin:
>
> >>Maybe this could also be used to implement a "git merge --squash
> >>A..B", a.k.a a "partial merge".
> >What exactly should it do?
>
> The same thing, apply a set of changes on top of the current branch,
> just using the "merge" name, and not "rebase" or "cherry-pick".
> "merge --squash" is just "cherry-pick" with a different name.
Err, no. "git merge --squash foo" merges all changes from the merge base
of HEAD and foo up to foo. "git cherry-pick foo" takes just the changes
from foo^ to foo. For example:
A---B---C (master)
\
D---E---F (foo)
git cherry-pick foo # Tries to create a new commit with the changes from
# "git diff D F"
git merge --squash foo # Tries to create a new commit with the changes
# from "git diff A F"
Björn
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Matthieu Moy @ 2009-12-09 10:55 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, git
In-Reply-To: <20091209103850.GD2977@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> cherry-pick is a binary though while rebase is a shell script.
> Should I just exec git rebase? git-rebase?
See run-command.h :
#define RUN_GIT_CMD 2 /*If this is to be git sub-command */
int run_command_v_opt(const char **argv, int opt);
That should do the trick (grep 'run_command_v_opt.*GIT_CMD' *.c for
some example of uses).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Peter Krefting @ 2009-12-09 10:52 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20091209093758.GA2977@redhat.com>
Michael S. Tsirkin:
>> Maybe this could also be used to implement a "git merge --squash A..B",
>> a.k.a a "partial merge".
> What exactly should it do?
The same thing, apply a set of changes on top of the current branch, just
using the "merge" name, and not "rebase" or "cherry-pick". "merge --squash"
is just "cherry-pick" with a different name.
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-09 10:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vfx7lcj18.fsf@alter.siamese.dyndns.org>
On Tue, Dec 08, 2009 at 12:22:59PM -0800, Junio C Hamano wrote:
> "Michael S. Tsirkin" <mst@redhat.com> writes:
>
> > Add --revisions flag to rebase, so that it can be used
> > to apply an arbitrary range of commits on top
> > of a current branch.
>
> Many people wanted to have "pick many commits onto the current HEAD" and I
> think it would be a natural, uncontroversial and welcome addition to allow
> "git cherry-pick A..B". In fact, historically, people who wanted to have
> "pick many commits" complained that the "rebase" interface was backwards,
> because it works in the _wrong_ direction for _their_ usecase. Of course,
> when you _are_ rebasing a branch on top of some other branch, the way
> "rebase" currently works is the _right_ direction.
>
> But I think it is a reasonable thing to _implement_ the feature to
> range-pick commits reusing the sequencing logic already in "rebase" and
> "rebase -i". That essentially is what we wanted to do with "git
> sequencer" that would be a sequencing logic backend shared among rebase,
> cherry-pick, and perhaps am.
>
> So perhaps a good way to move forward is to teach "git cherry-pick A..B"
> to be a thin wrapper that invokes a new hidden mode of operation added to
> "rebase" that is not advertised to the end user.
>
> I would suggest calling the option to invoke that hidden mode not
> "--revisions", but "--reverse" or "--opposite" or something of that
> nature, though. It makes "rebase" work in different direction.
cherry-pick is a binary though while rebase is a shell script.
Should I just exec git rebase? git-rebase?
--
MST
^ permalink raw reply
* Re: rerere failed to parse conflict hunks
From: Uwe Kleine-König @ 2009-12-09 10:00 UTC (permalink / raw)
To: Ben Dooks; +Cc: git, Michael J Gruber
In-Reply-To: <4B1F721E.9050609@drmicha.warpmail.net>
Best regards
Uwe
On Wed, Dec 09, 2009 at 10:47:10AM +0100, Michael J Gruber wrote:
> Uwe Kleine-König venit, vidit, dixit 09.12.2009 09:46:
> > Hello,
> >
> > I just tried to merge linux-next
> > (5c1af82119f11c5b322156b09d38cc37318849c4) into my private tree
> > (based on 2b876f95d03e226394b5d360c86127cbefaf614b) and this
> > happened:
> >
> > ...
> > Removing sound/soc/au1x/sample-ac97.c
> > Recorded preimage for 'arch/Kconfig'
> > Recorded preimage for 'arch/arm/mach-s3c2440/mach-anubis.c'
> > Recorded preimage for 'arch/arm/plat-mxc/Makefile'
> > error: Could not parse conflict hunks in arch/arm/plat-s3c/dev-hsmmc2.c
> > Recorded preimage for 'arch/arm/plat-s3c/include/plat/sdhci.h'
> > Recorded preimage for 'arch/arm/plat-samsung/Kconfig'
> > Recorded preimage for 'arch/x86/include/asm/x86_init.h'
> > Recorded preimage for 'arch/x86/kernel/x86_init.c'
> > Recorded preimage for 'drivers/net/wireless/ray_cs.c'
> > Recorded preimage for 'kernel/Makefile'
> > Recorded preimage for 'kernel/power/hibernate.c'
> > Recorded preimage for 'net/sctp/sysctl.c'
> > Automatic merge failed; fix conflicts and then commit the result.
> >
> > If you are interested, I can provide you the two trees above. When
> > reproducing the line "error: ..." came later, but is still present.
> >
> > I guess this should be reproduceable with
> >
> > git clone -n git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> > cd linux-2.6
> > git remote add -f next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> > git checkout 2b876f95d03e226394b5d360c86127cbefaf614b
> > git merge 5c1af82119f11c5b322156b09d38cc37318849c4
> >
> > I havn't tried though.
> >
> > The only non-trivial conflict is:
> >
> > #include <plat/sdhci.h>
> > #include <plat/devs.h>
> > <<<<<<< HEAD
> > =======
> > <<<<<<< HEAD
> > #include <plat/cpu.h>
> > =======
> > >>>>>>> next-s5pc1xx
> > >>>>>>> next/master
> >
>
> Someone committed a file with conflict markers. Bad bad boy. I guess
> a8c4f01 (fixup sdhci merge failure, 2009-11-23) did not quite what it
> promised.
obviously, yes.
Ben, you might want to redo commit a8c4f018ba69266aeb3cccf73c36b6663189e730
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* Re: rerere failed to parse conflict hunks
From: Michael J Gruber @ 2009-12-09 9:47 UTC (permalink / raw)
To: Uwe Kleine-König; +Cc: git
In-Reply-To: <20091209084648.GA30139@pengutronix.de>
Uwe Kleine-König venit, vidit, dixit 09.12.2009 09:46:
> Hello,
>
> I just tried to merge linux-next
> (5c1af82119f11c5b322156b09d38cc37318849c4) into my private tree
> (based on 2b876f95d03e226394b5d360c86127cbefaf614b) and this
> happened:
>
> ...
> Removing sound/soc/au1x/sample-ac97.c
> Recorded preimage for 'arch/Kconfig'
> Recorded preimage for 'arch/arm/mach-s3c2440/mach-anubis.c'
> Recorded preimage for 'arch/arm/plat-mxc/Makefile'
> error: Could not parse conflict hunks in arch/arm/plat-s3c/dev-hsmmc2.c
> Recorded preimage for 'arch/arm/plat-s3c/include/plat/sdhci.h'
> Recorded preimage for 'arch/arm/plat-samsung/Kconfig'
> Recorded preimage for 'arch/x86/include/asm/x86_init.h'
> Recorded preimage for 'arch/x86/kernel/x86_init.c'
> Recorded preimage for 'drivers/net/wireless/ray_cs.c'
> Recorded preimage for 'kernel/Makefile'
> Recorded preimage for 'kernel/power/hibernate.c'
> Recorded preimage for 'net/sctp/sysctl.c'
> Automatic merge failed; fix conflicts and then commit the result.
>
> If you are interested, I can provide you the two trees above. When
> reproducing the line "error: ..." came later, but is still present.
>
> I guess this should be reproduceable with
>
> git clone -n git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
> cd linux-2.6
> git remote add -f next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
> git checkout 2b876f95d03e226394b5d360c86127cbefaf614b
> git merge 5c1af82119f11c5b322156b09d38cc37318849c4
>
> I havn't tried though.
>
> The only non-trivial conflict is:
>
> #include <plat/sdhci.h>
> #include <plat/devs.h>
> <<<<<<< HEAD
> =======
> <<<<<<< HEAD
> #include <plat/cpu.h>
> =======
> >>>>>>> next-s5pc1xx
> >>>>>>> next/master
>
Someone committed a file with conflict markers. Bad bad boy. I guess
a8c4f01 (fixup sdhci merge failure, 2009-11-23) did not quite what it
promised.
Michael
^ permalink raw reply
* Re: help: bisect single file from repos
From: SZEDER Gábor @ 2009-12-09 9:45 UTC (permalink / raw)
To: Nanako Shiraishi
Cc: Junio C Hamano, git, Christian Couder, Michael J Gruber, wharms
In-Reply-To: <20091209172737.6117@nanako3.lavabit.com>
Hi,
On Wed, Dec 09, 2009 at 05:27:37PM +0900, Nanako Shiraishi wrote:
> Quoting SZEDER Gábor <szeder@ira.uka.de>
>
> > [1] - 'git cherry-pick' doc says the following:
> >
> > <commit>
> > Commit to cherry-pick. For a more complete list of ways to spell
> > commits, see the "SPECIFYING REVISIONS" section in git-rev-parse(1).
> >
> > What? "A _more_ complete list"!? Well, it's not very hard to be more
> > complete than this, there is not a single way described here (;
>
> I agree that "more" shouldn't be in that sentence, and I understand
> your hesitation to read plumbing manual pages, but I don't think it
> is a sane solution to the issue to repeat how to name a commit in
> manual pages for every single command to bloat the two line
> description you quoted into a half-page paragraph. Even within that
> two lines, the real information that should be in the manual for
> cherry-pick is only three words "Commit to cherry-pick" and the rest
> is to help people who don't know.
I agree, that's why I proposed "a _section_ about specifying these
commits" in the more relevant part of my previous email you did not
quote.
The description of the "<commit>" option would remain almost the same,
but it will now refer to a dedicated section about specifying commits
below, but still in the same manpage. This new dedicated section
would contain the list of three, five, N most common ways to specify a
commit, avoiding the bloatage in the options section. And for those
who really want to dig deep, this dedicated section will refer to 'git
rev-parse' for the complete list.
And this would not be the first time we document something in many
places, think of '--pretty' and diff options, for example.
Best,
Gábor
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Michael S. Tsirkin @ 2009-12-09 9:37 UTC (permalink / raw)
To: Peter Krefting; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0912090941420.470@ds9.cixit.se>
On Wed, Dec 09, 2009 at 09:47:56AM +0100, Peter Krefting wrote:
> Junio C Hamano:
>
>> Many people wanted to have "pick many commits onto the current HEAD"
>> and I think it would be a natural, uncontroversial and welcome addition
>> to allow "git cherry-pick A..B".
>
> Or even "git cherry-pick branch", as I naïvely tried doing before I
> understood what it did. This is definitely a feature that would help me.
>
> The question of where it goes is actually a bit difficult, it is the same
> mode of operation as "git rebase", only the other way around. It is the
> same as "git cherry-pick", but called multiple times. And it is the same
> as "git merge --squash", but without squashing the commits into one.
>
> So does this new mode go into rebase, cherry-pick or merge, or into all
> three? No matter which, proper documentation is needed.
>
>
> Maybe this could also be used to implement a "git merge --squash A..B",
> a.k.a a "partial merge".
What exactly should it do?
> (And if it could be implemented to allow a "git
> merge A..B" and later do a "git merge B" to merge the rest of the
> side-branch, that would be interesting).
rebase already tries to detect previously applied commits.
Maybe we can teach it to use more heuristics.
> --
> \\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH 2/2] t7508-status: test all modes with color
From: Michael J Gruber @ 2009-12-09 9:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git
In-Reply-To: <7vmy1swvjc.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 09.12.2009 06:32/06:44:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> > Jakub Narebski venit, vidit, dixit 08.12.2009 12:10:
>>> >> Michael J Gruber wrote:
>>> >>
>>>> >>> +decrypt_color () {
>>>> >>> + sed \
>>>> >>> + -e 's/.\[1m/<WHITE>/g' \
>>>> >>> + -e 's/.\[31m/<RED>/g' \
>>>> >>> + -e 's/.\[32m/<GREEN>/g' \
>>>> >>> + -e 's/.\[34m/<BLUE>/g' \
>>>> >>> + -e 's/.\[m/<RESET>/g'
>>>> >>> +}
>>> >>
>>> >> Shouldn't this be better in test-lib.sh, or some common lib
>>> >> (lib-color.sh or color-lib.sh; we are unfortunately a bit inconsistent
>>> >> in naming here)?
>> >
>> > Well, so far it's used in two places (and somewhat differently). I would
>> > say test-libification starts at 3 :)
> That is a pretty lame excuse and is a bad way to keep things maintainable.
>
> Having two copies now means that you will *double* the chance for the next
> person to copy and paste one of the existing copies that are found in the
> non-library-ish part of the test script set to create the third duplicate,
> without even realizing that there already are two copies that should have
> been consolidated in the first place. The worst part is that once that
> duplication is pointed out, s/he will use the existing two copies as an
> excuse for copy and paste.
>
> Please don't.
>
Okay okay, I guess I have to spell out my smileys better in the future.
The real question for us (Jakub and me) was where to put the code. I
think by giving that info I could have been easily convinced to do that
step...
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Michael J Gruber <git@drmicha.warpmail.net> writes:
>>
>>> Jakub Narebski venit, vidit, dixit 08.12.2009 12:10:
>>>> Michael J Gruber wrote:
>>>>
>>>>> +decrypt_color () {
>>>>> + sed \
>>>>> + -e 's/.\[1m/<WHITE>/g' \
>>>>> + -e 's/.\[31m/<RED>/g' \
>>>>> + -e 's/.\[32m/<GREEN>/g' \
>>>>> + -e 's/.\[34m/<BLUE>/g' \
>>>>> + -e 's/.\[m/<RESET>/g'
>>>>> +}
>>>>
>>>> Shouldn't this be better in test-lib.sh, or some common lib
>>>> (lib-color.sh or color-lib.sh; we are unfortunately a bit inconsistent
>>>> in naming here)?
>>>
>>> Well, so far it's used in two places (and somewhat differently). I would
>>> say test-libification starts at 3 :)
>> ...
>> Please don't.
>
> I'll squash this in to fix it up.
>
> I don't know where 36->BROWN mistake came from when color.h has a
> series of #define that can be used to make the decoding script
> mechanically, though ;-)
I don't know either, I didn't make it - I even corrected it in my copy -
which proves your former point, of course.
> t/t4034-diff-words.sh | 23 ++++---------
> t/t7508-status.sh | 83 ++++++++++++++++++++++---------------------------
> t/test-lib.sh | 11 ++++++
> 3 files changed, 55 insertions(+), 62 deletions(-)
>
> diff --git a/t/t4034-diff-words.sh b/t/t4034-diff-words.sh
> index 4508eff..ea895b0 100755
> --- a/t/t4034-diff-words.sh
> +++ b/t/t4034-diff-words.sh
> @@ -11,18 +11,9 @@ test_expect_success setup '
>
> '
>
> -decrypt_color () {
> - sed \
> - -e 's/.\[1m/<WHITE>/g' \
> - -e 's/.\[31m/<RED>/g' \
> - -e 's/.\[32m/<GREEN>/g' \
> - -e 's/.\[36m/<BROWN>/g' \
> - -e 's/.\[m/<RESET>/g'
> -}
> -
> word_diff () {
> test_must_fail git diff --no-index "$@" pre post > output &&
> - decrypt_color < output > output.decrypted &&
> + test_decode_color <output >output.decrypted &&
> test_cmp expect output.decrypted
> }
>
> @@ -47,7 +38,7 @@ cat > expect <<\EOF
> <WHITE>index 330b04f..5ed8eff 100644<RESET>
> <WHITE>--- a/pre<RESET>
> <WHITE>+++ b/post<RESET>
> -<BROWN>@@ -1,3 +1,7 @@<RESET>
> +<CYAN>@@ -1,3 +1,7 @@<RESET>
> <RED>h(4)<RESET><GREEN>h(4),hh[44]<RESET>
> <RESET>
> a = b + c<RESET>
> @@ -68,7 +59,7 @@ cat > expect <<\EOF
> <WHITE>index 330b04f..5ed8eff 100644<RESET>
> <WHITE>--- a/pre<RESET>
> <WHITE>+++ b/post<RESET>
> -<BROWN>@@ -1,3 +1,7 @@<RESET>
> +<CYAN>@@ -1,3 +1,7 @@<RESET>
> h(4),<GREEN>hh<RESET>[44]
> <RESET>
> a = b + c<RESET>
> @@ -104,7 +95,7 @@ cat > expect <<\EOF
> <WHITE>index 330b04f..5ed8eff 100644<RESET>
> <WHITE>--- a/pre<RESET>
> <WHITE>+++ b/post<RESET>
> -<BROWN>@@ -1,3 +1,7 @@<RESET>
> +<CYAN>@@ -1,3 +1,7 @@<RESET>
> h(4)<GREEN>,hh[44]<RESET>
> <RESET>
> a = b + c<RESET>
> @@ -146,7 +137,7 @@ cat > expect <<\EOF
> <WHITE>index 330b04f..5ed8eff 100644<RESET>
> <WHITE>--- a/pre<RESET>
> <WHITE>+++ b/post<RESET>
> -<BROWN>@@ -1,3 +1,7 @@<RESET>
> +<CYAN>@@ -1,3 +1,7 @@<RESET>
> h(4),<GREEN>hh[44<RESET>]
> <RESET>
> a = b + c<RESET>
> @@ -168,7 +159,7 @@ cat > expect <<\EOF
> <WHITE>index c29453b..be22f37 100644<RESET>
> <WHITE>--- a/pre<RESET>
> <WHITE>+++ b/post<RESET>
> -<BROWN>@@ -1 +1 @@<RESET>
> +<CYAN>@@ -1 +1 @@<RESET>
> aaa (aaa) <GREEN>aaa<RESET>
> EOF
>
> @@ -187,7 +178,7 @@ cat > expect <<\EOF
> <WHITE>index 289cb9d..2d06f37 100644<RESET>
> <WHITE>--- a/pre<RESET>
> <WHITE>+++ b/post<RESET>
> -<BROWN>@@ -1 +1 @@<RESET>
> +<CYAN>@@ -1 +1 @@<RESET>
> (<RED>:<RESET>
> EOF
>
> diff --git a/t/t7508-status.sh b/t/t7508-status.sh
> index 50554a0..cf67fe3 100755
> --- a/t/t7508-status.sh
> +++ b/t/t7508-status.sh
> @@ -8,45 +8,36 @@ test_description='git status'
> . ./test-lib.sh
>
> test_expect_success 'setup' '
> - : > tracked &&
> - : > modified &&
> + : >tracked &&
> + : >modified &&
> mkdir dir1 &&
> - : > dir1/tracked &&
> - : > dir1/modified &&
> + : >dir1/tracked &&
> + : >dir1/modified &&
> mkdir dir2 &&
> - : > dir1/tracked &&
> - : > dir1/modified &&
> + : >dir1/tracked &&
> + : >dir1/modified &&
> git add . &&
>
> git status >output &&
>
> test_tick &&
> git commit -m initial &&
> - : > untracked &&
> - : > dir1/untracked &&
> - : > dir2/untracked &&
> - echo 1 > dir1/modified &&
> - echo 2 > dir2/modified &&
> - echo 3 > dir2/added &&
> + : >untracked &&
> + : >dir1/untracked &&
> + : >dir2/untracked &&
> + echo 1 >dir1/modified &&
> + echo 2 >dir2/modified &&
> + echo 3 >dir2/added &&
> git add dir2/added
> '
>
> -decrypt_color () {
> - sed \
> - -e 's/.\[1m/<WHITE>/g' \
> - -e 's/.\[31m/<RED>/g' \
> - -e 's/.\[32m/<GREEN>/g' \
> - -e 's/.\[34m/<BLUE>/g' \
> - -e 's/.\[m/<RESET>/g'
> -}
> -
> test_expect_success 'status (1)' '
>
> grep "use \"git rm --cached <file>\.\.\.\" to unstage" output
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> @@ -72,12 +63,12 @@ EOF
>
> test_expect_success 'status (2)' '
>
> - git status > output &&
> + git status >output &&
> test_cmp expect output
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> M dir1/modified
> A dir2/added
> ?? dir1/untracked
> @@ -90,7 +81,7 @@ EOF
>
> test_expect_success 'status -s (2)' '
>
> - git status -s > output &&
> + git status -s >output &&
> test_cmp expect output
>
> '
> @@ -112,8 +103,8 @@ cat >expect <<EOF
> EOF
> test_expect_success 'status -uno' '
> mkdir dir3 &&
> - : > dir3/untracked1 &&
> - : > dir3/untracked2 &&
> + : >dir3/untracked1 &&
> + : >dir3/untracked2 &&
> git status -uno >output &&
> test_cmp expect output
> '
> @@ -258,7 +249,7 @@ test_expect_success 'status -s (status.showUntrackedFiles all)' '
> test_cmp expect output
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> @@ -284,12 +275,12 @@ EOF
>
> test_expect_success 'status with relative paths' '
>
> - (cd dir1 && git status) > output &&
> + (cd dir1 && git status) >output &&
> test_cmp expect output
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> M modified
> A ../dir2/added
> ?? untracked
> @@ -301,12 +292,12 @@ A ../dir2/added
> EOF
> test_expect_success 'status -s with relative paths' '
>
> - (cd dir1 && git status -s) > output &&
> + (cd dir1 && git status -s) >output &&
> test_cmp expect output
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> M dir1/modified
> A dir2/added
> ?? dir1/untracked
> @@ -319,7 +310,7 @@ EOF
>
> test_expect_success 'status --porcelain ignores relative paths setting' '
>
> - (cd dir1 && git status --porcelain) > output &&
> + (cd dir1 && git status --porcelain) >output &&
> test_cmp expect output
>
> '
> @@ -330,7 +321,7 @@ test_expect_success 'setup unique colors' '
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> @@ -357,7 +348,7 @@ EOF
> test_expect_success 'status with color.ui' '
>
> git config color.ui always &&
> - git status | decrypt_color > output &&
> + git status | test_decode_color >output &&
> test_cmp expect output
>
> '
> @@ -366,12 +357,12 @@ test_expect_success 'status with color.status' '
>
> git config --unset color.ui &&
> git config color.status always &&
> - git status | decrypt_color > output &&
> + git status | test_decode_color >output &&
> test_cmp expect output
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> <RED>M<RESET> dir1/modified
> <GREEN>A<RESET> dir2/added
> <BLUE>??<RESET> dir1/untracked
> @@ -386,7 +377,7 @@ test_expect_success 'status -s with color.ui' '
>
> git config --unset color.status &&
> git config color.ui always &&
> - git status -s | decrypt_color > output &&
> + git status -s | test_decode_color >output &&
> test_cmp expect output
>
> '
> @@ -395,12 +386,12 @@ test_expect_success 'status -s with color.status' '
>
> git config --unset color.ui &&
> git config color.status always &&
> - git status -s | decrypt_color > output &&
> + git status -s | test_decode_color >output &&
> test_cmp expect output
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> M dir1/modified
> A dir2/added
> ?? dir1/untracked
> @@ -415,7 +406,7 @@ test_expect_success 'status --porcelain ignores color.ui' '
>
> git config --unset color.status &&
> git config color.ui always &&
> - git status --porcelain | decrypt_color > output &&
> + git status --porcelain | test_decode_color >output &&
> test_cmp expect output
>
> '
> @@ -424,7 +415,7 @@ test_expect_success 'status --porcelain ignores color.status' '
>
> git config --unset color.ui &&
> git config color.status always &&
> - git status --porcelain | decrypt_color > output &&
> + git status --porcelain | test_decode_color >output &&
> test_cmp expect output
>
> '
> @@ -433,7 +424,7 @@ test_expect_success 'status --porcelain ignores color.status' '
> git config --unset color.status
> git config --unset color.ui
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> # On branch master
> # Changes to be committed:
> # (use "git reset HEAD <file>..." to unstage)
> @@ -461,12 +452,12 @@ EOF
> test_expect_success 'status without relative paths' '
>
> git config status.relativePaths false
> - (cd dir1 && git status) > output &&
> + (cd dir1 && git status) >output &&
> test_cmp expect output
>
> '
>
> -cat > expect << \EOF
> +cat >expect <<\EOF
> M dir1/modified
> A dir2/added
> ?? dir1/untracked
> @@ -479,7 +470,7 @@ EOF
>
> test_expect_success 'status -s without relative paths' '
>
> - (cd dir1 && git status -s) > output &&
> + (cd dir1 && git status -s) >output &&
> test_cmp expect output
>
> '
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 5fdc5d9..d63ad2d 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -208,6 +208,17 @@ test_set_editor () {
> export VISUAL
> }
>
> +test_decode_color () {
> + sed -e 's/.\[1m/<WHITE>/g' \
> + -e 's/.\[31m/<RED>/g' \
> + -e 's/.\[32m/<GREEN>/g' \
> + -e 's/.\[33m/<YELLOW>/g' \
> + -e 's/.\[34m/<BLUE>/g' \
> + -e 's/.\[35m/<MAGENTA>/g' \
> + -e 's/.\[36m/<CYAN>/g' \
> + -e 's/.\[m/<RESET>/g'
> +}
> +
> test_tick () {
> if test -z "${test_tick+set}"
> then
Regarding the larger part of your change: Is there a specific reason for
">output" rather than "> output" or just a style issue? I was simply
following the style which I found present in t7508 (same goes for empty
leading and trailing lines in the test bodies).
Michael
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Sverre Rabbelier @ 2009-12-09 9:08 UTC (permalink / raw)
To: Christian Couder
Cc: Junio C Hamano, Stephan Beyer, Christian Couder, Daniel Barkalow,
Git List, Johannes Schindelin
In-Reply-To: <200912090752.51609.chriscool@tuxfamily.org>
Heya,
On Wed, Dec 9, 2009 at 07:52, Christian Couder <chriscool@tuxfamily.org> wrote:
<snip>
> After that I plan to work on cherry-pick and that could be useful to
> implement something like "git cherry-pick A..B".
Ah, okay, thanks for the update!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [REROLL PATCH 3/8] Pass unknown protocols to external protocol handlers
From: Bert Wesarg @ 2009-12-09 8:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ilari Liusvaara, git
In-Reply-To: <7vskbl59ai.fsf@alter.siamese.dyndns.org>
On Wed, Dec 9, 2009 at 00:35, Junio C Hamano <gitster@pobox.com> wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>> + } else if (!is_url(url)
>> + || !prefixcmp(url, "file://")
>> + || !prefixcmp(url, "git://")
>> + || !prefixcmp(url, "ssh://")
>> + || !prefixcmp(url, "git+ssh://")
>> + || !prefixcmp(url, "ssh+git://")) {
>> + /* These are builtin smart transports. */
>
> Hmm, what is !is_url(url) at the beginning for, if this lists "builtin"
> smart transports?
I think/hope this should catch theses use cases:
? [user@]host.xz:/path/to/repo.git/
? [user@]host.xz:~user/path/to/repo.git/
? [user@]host.xz:path/to/repo.git
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Peter Krefting @ 2009-12-09 8:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Michael S. Tsirkin, Git Mailing List
In-Reply-To: <7vfx7lcj18.fsf@alter.siamese.dyndns.org>
Junio C Hamano:
> Many people wanted to have "pick many commits onto the current HEAD" and I
> think it would be a natural, uncontroversial and welcome addition to allow
> "git cherry-pick A..B".
Or even "git cherry-pick branch", as I naïvely tried doing before I
understood what it did. This is definitely a feature that would help me.
The question of where it goes is actually a bit difficult, it is the same
mode of operation as "git rebase", only the other way around. It is the same
as "git cherry-pick", but called multiple times. And it is the same as "git
merge --squash", but without squashing the commits into one.
So does this new mode go into rebase, cherry-pick or merge, or into all
three? No matter which, proper documentation is needed.
Maybe this could also be used to implement a "git merge --squash A..B", a.k.a
a "partial merge". (And if it could be implemented to allow a "git merge A..B"
and later do a "git merge B" to merge the rest of the side-branch, that
would be interesting).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* rerere failed to parse conflict hunks
From: Uwe Kleine-König @ 2009-12-09 8:46 UTC (permalink / raw)
To: git
Hello,
I just tried to merge linux-next
(5c1af82119f11c5b322156b09d38cc37318849c4) into my private tree
(based on 2b876f95d03e226394b5d360c86127cbefaf614b) and this
happened:
...
Removing sound/soc/au1x/sample-ac97.c
Recorded preimage for 'arch/Kconfig'
Recorded preimage for 'arch/arm/mach-s3c2440/mach-anubis.c'
Recorded preimage for 'arch/arm/plat-mxc/Makefile'
error: Could not parse conflict hunks in arch/arm/plat-s3c/dev-hsmmc2.c
Recorded preimage for 'arch/arm/plat-s3c/include/plat/sdhci.h'
Recorded preimage for 'arch/arm/plat-samsung/Kconfig'
Recorded preimage for 'arch/x86/include/asm/x86_init.h'
Recorded preimage for 'arch/x86/kernel/x86_init.c'
Recorded preimage for 'drivers/net/wireless/ray_cs.c'
Recorded preimage for 'kernel/Makefile'
Recorded preimage for 'kernel/power/hibernate.c'
Recorded preimage for 'net/sctp/sysctl.c'
Automatic merge failed; fix conflicts and then commit the result.
If you are interested, I can provide you the two trees above. When
reproducing the line "error: ..." came later, but is still present.
I guess this should be reproduceable with
git clone -n git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
git remote add -f next git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
git checkout 2b876f95d03e226394b5d360c86127cbefaf614b
git merge 5c1af82119f11c5b322156b09d38cc37318849c4
I havn't tried though.
The only non-trivial conflict is:
#include <plat/sdhci.h>
#include <plat/devs.h>
<<<<<<< HEAD
=======
<<<<<<< HEAD
#include <plat/cpu.h>
=======
>>>>>>> next-s5pc1xx
>>>>>>> next/master
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox