rebase: add --revisions flag

Add --revisions flag to rebase, so that it can be used to apply an arbitrary range of commits on top of a current branch.

Signed-off-by Michael S. Tsirkin <[email protected]>

---

I've been wishing for this functionality for a while now, so here goes. This isn't yet properly documented and I didn't write a test, but the patch seems to work fine for me. Any early flames/feedback?

Quoted 11 lines · Michael S. Tsirkin

Add --revisions flag to rebase, so that it can be used to apply an arbitrary range of commits on top of a current branch.

Signed-off-by Michael S. Tsirkin <[email protected]>

---

I've been wishing for this functionality for a while now, so here goes. This isn't yet properly documented and I didn't write a test, but the patch seems to work fine for me. Any early flames/feedback?

This pretty much reverses what rebase normally does. Instead of "rebase this onto that" it's "'rebase' that onto this". And instead of updating the branch head that got rebased, the, uhm, "upstream" gets updated.

Also, AFAICT this needs to be called like this:
git rebase --revisions foo..bar HEAD

Changing the meaning of the <upstream> argument and relying on the fact that <newbase> defaults to <upstream>. If such a thing gets added, it should rather work like --root, not using <upstream> at all, but --onto <newbase> only. Maybe defaulting to HEAD for <newbase> and making --onto optional, as it's reversed WRT what it does compared to the usual rebase.

But generally, I'd say it would be better to add such a range feature to cherry-pick than abusing rebase for that.

Björn

Quoted 20 lines · Björn Steinbrink

Quoted 11 lines · Michael S. Tsirkin

Add --revisions flag to rebase, so that it can be used to apply an arbitrary range of commits on top of a current branch.

Signed-off-by Michael S. Tsirkin <[email protected]>

---

I've been wishing for this functionality for a while now, so here goes. This isn't yet properly documented and I didn't write a test, but the patch seems to work fine for me. Any early flames/feedback?

This pretty much reverses what rebase normally does. Instead of "rebase this onto that" it's "'rebase' that onto this". And instead of updating the branch head that got rebased, the, uhm, "upstream" gets updated.

Also, AFAICT this needs to be called like this:
git rebase --revisions foo..bar HEAD

Quoted 6 lines

Changing the meaning of the <upstream> argument and relying on the fact that <newbase> defaults to <upstream>. If such a thing gets added, it should rather work like --root, not using <upstream> at all, but --onto <newbase> only. Maybe defaulting to HEAD for <newbase> and making --onto optional, as it's reversed WRT what it does compared to the usual rebase.

Sorry, I had trouble parsing the above. Could you suggest e.g. how the help line should look?

Quoted 2 lines

But generally, I'd say it would be better to add such a range feature to cherry-pick than abusing rebase for that.

The reason to use rebase is that I often want to combine this with -i flag, editing patches as they are applied.

Quoted 28 lines · Michael S. Tsirkin

Quoted 20 lines · Björn Steinbrink

Quoted 11 lines · Michael S. Tsirkin

Add --revisions flag to rebase, so that it can be used to apply an arbitrary range of commits on top of a current branch.

Signed-off-by Michael S. Tsirkin <[email protected]>

---

I've been wishing for this functionality for a while now, so here goes. This isn't yet properly documented and I didn't write a test, but the patch seems to work fine for me. Any early flames/feedback?

This pretty much reverses what rebase normally does. Instead of "rebase this onto that" it's "'rebase' that onto this". And instead of updating the branch head that got rebased, the, uhm, "upstream" gets updated.

Also, AFAICT this needs to be called like this:
git rebase --revisions foo..bar HEAD

Quoted 6 lines

Changing the meaning of the <upstream> argument and relying on the fact that <newbase> defaults to <upstream>. If such a thing gets added, it should rather work like --root, not using <upstream> at all, but --onto <newbase> only. Maybe defaulting to HEAD for <newbase> and making --onto optional, as it's reversed WRT what it does compared to the usual rebase.

Quoted 2 lines

Sorry, I had trouble parsing the above. Could you suggest e.g. how the help line should look?

Current:
git rebase [-i | --interactive] [options] [--onto <newbase>]

	<upstream> [<branch>]
git rebase [-i | --interactive] [options] --onto <newbase>
	--root [<branch>]

Add:
git rebase [-i | --interactive] [options] --revisions <range> [<branch>]

(Thinking about it, I guess an explicit --onto makes no sense with the --revisions flag)

Quoted 5 lines

Quoted 2 lines

But generally, I'd say it would be better to add such a range feature to cherry-pick than abusing rebase for that.

The reason to use rebase is that I often want to combine this with -i flag, editing patches as they are applied.

Hm, well, your patch didn't touch git-rebase--interactive.sh ;-)

Björn

Quoted 22 lines · Björn Steinbrink

Quoted 10 lines

Quoted 9 lines

Also, AFAICT this needs to be called like this:
git rebase --revisions foo..bar HEAD

Changing the meaning of the <upstream> argument and relying on the fact that <newbase> defaults to <upstream>. If such a thing gets added, it should rather work like --root, not using <upstream> at all, but --onto <newbase> only. Maybe defaulting to HEAD for <newbase> and making --onto optional, as it's reversed WRT what it does compared to the usual rebase.

Quoted 2 lines

Sorry, I had trouble parsing the above. Could you suggest e.g. how the help line should look?

Current:
git rebase [-i | --interactive] [options] [--onto <newbase>]

	<upstream> [<branch>]
git rebase [-i | --interactive] [options] --onto <newbase>
	--root [<branch>]

Add:
git rebase [-i | --interactive] [options] --revisions <range> [<branch>]

Quoted 2 lines

(Thinking about it, I guess an explicit --onto makes no sense with the --revisions flag)

I agree.
So this is different from what I implemented basically only in that we should disallow combining --onto with --revisions. Right?

Quoted 7 lines · Michael S. Tsirkin

Add --revisions flag to rebase, so that it can be used to apply an arbitrary range of commits on top of a current branch.

Signed-off-by Michael S. Tsirkin <[email protected]>

---

Quoted 4 lines

I've been wishing for this functionality for a while now, so here goes. This isn't yet properly documented and I didn't write a test, but the patch seems to work fine for me. Any early flames/feedback?

This pretty much reverses what rebase normally does. Instead of "rebase this onto that" it's "'rebase' that onto this". And instead of updating the branch head that got rebased, the, uhm, "upstream" gets updated.

Quoted 13 lines · Björn Steinbrink

Quoted 11 lines · Michael S. Tsirkin

Add --revisions flag to rebase, so that it can be used to apply an arbitrary range of commits on top of a current branch.

Signed-off-by Michael S. Tsirkin <[email protected]>

---

I've been wishing for this functionality for a while now, so here goes. This isn't yet properly documented and I didn't write a test, but the patch seems to work fine for me. Any early flames/feedback?

Quoted 3 lines

This pretty much reverses what rebase normally does. Instead of "rebase this onto that" it's "'rebase' that onto this". And instead of updating the branch head that got rebased, the, uhm, "upstream" gets updated.

The last sentence is wrong I think - it is still the branch head that is updated.

Quoted 14 lines · Michael S. Tsirkin

Quoted 13 lines · Björn Steinbrink

Quoted 11 lines · Michael S. Tsirkin

Add --revisions flag to rebase, so that it can be used to apply an arbitrary range of commits on top of a current branch.

Signed-off-by Michael S. Tsirkin <[email protected]>

---

I've been wishing for this functionality for a while now, so here goes. This isn't yet properly documented and I didn't write a test, but the patch seems to work fine for me. Any early flames/feedback?

Quoted 6 lines

Quoted 3 lines

This pretty much reverses what rebase normally does. Instead of "rebase this onto that" it's "'rebase' that onto this". And instead of updating the branch head that got rebased, the, uhm, "upstream" gets updated.

The last sentence is wrong I think - it is still the branch head that is updated.

But you don't rebase the branch head. Before the rebase, the branch head doesn't reference the commits that get rebased. For example:

git checkout bar
git rebase --revisions foo bar

You "rebase" the commits in foo's history, but you update bar.

WRT the result, the above command should be equivalent to:
git checkout bar
git reset --hard foo
git rebase --root --onto ORIG_HEAD;

And here, the commits currently reachable through "bar" are rebased, and "bar" also gets updated.

Björn

Quoted 25 lines · Björn Steinbrink

Quoted 14 lines · Michael S. Tsirkin

Quoted 13 lines · Björn Steinbrink

Quoted 11 lines · Michael S. Tsirkin

Add --revisions flag to rebase, so that it can be used to apply an arbitrary range of commits on top of a current branch.

Signed-off-by Michael S. Tsirkin <[email protected]>

---

I've been wishing for this functionality for a while now, so here goes. This isn't yet properly documented and I didn't write a test, but the patch seems to work fine for me. Any early flames/feedback?

Quoted 6 lines

Quoted 3 lines

This pretty much reverses what rebase normally does. Instead of "rebase this onto that" it's "'rebase' that onto this". And instead of updating the branch head that got rebased, the, uhm, "upstream" gets updated.

The last sentence is wrong I think - it is still the branch head that is updated.

But you don't rebase the branch head. Before the rebase, the branch head doesn't reference the commits that get rebased. For example:

Quoted 4 lines

git checkout bar
git rebase --revisions foo bar

You "rebase" the commits in foo's history, but you update bar.

Yes, that's the who point of the patch.

The above applies a single commit, foo, on top of current branch bar.

Quoted 6 lines

WRT the result, the above command should be equivalent to:
git checkout bar
git reset --hard foo
git rebase --root --onto ORIG_HEAD;

Quoted 2 lines

And here, the commits currently reachable through "bar" are rebased, and "bar" also gets updated.

So this
1. won't be very useful, as you show it is easy
to achieve with existing commands.

2. interprets "foo" as branch name as opposed to
revision range.

OTOH, rebase --revisions as I implemented is a "smarter cherry-pick" which can't easily be achieved with existing commands, especially if you add "-i".

Quoted 26 lines · Michael S. Tsirkin

Quoted 25 lines · Björn Steinbrink

Quoted 14 lines · Michael S. Tsirkin

Quoted 13 lines · Björn Steinbrink

Quoted 11 lines · Michael S. Tsirkin

Add --revisions flag to rebase, so that it can be used to apply an arbitrary range of commits on top of a current branch.

Signed-off-by Michael S. Tsirkin <[email protected]>

---

I've been wishing for this functionality for a while now, so here goes. This isn't yet properly documented and I didn't write a test, but the patch seems to work fine for me. Any early flames/feedback?

Quoted 6 lines

Quoted 3 lines

This pretty much reverses what rebase normally does. Instead of "rebase this onto that" it's "'rebase' that onto this". And instead of updating the branch head that got rebased, the, uhm, "upstream" gets updated.

The last sentence is wrong I think - it is still the branch head that is updated.

But you don't rebase the branch head. Before the rebase, the branch head doesn't reference the commits that get rebased. For example:

Quoted 6 lines

Quoted 4 lines

git checkout bar
git rebase --revisions foo bar

You "rebase" the commits in foo's history, but you update bar.

Yes, that's the who point of the patch.

Yes, and it's "backwards" compared to the existing "rebase" modes, but more like "cherry-pick".

Quoted 1 line

The above applies a single commit, foo, on top of current branch bar.

Hm, no. I expected it to turn all commits reachable from foo into patches and applying them to bar. But actually, that should hit the special <since> mode of format-patch. So
git rebase --revisions foo bar
is (with your patch) actually the same as
git rebase foo bar

So actually the example should have been:
git rebase --root --revisions foo bar

Both invocations probably mess up the diff-stat as that becomes:
git diff --stat --summary foo
So it creates a diffstat of the diff from the working tree to "foo", which can't be right.

Quoted 6 lines

Quoted 6 lines

WRT the result, the above command should be equivalent to:
git checkout bar
git reset --hard foo
git rebase --root --onto ORIG_HEAD;

Quoted 6 lines

Quoted 2 lines

And here, the commits currently reachable through "bar" are rebased, and "bar" also gets updated.

So this
1. won't be very useful, as you show it is easy
to achieve with existing commands.

One can "almost" achieve it.
git rebase --revision A..B foo

is about the same as:
git checkout foo
git reset --hard B
git rebase --onto ORIG_HEAD A

But:
a) The "reset --hard" obviously lacks the safety checks for clean index/working tree.
b) "git rebase --abort" won't take you back to your initial state, but to B.
c) It's not really obvious that you can do it and how to do it.

Another possibility would be:

git checkout B^0 # detach HEAD at B
git rebase foo # rebase onto foo
git checkout foo
git merge HEAD@{1} # Fast-forwards foo to the rebased stuff

That fixes a), avoid b) [because you don't mess up any branch head early] but is still subject to c).

And for both methods, the ORIG_HEAD and HEAD@{1} arguments are somewhat "unstable", e.g. checking out the wrong branch head first, and only then the correct one, you'd have to use HEAD@{2} instead of HEAD@{1} (because the reflog for HEAD got a new entry).

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.

Quoted 2 lines

2. interprets "foo" as branch name as opposed to
revision range.

Well, a single committish is a "range" as far as the range-based commands are concerned, e.g. "git log master" treats "master" to mean all commits reachable it. If "rebase --revisions master" would do the same, that's at least consistent (and for single commit picks, there's already cherry-pick). The problem with your patch is that it passes the revision argument to format-patch as is, and:
git format-patch foo
is the same as
git format-patch foo..HEAD

Quoted 3 lines

OTOH, rebase --revisions as I implemented is a "smarter cherry-pick" which can't easily be achieved with existing commands, especially if you add "-i".

And that "is a 'smarter cherry-pick'" is why I think that rebase is actually the wrong command to get that feature. While rebase internally does just mass-cherry-picking, it does that with commits in the current branch onto a specified branch. The --revisions flag makes it do things the other way around.

Björn

Quoted 5 lines · Björn Steinbrink

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:

(quoted diff) +0 -1

-	Imagine developing a patchset with a complex bugfix on master branch.

Then I decide to also apply (backport) this patchset to stable branch.

(quoted diff) +0 -1

-	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.

(quoted diff) +0 -1

-	I have a large queue of patches on staging branch, I decide that

a range of patches is mature enough for master.

Quoted 7 lines · Michael S. Tsirkin

Quoted 5 lines · Björn Steinbrink

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.

Quoted 3 lines

I need this often for many reasons:

(quoted diff) +0 -1

-	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.

Quoted 3 lines

(quoted diff) +0 -1

-	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.

Quoted 2 lines

(quoted diff) +0 -1

-	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

OTOH, rebase --revisions as I implemented is a "smarter cherry-pick" which can't easily be achieved with existing commands, especially if you add "-i".

Add --revisions flag to rebase, so that it can be used to apply an arbitrary range of commits on top of a current branch.

Quoted 3 lines · Michael S. Tsirkin

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?

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".

Junio C Hamano:

Quoted 3 lines

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).

Signature · 1 line

\\// Peter - http://www.softwolves.pp.se/

Quoted 1 line

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?

Michael S. Tsirkin:

Quoted 3 lines

Quoted 2 lines

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.

Björn Steinbrink:

Quoted 4 lines

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.

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 Steinbrink:

Quoted 4 lines

"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.

I know, this is the one "feature" of CVS that I sometimes miss in Git, that I cannot "merge" just parts of a history, and have that recorded in the history tree. I know it's wrong, I know I could do it better, but sometimes it's the shortcut that would make life easier for me. :-)

But the reason I mentioned it was because of the discussion on whether the "reverse rebase" should be an option to "cherry-pick" or not, and I mentioned that it could just as well be "merge" since it can be used to throw away history as well.

Quoted 5 lines

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.

And tell "merge" to tell me that if I try, so that if I try

  $ git merge A..B

I would get a message saying something like

Cannot merge a range of commits. Try "git cherry-pick A..B" or "git rebase --reverse A..B".

And perhaps we could also in the same way retire --squash?

  $ git merge --squash B
  The "--squash" option is obsolete. Please use "git cherry-pick
  --squash B".

(with a transition period where it would just call the other). Or whatever the options to simulate the old behaviour would be. This would make it clearer that "merge" preserves history while "cherry-pick" and "rebase" do not.

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"

Quoted 4 lines · 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. For example:

Quoted 6 lines

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"?

Quoted 10 lines · Andreas Schwab

Quoted 8 lines · 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. For example:

A---B---C (master)
\
D---E---F (foo)

Quoted 4 lines

Quoted 2 lines

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

Quoted 14 lines · Björn Steinbrink

Quoted 13 lines · Andreas Schwab

Quoted 10 lines · 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. 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"

Quoted 3 lines

Quoted 1 line

Did you mean "git diff E F"?

Ugh, yes, of course. Thanks.

So this will be best written as
git cherry-pick ..foo

"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".

Quoted 5 lines · Björn Steinbrink

"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 agree with this to some degree, but I do not offhand think of a better alternative.

At the first sight, it looks as if what "merge --squash" does was implemented as a new option "--squash" to the "merge" command merely because the way _how_ it internally needs to compute the result was already available in the implementation of "merge" command, and not necessarily because _what_ it does was conceptually consistent with the way "merge" works.

But at the conceptual level, "merge --squash" is a short-hand for this command sequence:

git rebase -i HEAD that-branch
... make everything except the first one into "squash" git checkout - ;# come back to the original branch git merge that-branch ;# fast forward to it

So after all, it is "merge it after squashing them".

Quoted 9 lines

But at the conceptual level, "merge --squash" is a short-hand for this command sequence:

git rebase -i HEAD that-branch
... make everything except the first one into "squash" git checkout - ;# come back to the original branch git merge that-branch ;# fast forward to it

So after all, it is "merge it after squashing them".

To me, that approach looks backwards,...

Quoted 8 lines · Björn Steinbrink

Quoted 8 lines

But at the conceptual level, "merge --squash" is a short-hand for this command sequence:

git rebase -i HEAD that-branch
... make everything except the first one into "squash" git checkout - ;# come back to the original branch git merge that-branch ;# fast forward to it

Quoted 3 lines

Quoted 1 line

So after all, it is "merge it after squashing them".

To me, that approach looks backwards,...

Yes, of course, but what you are missing (and I am at blame for forgetting to mention the history behind this in the message you are responding to) is that "merge --squash" to support a particular need/use case was done way before "rebase -i" came into existence.

A nicer workflow may be to use "rebase -i" to clean up the history before even contemplating to integrate the topic to the mainline, instead of the above "abandoning or forking off again", if you know today's git.

But interactive was not available back then. It was introduced at 1b1dce4 (Teach rebase an interactive mode, 2007-06-25), which is 1 year after 7d0c688 (git-merge --squash, 2006-06-23).

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.

Heya,

Quoted 5 lines · Junio C Hamano

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.

Speaking of which, what's the status of git sequencer? I seem to remember some activity recently to slowly rewrite git rebase in c, but I haven't seen anything since then. Is it still moving forward? Is anyone interested in doing so? Just curious...

Hi,

Quoted 9 lines · Sverre Rabbelier

Heya,

Quoted 5 lines · Junio C Hamano

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.

Quoted 4 lines

Speaking of which, what's the status of git sequencer? I seem to remember some activity recently to slowly rewrite git rebase in c, but I haven't seen anything since then. Is it still moving forward? Is anyone interested in doing so? Just curious...

Last June and July, I sent some patch series to port "rebase -i" to C using code from the sequencer project. My goal was to save some interesting code from the sequencer GSoC 2008 project and at the same time to move forward "rebase -i" code toward a sequencer.

But Dscho and Junio didn't like the fact that the code from the sequencer I added was duplicating existing code and was not properly refactored, though it also added things that would be needed later for the sequencer. My plan was to refactor later, once I had a sequencer, but Junio and Dscho did not like that plan. They said it would be a too big maintenance burden.

So I agreed to not duplicate any existing code and to properly refactor everything. And I have been trying to take interesting and useful code from the sequencer project and to integrate it into existing commands. And this is why I sent yesterday the 4th version of my '"git reset --merge" related improvements' patch series.

After that I plan to work on cherry-pick and that could be useful to implement something like "git cherry-pick A..B".

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.

Quoted 7 lines · Junio C Hamano

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.

Signature · 2 lines

Matthieu Moy
http://www-verimag.imag.fr/~moy/

Quoted 14 lines · Matthieu Moy

Quoted 7 lines · Junio C Hamano

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

Quoted 6 lines

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?

Quoted 15 lines · Michael S. Tsirkin

Quoted 14 lines · Matthieu Moy

Quoted 7 lines · Junio C Hamano

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

Quoted 8 lines

Quoted 6 lines

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

Perhaps "git rebase --cherry-pick A..B" would be a better name. No objection for --opposite either.

Quoted 3 lines · Michael S. Tsirkin

Add --revisions flag to rebase, so that it can be used to apply an arbitrary range of commits on top of a current branch.

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.