Re: `git stash pop` UX Problem

Brandon McCaig [off-list ref] writes:

On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
[off-list ref] wrote:

quoted

You might be adding other files for other reasons. But if you add a file
that does resolve a conflict caused by 'git stash pop', it is not
guessing.

Staging a file doesn't tell git that you resolved a conflict. Git will
happily accept a blob full of conflict markers. Git doesn't know the
difference. Git expects the user to know what is right. The user has
the freedom to manipulate the index as they see fit, which means both
adding and removing from it anytime they wish.

But git has a notion of "unresolved conflict". For example, when I have
conflicts from a 'git stash pop', 'git status' shows:

stephe@takver$ git status
# On branch master
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#	both modified:      CommandBasedAutonomous.java
#	both modified:      DriveByInches.java
#
# ...

How does it know those files are "unmerged"? I'm guessing it has
recorded the fact that they had conflicts. Where does it record that?

In fact, at this point, I have edited CommandBasedAutonomous.java to
resolve the conflicts. But git apparently doesn't know that.

So I do 'git add CommandBasedAutonomous.java', then 'git status':

stephe@takver$ git status
# On branch master
# Changes to be committed:
#   (use "git reset HEAD <file>..." to unstage)
#
#	modified:   AerialAssist2014/src/org/usfirst/frc1939/AerialAssist2014/commands/CommandBasedAutonomous.java
#
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#	both modified:      AerialAssist2014/src/org/usfirst/frc1939/AerialAssist2014/commands/DriveByInches.java

And git thinks that file is now "merged".

So it appears that adding a file _does_ tell git that the conflict is
resolved.

Or am I still missing something?

quoted

So "git add" and "git stash *" are lower level tools; to get the effect
we are asking for, we should use a front-end (which is why I'm writing
one for Emacs :).

You *can* use a front end, but I would argue that you shouldn't
necessarily. Most third-party front ends only serve to confuse users.
In general, they only cause problems and encourage ignorance.

Won't happen here; I'm writing it. It may confuse other people, but
not me :).

Git is a very pure system.

Hmm. We'll have to disagree on that. git gives the impression of having
grown organically for quite a while, and therefore suffers from changing
and competing design paradigms and conflicting requirements due to
preserving backward compatiblity.

monotone is much cleaner, since it has had very few design paradigm
changes, and they were implemented cleanly, without preserving backward
compatibility. monotone is not as flexible as git, but what I've seen so
far could be added to monotone (I don't think it ever will be; monotone
is dying as a project).

We are probably using different definitions of "pure" here.

It is up to the user to learn how to assemble those tools for
good (and many front ends exist to help; sometimes arguably too many
as it is, such as git-pull(1) for example).

Yes. Which is why we are discussing how much help git should be while
still learning the rules.

 This isn't a case of the API being wrong. This is a case of PEBKAC,
IMO.

(wikipedia to the rescue; PEBKAC = "operator error")

Yes, I'm not using it correctly, because I don't understand it yet.
That's the definition of "newbie".

Dropping the stash after adding all changes to the index after a
failed pop is not universal.

Not universal, but it appears to be very common; it is certainly what I
expect, as a newbie. So it could be the default as long as there is a
configuration option to have it not do that.

I _did_ "RTFM" (specifically the man page on 'git stash', and before
that the git book at http://git-scm.com/documentation (which did not
mention stash)); it did not explain the full cycle of how to resolve
conflicts after stash pop.

Perhaps there is a different manual that I could read instead?

In particular, one that explains what "unmerged paths" means in the 'git
status' output? The 'git-status' man page does not do that.

--
-- Stephe