Re: [PATCH v2 04/13] Teach rebase interactive the mark command

[Johannes Schindelin <Johannes.Schindelin@gmx.de>]

Hi,

On Sat, 3 May 2008, Junio C Hamano wrote:

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> >> And I try to stress that while we are still in the drawing board 
> >> phase, because it would be painful to change once we start with a 
> >> language without enough expressiveness.
> >
> > Unfortunately, we are no longer in the drawing board phase, because 
> > the offending code is already in 'next'.
> 
> What does that mean?  "Now we are committed to it, so I will stop 
> complaining and work within the overall design in a more constructive 
> way"?

Fine.

I think that the "mark" mechanism is a fine thing for scripts that import 
into Git.  There, the limitation to integers in a certain range does not 
hurt.

The "mark" mechanism could even be used to implement a user-friendly 
rebase -i -p, but I think that _exposing_ it is a mistake.

Sure, I could imagine that _editing_ a list of commits, you want to mark a 
commit (why not "tag", which would be much more consistent with the rest 
of Git?), but name it something human-readable, such as

	pick 1234567 Clean up rebase -i -p
	tag cleanup
	...
	merge 2345678 cleanup master

Yes, you read that correctly, I think that allowing plain ref names is 
very valuable.  AFAICT my original implementation allows that (dunno about 
the current code).

I actually grow fonder and fonder of the ' idea (rewritten commits can be 
referenced by their short commit name with a single apostroph appended, 
and if that commit was not rewritten at all, it falls back to the original 
commit).

That should please you, and the other guy commenting on the "magic".

In the meantime I am also convinced that it could be implemented in an 
elegant way.

Ciao,
Dscho