On Wed, 2015-07-08 at 16:23 -0700, Junio C Hamano wrote: > Johannes Sixt <j6t@xxxxxxxx> writes: > > >> We could reduce the number from two to one by providing a new > >> git-am-status command which outputs one of "CHERRY-PICKING", > >> "REVERTING", or "" (or maybe it would also handle rebase and am). We > >> could also generalize it to "git-prompt-helper" or something by moving > >> that entire bunch of if statements inside. This would replace calls to > >> "git describe". > >> > >> But you probably have a better idea. > > > > Isn't it mere coincidence that the content of these two files looks > > like a non-packed ref? Wouldn't it be better to consider the two akin > > to MERGE_HEAD (which is not a ref because it records more than just a > > commit name)? > > That is an excellent thought that seems to have escaped everybody > involved in the review. > > These things do not behave like refs. They do not want reflogs (and > even if they had, the log would not mean much), and if we want to > add more information on the cherry-pick and revert in progress, they > are the most natural place to do so. > > Another thing that makes me vote for treating them just like > FETCH_HEAD, MERGE_HEAD and other ALL_CAPS files like COMMIT_MSG is > what should happen in a repository with more than one working trees. > You do not want to share what "CHERRY_PICK_HEAD" means across them > only because they happen to record an object name. I didn't see this until after I had sent my previous message. I think the "multiple working trees" argument is strong enough that I will change the code (and tests). -- 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