author | Jan Krüger <jk@jk.gs> | |
Sun, 30 May 2010 08:19:26 +0000 (10:19 +0200) | ||
committer | Junio C Hamano <gitster@pobox.com> | |
Tue, 1 Jun 2010 00:48:38 +0000 (17:48 -0700) | ||
commit | 05bdcfe5fc3d626b752c2cb574f05ed30b279bcf | |
tree | 31de3de69fa6bde0185b87663634636ad5648533 | tree | snapshot |
parent | 81fa024cd8e336ba257f13fe7724b95baacfa3ad | commit | diff |
git-am: suggest what to do with superfluous patches
Particularly in the context of rebase, conflicts frequently occur
because the change in the patch to be applied was made obsolete by new
upstream commits. In this case, solving the conflict effectively means
skipping the patch. However, it's not always readily apparent that the
patch needs to be skipped, and when people solve the conflict and try
git rebase --continue, they get confronted with a message of
No changes - did you forget to use 'git add'?
That's not very helpful if you did actually stage your changes and they
happen to turn the patch into a no-op. This extends the message to point
out what's going on.
Signed-off-by: Jan Krüger <jk@jk.gs>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Particularly in the context of rebase, conflicts frequently occur
because the change in the patch to be applied was made obsolete by new
upstream commits. In this case, solving the conflict effectively means
skipping the patch. However, it's not always readily apparent that the
patch needs to be skipped, and when people solve the conflict and try
git rebase --continue, they get confronted with a message of
No changes - did you forget to use 'git add'?
That's not very helpful if you did actually stage your changes and they
happen to turn the patch into a no-op. This extends the message to point
out what's going on.
Signed-off-by: Jan Krüger <jk@jk.gs>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-am.sh | diff | blob | history |