3 ms·

1. Yes, git stash is an option. Unfortunately, if it's anything like mercurial's shelve, it's not a good one. What happens when you 'unstash'? Does it proper

1. Yes, git stash is an option. Unfortunately, if it's anything like mercurial's shelve, it's not a good one. What happens when you 'unstash'? Does it properly give you conflict markers, or does it generate patchfiles? The latter is mercurial's behavior, and it sucks. To do the former, the stash command needs to also track the repo version that the local changes were based upon, so it has the historical information to present conflict markers (effectively, enough info for a 3-way merge). FWIW, This is actually the only thing holding my team back from switching back to hg. If hg shelve were part of the standard distribution and rock solid (multiple shelves would form a queue, no chance of corruption, and unshelve preserved historical information so it could properly merge conflicts), the world would be a better place. :) 2. Yes, I know WHY it does what it does. But the way it presents this info is unfortunate, because after a merge it's far more difficult to know exactly which changes you were making - many programmers are in the habit of reviewing their changes before committing. Does GIT let you easily tease out these differences? [edit: call to action]

pyre 16y ago
> many programmers are in the habit of reviewing their changes before committing. Does GIT let you easily tease out these differences? I'm unsure what you're asking here. I can say that 'git diff' shows you the difference between the working tree and the index and 'git diff --cached' shows you the difference between the index and the most recent commit (i.e. HEAD). Both of those accept a filename as an argument to just git the diff of that file in the respective spaces. All of the changes that cleanly merged are in the index, and all of the unresolved conflicts are not when you first enter the 'unresolved conflicts' state while attempting a merge. If your asking something more specific than that you'll have to rephrase or explain for me.

pyre 16y ago

> many programmers are in the habit of reviewing their changes before committing. Does GIT let you easily tease out these differences? I'm unsure what you're asking here. I can say that 'git diff' shows you the difference between the working tree and the index and 'git diff --cached' shows you the difference between the index and the most recent commit (i.e. HEAD). Both of those accept a filename as an argument to just git the diff of that file in the respective spaces. All of the changes that cleanly merged are in the index, and all of the unresolved conflicts are not when you first enter the 'unresolved conflicts' state while attempting a merge. If your asking something more specific than that you'll have to rephrase or explain for me.