<div dir="ltr"><div class="gmail_quote">On Tue, Feb 21, 2012 at 10:22 AM, Arne Babenhauserheide <span dir="ltr"><<a href="mailto:arne_bab@web.de">arne_bab@web.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Am Montag, 20. Februar 2012, 15:42:21 schrieb Martin Geisler:<br>
<div class="im">> I don't think it's "semantically wrong" if your semantics is:<br>
><br>
>   hg commit --amend == hg rollback; hg commit<br>
><br>
> That's how I've thought of that hypothetical flag from the beginning.<br>
><br>
> I actually don't care much if it's a command or a flag, I'm just saying<br>
</div>> that I find it natural that a flag on commit would behave as rollback<br>
<div class="im">> plus a new commit (with updated timestamp, of course).<br>
<br>
</div>I think that this is the current usecase, because it is the only simple way to<br>
do it.<br>
<br>
But actually what I want is “make the last commit look like this”, while<br>
retaining the usual Mercurial promises (don’t break other peoples history,<br>
don’t lose work, don’t get too complicated, …).<br>
<br>
If the commit is in draft, I likely won’t need the old commit anymore.<br>
Possibly I actually don’t want it to ever propagate (because I committed a<br>
password or so).<br>
<br>
I might want it to be available to me, though, because I might make an error<br>
on the new commit which I might only catch by comparing it to the old one.<br></blockquote><div><br></div><div>If Mercurial could mark changesets as eligible for garbage collection it</div><div>would probably be a good fit to mark the amended commit as such.</div>
<div><br></div><div>Since it doesn't (for now?), all we can do is keep a backup which strip</div><div>already does (I didn't think it was necessary, but others might disagree).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
If it is already public, I will have to keep the old commit around (for me it<br>
looks like obsolete actually could provide ways for safely rewriting public<br>
history, because the obsolete changesets stay available, so it is just like an<br>
abandoned branch with the additional info “please rebase over here to<br>
integrate with the latest changes”).<br></blockquote><div><br></div><div>You shouldn't be able to amend public changesets. If you really want to</div><div>you could 'hg phase -f -d' it and then --amend will agree to do it.</div>
</div></div>