Re: `git stash pop` UX Problem

[Stephen Leake <stephen_leake@stephe-leake.org>]

Brandon McCaig <bamccaig@gmail.com> writes:

> On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake
> <stephen_leake@stephe-leake.org> wrote:
>> 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?


>> 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