Brandon McCaig <bamccaig@xxxxxxxxx> writes: > On Thu, Feb 27, 2014 at 9:57 PM, Stephen Leake > <stephen_leake@xxxxxxxxxxxxxxxx> 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 -- 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