From: Shawn O. Pearce Date: Wed, 28 May 2008 23:45:54 GMT Subject: Re: [PATCH] Completion: Hint whether amend is the right thing to do. Message-ID: <20080528234554.GO30245@spearce.org> In-Reply-To: <7vlk1urob4.fsf@gitster.siamese.dyndns.org> Junio C Hamano wrote: > Robin Rosenberg writes: > > > onsdagen den 28 maj 2008 17.53.40 skrev Junio C Hamano: > >> Does this mean that it would help reduce mistakes if "git commit --amend" > >> noticed the presense of .dotest-merge but absense of .dotest-merge/amend > >> and refused to operate, I have to wonder? > > > > Well I found myself making these mistakes. That would probably be better. > > Shouldn't one block commit without amend too then? > > If you mean to forbid "git commit" during rebase (perhaps interrupted by > s/pick/edit/), I do not think that would fly -- it is the advertised way > to split a commit into two, if I am not mistaken. Right, you don't want to block commit if we stopped for an edit. But if we stopped because merge-recursive failed due to merge conflicts we want the user to fix up the tree, stage the changes, and call `git rebase --continue` to let rebase continue further. If further means finish the commit and then immediately stop (as we had failed while picking an edit) , rebase will stop and let the user edit. We don't need a special flag for rebase to pass to commit, it can just delete the state flag that prevents commits just before it calls commit. -- Shawn.