Jeff King <peff@xxxxxxxx> wrote: > On Mon, Dec 04, 2006 at 10:09:17PM -0800, Junio C Hamano wrote: > > > Should I take these responses to mean that you two are negative > > about the approach of spending extra cycles to commands that can > > leave the working tree in a "in the middle of doing something" > > state to help having a unified command to explain what the > > situation is and suggest the user possible exits, or are you > > saying that it might be a good idea but "git explain" is a bad > > name? > > It seems like the point of this command is to show some state > information which would otherwise be hard to see. I think of 'git > status' as the way to look at the repository state. Perhaps we should > enhance the output of 'git status' to note things such as failed merges, > whether we're bisecting, in the middle of applying a patch series, etc. > There could be an optional verbosity switch to give "full explanations" > including recommended ways to deal with the situation. I wholeheartedly agree that 'git status' should show something like this. I actually had some stuff that was a work-in-progress several months ago that enhanced status with several things like this; but got distracted and forgot about that repository. I'll try to dig it out sometime tomorrow. I remember my work started from wanting to know what 'git-rerere' would be recording. -- Eric Wong - 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