Hi,
On Sat, 3 May 2008, Junio C Hamano wrote:
Johannes Schindelin [off-list ref] writes:
quoted
quoted
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