Re: [RFC] improving advice message from "git commit" during a merge
Stefan Beller writes: > On 27.08.2014 20:23, Junio C Hamano wrote: >> I am not doing this myself soon, though. Hint, hint... > > I asked once upon a time, if there was a place, > which collects such topics for casual contributors and new comers. > > Would you mind to update the leftover bits at > http://git-blame.blogspot.de/search?q=leftover&by-date=true > ? They live in a bit more permanent home at http://git-blame.blogspot.com/p/leftover-bits.html these days. It is too early to tell this particular one will make an entry there yet ;-) -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] improving advice message from "git commit" during a merge
On 27.08.2014 20:23, Junio C Hamano wrote: > I am not doing this myself soon, though. Hint, hint... I asked once upon a time, if there was a place, which collects such topics for casual contributors and new comers. Would you mind to update the leftover bits at http://git-blame.blogspot.de/search?q=leftover&by-date=true ? Thanks, Stefan -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] improving advice message from "git commit" during a merge
Jeff King writes: >> - When all the unmerged paths have their conflicts resolved in the >>working tree, we do not have to say "Fix them up in the work >>tree,". We can instead say "You seem to have fixed them up in >>the work tree already," or something. > > How are you determining what has been resolved? By looking for "<<<" > markers? That feels a little flaky, but I guess it would probably work > well enough in practice. I was going to say "whatever rerere does" by reusing whatever it has already implemented. > If we started using that heuristic, it would probably make sense to > teach "git status" about it (and then maybe just have a failed "commit" > rely on wt_status to produce the output). > >> I am not doing this myself soon, though. Hint, hint... > > Me either, though it all seems like a sensible direction to me. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] improving advice message from "git commit" during a merge
On Wed, Aug 27, 2014 at 11:23:08AM -0700, Junio C Hamano wrote: > When there are unmerged paths, you would often get something like > this: > > [git.git (pu|MERGING]$ git commit > U copy.c > U wrapper.c > error: commit is not possible because you have unmerged files. > hint: Fix them up in the work tree, and then use 'git add/rm ' > hint: as appropriate to mark resolution and make a commit, or use > hint: 'git commit -a'. > fatal: Exiting because of an unresolved conflict. > > which is all good and correct, but I am wondering if we can be a bit > more helpful by customizing the message in various ways. > > - When all the unmerged paths have their conflicts resolved in the >working tree, we do not have to say "Fix them up in the work >tree,". We can instead say "You seem to have fixed them up in >the work tree already," or something. How are you determining what has been resolved? By looking for "<<<" markers? That feels a little flaky, but I guess it would probably work well enough in practice. If we started using that heuristic, it would probably make sense to teach "git status" about it (and then maybe just have a failed "commit" rely on wt_status to produce the output). > I am not doing this myself soon, though. Hint, hint... Me either, though it all seems like a sensible direction to me. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFC] improving advice message from "git commit" during a merge
When there are unmerged paths, you would often get something like this: [git.git (pu|MERGING]$ git commit U copy.c U wrapper.c error: commit is not possible because you have unmerged files. hint: Fix them up in the work tree, and then use 'git add/rm ' hint: as appropriate to mark resolution and make a commit, or use hint: 'git commit -a'. fatal: Exiting because of an unresolved conflict. which is all good and correct, but I am wondering if we can be a bit more helpful by customizing the message in various ways. - When all the unmerged paths have their conflicts resolved in the working tree, we do not have to say "Fix them up in the work tree,". We can instead say "You seem to have fixed them up in the work tree already," or something. - When some of the unmerged paths have their conflicts still in the working tree, we can name them separately from the ones that have already been dealt with. U copy.c U wrapper.c (conflicts already resolved in the working tree) - Hasty-and-careless new users will be incorrectly enticed to type the command given by "or use 'git commit -a'" at the end of this advice message without thinking. Perhaps it is safer to stop the sentence at "... and make a commit." and drop that last bit while there are conflicts still in the working tree files. We should use the current end-of-message only when all the conflicts have been resolved in the working tree. - The "/rm" in "use 'git add/rm '" is often useless, as it is much rarer to remove a path than adding one. Perhaps show that part only when there is a conflicted path with stage #2 but not stage #3 (i.e. they kept what we removed) or vice versa. "add" needs to stay there no matter what, as that is how we tell the index "this is the final content". I am not doing this myself soon, though. Hint, hint... -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
