[prev in list] [next in list] [prev in thread] [next in thread] 

List:       git
Subject:    Re: [PATCH] Add a testcase for the safety of pull-policy='pull'.
From:       Yann Dirson <ydirson () altern ! org>
Date:       2007-02-28 21:48:51
Message-ID: 20070228214851.GC4149 () nan92-1-81-57-214-146 ! fbx ! proxad ! net
[Download RAW message or body]

On Tue, Feb 27, 2007 at 11:38:45PM +0000, Catalin Marinas wrote:
> >> BTW, push --undo now requires a status --reset beforehand.
> >
> >Oh, I had not noticed that.  Why so ?  It's not like if "push --undo"
> >would lose any valuable data...
> 
> I added it so that one cannot remove the local changes by doing a
> "push --undo" in error. You would have to explicitly ask for local
> changes removing with status --reset.

At least, the message in that case should probably be made better,
when undoing to avoid having to resolve a conflict: the message says I
cannot undo because I have a conflict, whereas it is the exact reason
why I want to undo.
Especially, since the conflict markers are now auto-recorded, we could
simply allow undo in that case.

> >What strikes me most in this case is the difference in behaviour
> >between this type of conflict (conflict marked in index, so needs an
> >operation outside the current scope of stgit to proceed), with a
> >regular stgit conflict that occurs during a push (index clean,
> >conflict info not available to tools written for regular GIT).
> 
> I think this is a valid GIT conflict as the upstream tree re-wrote the
> history and git-pull will trigger a 3-way merge.

I do not discuss the validity of the conflict.  I'm just emphasizing
that it makes it hard to handle things in stgit, with *any*
post-rebase processing being skipped.  For now we seem to have nothing
critical for that workflow (I'll surely end up with deactivating the
orig-base check for pull-policy=pull), but that may cause more trouble
later, eg. when implementing transactions.


> If you would always use git-fetch + stgit-rebase, there wouldn't be
> any problem.

Sure, that's why I'm lobbying for this policy to be the default :)


> (BTW, I just added a patch for a 2-way interactive merge as well).

Sounds great - I just had an add/add conflict today on 0.12.1 when
trying to play with "resolved -i", and it loudly complained it had no
ancestor to play with.  Sounds like a perfect usage for 2-way merges.

Best regards,
-- 
Yann.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
[prev in list] [next in list] [prev in thread] [next in thread]