Hi, On Sat, 3 May 2008, Junio C Hamano wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
