Hey, On Mon, Jun 6, 2011 at 9:14 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Michael J Gruber <git@xxxxxxxxxxxxxxxxxxxx> writes: > >>> That is why I asked what the user experience of "git show NEXT" as opposed >>> to "git show INDEX" should look like. So what should it look like during a >>> "pull" that did not finish? >> >> If NEXT is to mean the result of a commit in the current state, and the >> current state would or should not allow a commit, then trying to access >> that pseudo-commit should error out with a helpful message. > > What "helpful message"? I asked for the user experience, not handwaving. > > Do you mean to say that the error message would teach the user that the > current state is not something you can create a commit? What message would > that give the end user? ÂI am hoping the following is not what will happen: > > ÂQ. I tried "git show NEXT" because I wanted to see what the next commit > Â Â would look like, but I got an error, saying NEXT is not known as I > Â Â haven't resolved a conflict. > > ÂA. Yes, the message is correct. I'm not sure why this wouldn't just list out the index tree, having some message for entries that have more than one stage. Like a porcelain-ized version of 'git ls-files --stage', maybe in this case with a warning at the bottom that a subsequent commit command will not complete. Even something similar to what would happen if you ran 'commit' right then: fatal: 'commit' will not be possible because you have unmerged files. > ÂQ. But then how can I see what the next commit would look like? > > ÂA. You would say "git diff HEAD NEXT". > > ÂQ. Ah, that is the same as I always do before making a commit to see what > Â Â I have added so far look sane. Thanks. Why would this look sane? I would think this would say "* Unmerged path <file>" just like 'diff --cached would do. > > Â Â ...after 2 minutes... > > ÂQ. Sorry, it does not work. I get the same error, that says NEXT is not > Â Â known yet. > > ÂA. Ok, you would say "git diff HEAD" the old fashioned way. The person > Â Â who thought NEXT would be useful didn't think things through. I think the point would be that "git diff HEAD WTREE" would give you this same output and if you had the basic concept of these three important areas of Git that you could be explicit about what you wanted to see or compare rather than having to look up the specific special case that will show you what you want. Consider these very common scenarios from a new user perspective: you want to see what is changed in your working tree but not added yet, you want to see what is added but not committed, you want to see the sum total of all changes since your last commit and you want to see what the index currently looks like. Here are the commands currently: a) diff b) diff --cached c) diff HEAD d) ls-files --stage Here would be the commands with the proposed pseudo-trees. a) diff NEXT WTREE b) diff HEAD NEXT c) diff HEAD WTREE d) show NEXT It seems to me to be more guessable and straightforward for new users. But, yes, I assume there would be some difficulty in supporting it everywhere. > > ÂQ. Now I am seeing a diff between the conflicted state and the previous > Â Â commit, I think I can get to where I want to go from here. Thanks. > > >> Another option is to make NEXT/INDEX mean a tree (:0:). I have not >> thought this through (and have not made a suggestion, accordingly) but I >> do see a problem in the UI. (I don't think we need to change the >> existing ui in that respect but can amend and improve it.) >> >> Anyway, it's rc phase :) > > Rc or not rc, just repeating a fuzzy and uncooked "idea" around phoney > ref-looking names that will end up confusing the users, and selling that > as if it is a logical conclusion to "we want to give an easier to > understand UI", without presenting a solid user experience design that is > convincing enough that the "idea" will reduce confusion will not get us > anywhere, especially when it is sprinkled with ad hominem attack at me. I think I'm the only one that mentioned your name so I apologize if you saw that as an attack. I was not saying you are unreasonable in not changing the UI all the time, or that you are unreasonable for not liking the NEXT/WTREE - there are certainly cases I'm not considering. (For example, I'm more concerned about things like 'git commit-tree NEXT' or 'git rev-parse NEXT' if the index is in a weird state - it obviously has to be special-cased and I would assume only usable at the porcelain level, possibly only by 'diff', 'show' and 'grep'. It's the implementation I'm mainly worried about, I feel that the UI would be pretty straightforward in all these cases.) Re: the ad-hominim stuff, I was simply remarking that the 'reset'/'checkout' debate has been had several times and there is precedent for it being a non-starter. I also see and understand the argument from you and Linus about that, I just happen to disagree with it. It was not meant to be an attack. Scott -- 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