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?

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle

On 24/05/07, Karl Hasselström [off-list ref] wrote:

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?

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.

-- 
Catalin

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

On 24/05/07, Karl Hasselström [off-list ref] wrote:

quoted

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?

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.

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.

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle