<div dir="ltr">On Mon, Feb 20, 2012 at 8:47 AM, Martin Geisler <<a href="mailto:mg@lazybytes.net">mg@lazybytes.net</a>> wrote:<br>><br>> Idan Kamara <<a href="mailto:idankk86@gmail.com">idankk86@gmail.com</a>> writes:<br>
><br>> > On Sat, Feb 18, 2012 at 12:05 AM, Matt Mackall <<a href="mailto:mpm@selenic.com">mpm@selenic.com</a>> wrote:<br>> >><br>> >> On Fri, 2012-02-17 at 18:44 +0100, Patrick Mézard wrote:<br>
> >> > Le 02/02/12 13:55, Idan Kamara a écrit :<br>> >> > > On Thu, Feb 2, 2012 at 2:45 PM, Angel Ezquerra <<br>> > <a href="mailto:angel.ezquerra@gmail.com">angel.ezquerra@gmail.com</a> <mailto:<a href="mailto:angel.ezquerra@gmail.com">angel.ezquerra@gmail.com</a>>> wrote:<br>
> >> > ><br>> >> > >     On Thu, Feb 2, 2012 at 1:35 PM, Idan Kamara<br>> >> > > <<a href="mailto:idankk86@gmail.com">idankk86@gmail.com</a><mailto:<a href="mailto:idankk86@gmail.com">idankk86@gmail.com</a>>> wrote:<br>
> >> > >     > # HG changeset patch<br>> >> > >     > # User Idan Kamara <<a href="mailto:idankk86@gmail.com">idankk86@gmail.com</a><br>> >> > > <mailto:<a href="mailto:idankk86@gmail.com">idankk86@gmail.com</a>>><br>
> >> > >     > # Date 1328185747 -7200<br>> >> > >     > # Branch stable<br>> >> > >     > # Node ID cc7dec00d5016f03acf789c35ce6ef50b204f0cb<br>> >> > >     > # Parent  0620421044a2bcaafd054a6ee454614888699de8<br>
> >> > >     > commit: add --amend option to amend the parent changeset<br>> >> ><br>> >> > [...]<br>> >> ><br>> >> > ><br>> >> > >     This is quite cool and a neat example of what can be done now<br>
> >> > >     that mercurial tracks phases :-)<br>> >> > ><br>> >> > >     One thing that would be nice is to be able to just "amend"<br>> >> > >     the commit message (without modifying the patch file<br>
> >> > >     contents). I think _that_ is probably _the_ most commonly<br>> >> > >     requested history editing operation (at least in my<br>> >> > >     experience).<br>> >> > ><br>
> >> > ><br>> >> > > Right. I didn't take care of that yet and due to the current<br>> >> > > implementation it fails with a 'nothing changed' message. But it<br>> >> > > should be doable.<br>
> >> ><br>> >> > I think the UI for this should be addressed right away. What are<br>> >> > the choices?<br>> >> ><br>> >> > 1- git commit --amend: open the editor with the current message all<br>
> >> > the time, even when the working directory is clean<br>> >> > 2- Add qrefresh like --edit option<br>> >><br>> >> I don't think launching and quitting an editor is overly burdensome,<br>
> >> especially given that fixing a commit message will be an extremely<br>> >> common usage.<br>> ><br>> > I agree. And even if we end up having to choose between:<br>> ><br>> > 1) adding a new command<br>
> > 2) adding --edit to commit<br>> ><br>> > I think 2) is preferable. Same goes for -U and -D.<br>><br>> I never use the -U and -D options for qrefresh and I don't even think<br>> the --amend flag for commit should support it. Ammend means "redo the<br>
> very last commit" and so the user and date is already given by "this<br>> user" and "now".<div><br></div><div>I never use them either but the impression I got from most commands</div><div>
with similar behavior to --amend is that they preserve the old</div><div>date/user and have an option to refresh those.</div><div><br></div><div>So in my opinion we should keep the old date/user by default and</div><div>add -U/-D later on if there's enough need (rather than doing the opposite</div>
<div>and end up adding --keep-user/date).</div><div><br><div>><br>> In that way, 'hg commit --amend' becomes very much like<br>><br>>  hg rollback; hg commit -l .hg/last-message.txt<br>><br>> with the twist that the editor is started even though a commit message<br>
> is given on the command line.<br><div><br></div><div><div>Sometimes you might be doing several commits and only when you're</div><div>about to push you review them and realize you've made a mistake.</div></div>
<div><br></div><div>So I think it's also useful to amend a changeset with children (and</div><div>then manually rebasing those to the amended commit, which raises the</div><div>question whether rebase preserves date/user, and it turns out it does).</div>
</div></div></div>