Re: StGIT and conflicts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

> On 24/05/07, Karl Hasselström <kha@xxxxxxxxxxx> 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.

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@xxxxxxxxxxx
      www.treskal.com/kalle
-
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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux