On Wed, Apr 24, 2013 at 7:48 AM, Junio C Hamano gits...@pobox.com wrote:
there
could be textual conflicts and you could choose to leave them in, or
you could choose to have rerere resolve it. As long as you do the
same when replaying this prepackaged evil merge, this choice does
not matter,
Antoine Pelisse apeli...@gmail.com writes:
But, as it looks like you would save F on top of M, it means that M
would be reachable, and thus rerere would be recomputable from
somewhere else.
Exactly.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
Antoine Pelisse apeli...@gmail.com writes:
Should we think about adding some commands for that ?
On the very top of my head (there is certainly more than that):
- Save such a change: By basically creating a ref to HEAD (HEAD being
the commit, HEAD^ the fixed merge) with
Johan Herland jo...@herland.net writes:
This raises the same question I recently asked Antoine: For a given
prepackaged merge X,Y, do we assume that it only resolves conflicts
between the changes introduced in commit X vs. changes introduced in
commit Y, or do we assume that it resolves
On Wed, Apr 10, 2013 at 10:35 PM, Antoine Pelisse apeli...@gmail.com wrote:
The goal is to propose a structure for storing and pre-merging pairs of
commits.
Data-structure
==
We could use a note ref to store the pre-merge information. Each commit
would be annotated with a blob
On Tue, Apr 23, 2013 at 8:34 AM, Johan Herland jo...@herland.net wrote:
On Wed, Apr 10, 2013 at 10:35 PM, Antoine Pelisse apeli...@gmail.com wrote:
Data-structure
==
We could use a note ref to store the pre-merge information. Each commit
would be annotated with a blob containing
Johan Herland jo...@herland.net writes:
Can you solve this problem with a tree object, instead of inventing a
specially-formatted blob?
Hmm. What problem are you guys trying to solve?
I think Michael's use of a merge commit to record a merge result is
sufficient as a means to record how to
Antoine Pelisse apeli...@gmail.com writes:
And I
have the feeling that merge-fix/B or merge-fix/A doesn't hold
enough information to do that accurately.
Oh, you do not have to resort to feeling; these names do _not_ hold
enough information, period. We already know that, that was why I was
On Tue, Apr 23, 2013 at 5:29 PM, Junio C Hamano gits...@pobox.com wrote:
Antoine Pelisse apeli...@gmail.com writes:
And I
have the feeling that merge-fix/B or merge-fix/A doesn't hold
enough information to do that accurately.
Oh, you do not have to resort to feeling; these names do _not_
On Tue, Apr 23, 2013 at 4:51 PM, Antoine Pelisse apeli...@gmail.com wrote:
On Tue, Apr 23, 2013 at 8:34 AM, Johan Herland jo...@herland.net wrote:
On Wed, Apr 10, 2013 at 10:35 PM, Antoine Pelisse apeli...@gmail.com wrote:
Data-structure
==
We could use a note ref to store the
Any comment on that ? I think anyone using a Topic Workflow could
use that feature and that it would be a nice addition to the project.
Maybe I'm totally wrong in the proposal below (please tell me !), but
there are some unanswered question that prevents me from starting (and
I'd really like this
The goal is to propose a structure for storing and pre-merging pairs of commits.
Data-structure
==
We could use a note ref to store the pre-merge information. Each commit
would be annotated with a blob containing the list of pre-merges (one
sha1 per line with sha1 pointing to a merge
12 matches
Mail list logo
