Re: Heads up: major rebase -i -p rework coming up

4 messages, 3 authors, 2016-06-15 · open the first message on its own page

Re: Heads up: major rebase -i -p rework coming up

From: Junio C Hamano <hidden>
Date: 2016-06-15 22:46:01

Johannes Schindelin [off-list ref] writes:
	pick A
	pick C
	pick D
	goto A'
	pick B
	merge D' was E

This should lead to a much more intuitive user experience.

I am very sorry if somebody actually scripted rebase -i -p (by setting 
GIT_EDITOR with a script), but I am very certain that this cleanup is 
absolutely necessary to make rebase -i -p useful.
Three questions.

- An obvious one first.  How does this relate to the sequencer project (that
  seems to have gone somewhat dark?)

- What's with the apostrophe?  I seem to remember that you argued it would
  be enough to make "A" stand for the original when it is used for the
  first time and the second and later use can stand for the result of the
  last use (e.g. the "goto A'" above can be simply spelled as "goto A"),
  when I suggested to use "mark" in a way similar to how fast-import
  language uses it during the sequencer discussion?

  I am not complaining; I am just being curious why the sudden change of
  heart.

- Why do you need "merge D' was E"?  Shouldn't "pick E" be able to notice
  that E is a merge and decompose it into "merge D' was E" internally?

  This one I am somewhat complaining, unless your answer is "because this
  way the user could drop some parents from the merge in the editor".

  And if your answer is that, then my next question will be "if that is
  the case, can the user be expected to easily find out which commit each
  parent SHA-1 refers to, without having more hint on the 'merge' insn
  line?"

Re: Heads up: major rebase -i -p rework coming up

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:46:01

Hi,

On Sat, 24 Jan 2009, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
	pick A
	pick C
	pick D
	goto A'
	pick B
	merge D' was E

This should lead to a much more intuitive user experience.

I am very sorry if somebody actually scripted rebase -i -p (by setting 
GIT_EDITOR with a script), but I am very certain that this cleanup is 
absolutely necessary to make rebase -i -p useful.
Three questions.

- An obvious one first.  How does this relate to the sequencer project 
  (that seems to have gone somewhat dark?)
As far as I can see, Stephan can keep the "mark" command he cherishes so 
much, and we can still use thise syntax for rebase -i -p.
- What's with the apostrophe?  I seem to remember that you argued it 
  would be enough to make "A" stand for the original when it is used for 
  the first time and the second and later use can stand for the result 
  of the last use (e.g. the "goto A'" above can be simply spelled as 
  "goto A"), when I suggested to use "mark" in a way similar to how 
  fast-import language uses it during the sequencer discussion?

  I am not complaining; I am just being curious why the sudden change of 
  heart.
Very easy explanation.  I got convinced by your arguments.  Even if I 
could imagine that I never use the thing without apostrophe, it is good to 
have an obvious indicator that this is not necessarily the original 
commit.
- Why do you need "merge D' was E"?  Shouldn't "pick E" be able to 
  notice that E is a merge and decompose it into "merge D' was E" 
  internally?

  This one I am somewhat complaining, unless your answer is "because 
  this way the user could drop some parents from the merge in the 
  editor".
Not only that; the user could use this to fix mismerges, i.e. by replacing 
a SHA-1 with the SHA-1 (or indeed, a short name, unless it is "was") of 
the branch that she _actually_ wanted to merge with.
  And if your answer is that, then my next question will be "if that is 
  the case, can the user be expected to easily find out which commit 
  each parent SHA-1 refers to, without having more hint on the 'merge' 
  insn line?"
Nope.

In most cases, however, that should be plenty enough:

	merge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next

The user does not have to guess much what 9383af1 might refer to.

In case of octopodes, or when the commit message was changed, the user has 
to open another command line and look for herself, though.

Ciao,
Dscho

Re: Heads up: major rebase -i -p rework coming up

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:46:01

Hi,

On Sat, 24 Jan 2009, Johannes Schindelin wrote:
quoted
- Why do you need "merge D' was E"?  Shouldn't "pick E" be able to 
  notice that E is a merge and decompose it into "merge D' was E"  
  internally?

  This one I am somewhat complaining, unless your answer is "because 
  this way the user could drop some parents from the merge in the 
  editor".
Not only that; the user could use this to fix mismerges, i.e. by 
replacing a SHA-1 with the SHA-1 (or indeed, a short name, unless it is 
"was") of the branch that she _actually_ wanted to merge with.
quoted
  And if your answer is that, then my next question will be "if that 
  is the case, can the user be expected to easily find out which 
  commit each parent SHA-1 refers to, without having more hint on the 
  'merge' insn line?"
Nope.

In most cases, however, that should be plenty enough:

	merge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next

The user does not have to guess much what 9383af1 might refer to.
Heh, I think it is much easier than I thought:  How about this?

 	merge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next
	#   \ 9383af1 Revert previous two commits

Obviously, for octopodes, there would be multiple "#   \ <SHA-1> <oneline>" 
lines...

Ciao,
Dscho

Re: Heads up: major rebase -i -p rework coming up

From: Marc Branchaud <hidden>
Date: 2016-06-15 22:46:02

I'm sorry, but I just don't understand the purpose of 'was E' (or 
whatever syntax) in the merge command.  Why is there a need to refer to 
E at all?  The only reason I can think of is to replicate E's commit 
message.  Am I missing something?

Come to think of it, what if the user wants to edit a merge commit's 
message?  Should there be an 'editmerge' command?

		M.


Johannes Schindelin wrote:
quoted
- Why do you need "merge D' was E"?  Shouldn't "pick E" be able to 
  notice that E is a merge and decompose it into "merge D' was E" 
  internally?

  This one I am somewhat complaining, unless your answer is "because 
  this way the user could drop some parents from the merge in the 
  editor".
Not only that; the user could use this to fix mismerges, i.e. by replacing 
a SHA-1 with the SHA-1 (or indeed, a short name, unless it is "was") of 
the branch that she _actually_ wanted to merge with.
quoted
  And if your answer is that, then my next question will be "if that is 
  the case, can the user be expected to easily find out which commit 
  each parent SHA-1 refers to, without having more hint on the 'merge' 
  insn line?"
Nope.

In most cases, however, that should be plenty enough:

	merge 9383af1' was f39d50a Merge branch 'mh/unify-color' into next

The user does not have to guess much what 9383af1 might refer to.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help