StGIT and conflicts

The current behavior of StGIT is to not use the index for conflicts like git does. What advantages does this have that are great enough to motivate a deviation from the git behavior?

On 24/05/07, Karl Hasselström <kha@treskal.com> wrote:

I don't think there are any advantages in deviating from the git behaviour, only that when I first implementing it, git didn't have any smarter behaviour and I used diff3 (or other external merger, which can be used right now as well).

I'm not sure if git-diff still works when there are conflicts in the index. The current stg behaviour is to reset the index to the base of the patch and a stg diff would show the diff (including the config markers) to the base. I find this quite handy.

On 2007-05-25 11:00:33 +0100, Catalin Marinas wrote:

To be honest, I'm not very well versed in how git handles merge conflicts -- with all the nontrivial projects I touch, I use StGIT for everything that can conflict. :-) Grepping for "conflict" in the user manual brings up a very good explanation, though; and to answer your question: it seems to work very well indeed, surprise surprise. You can make the diff show anything you want, including between the patch base and the working dir. Though, as the manual points out, the most important view is probably between index and working tree, which shows you just the not-yet-fixed conflicts.

Step one would be to simply stop messing with the index after merges, and just let "stg resolved" mean "git add".

Step two (somewhat more ambitious) might be to stop trying to hide the index, by providing a flag to "stg refresh" to make it refresh only what's in the index, and not everything -- that is, to make it do what "git commit" does when _not_ given the -a flag. And once we stop hiding the index, there's no point in having StGIT commands to do things like add, remove, and so on -- we could just use what git provides.