On Wed, Jun 2, 2010 at 23:37, Junio C Hamano <gitster@xxxxxxxxx> wrote:
> Ævar Arnfjörð Bjarmason <avarab@xxxxxxxxx> writes:
>>> In general, it might be helpful to warn very loudly upon doing a commit
>>> --amend after fixing conflicts, but an implementation would probably be
>>> ugly and for all I know, there might be people who frequently cause
>>> conflicts while amending; those guys would probably be quite annoyed at
>>> such a warning.
>>
>> I've also introduced the error Peter describes into my history because
>> I wasn't careful. That required some splitting / reflog fixes later.
>>
>> Perhaps the best way to solve this would be to change the content of
>> COMMIT_EDITMSG in cases like these so it gives you an explicit warning
>> about what you're about to do.
>>
>> We already do this for merges, from builtin/commit.c:
>
> Very good point. "Users are told when the command gives back control, is
> the best "rebase -i" could do, but by definition the users are free to
> shoot themselves in the foot when given control, and "commit --amend" is
> the only sensible place to give further safeguard against this issue.
As it happens I shot myself in the foot with this yesterday, here's a
log of what I did:
aoeu git (404M) $ git reset HEAD^
Unstaged changes after reset:
M .gitignore
M Makefile
M config.mak.in
M configure.ac
M git.c
M wt-status.c
aoeu git (404M) $ git st
M .gitignore
M Makefile
M config.mak.in
M configure.ac
M git.c
M wt-status.c
?? gettext.c
?? gettext.h
?? po/
aoeu git (404M) $ git diff
aoeu git (404M) $ git show
At this point the amend message should warn me that I'm about to
merge stuff into the previous commit:
aoeu git (404M) $ git commit --amend
Waiting for Emacs...
[detached HEAD f9d39c1379537fb3afdfba244c61a7328dc394f2] Merge
branch 'maint'
Author: Junio C Hamano <gitster@xxxxxxxxx>
aoeu git (404M) $ git st
M wt-status.c
?? gettext.c
?? gettext.h
?? po/
Actually, related to that I think this documentation section could use
some work:
http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html#_splitting_commits
At the time I was:
* Going back in my history
* Splitting apart some hunks to an older commit from that commit
* recommiting the altered commit, leaving its commit info alone
* Stashing the changes I'd removed into several stashes
* git rebase --continue and applying all the stashes to one big commit later
I.e.:
git rebase -i master
...
git reset HEAD^
git stash save --patch "stash git-pull.sh"
git add -u
git commit -c e06ef88fead1510587ff32715beaccf622dec2ce
git rebase --continue
The "Commit the now-current index with whatever commit message is
appropriate now" part of the docs assumes that you don't want to keep
your old commit info around for the new rewritten commit.
Anyway, </braindump>. This is just one example of how the rebase
process could be friendlier with some minor changes, and how the
documentation could be improved.
--
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