Antoine Pelisse 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 merge-fix/HEAD^^1-HEAD^^2
> - Apply
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 merge-fix/HEAD^^1-HEAD^^2
- Apply the merge-fix: On top of a merge, fi
Antoine Pelisse 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 majord...@vger
On Wed, Apr 24, 2013 at 7:48 AM, Junio C Hamano 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, but using rer
Johan Herland writes:
> This raises the same question I recently asked Antoine: For a given
> prepackaged merge , 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 conflicts between the
On Wed, Apr 24, 2013 at 7:48 AM, Junio C Hamano wrote:
> Johan Herland writes:
>
>>> But P is a commit(/merge with two parents), not a blob. Can we have trees
>>> pointing to commits instead of blobs ?
>>
>> Sort of. We do so when recording submodules in regular git trees.
>
> You are using notes
Johan Herland writes:
>> But P is a commit(/merge with two parents), not a blob. Can we have trees
>> pointing to commits instead of blobs ?
>
> Sort of. We do so when recording submodules in regular git trees.
You are using notes to maintain reachability, aren't you? Because
commit objects tha
On Tue, Apr 23, 2013 at 4:51 PM, Antoine Pelisse wrote:
> On Tue, Apr 23, 2013 at 8:34 AM, Johan Herland wrote:
>> On Wed, Apr 10, 2013 at 10:35 PM, Antoine Pelisse wrote:
>>> Data-structure
>>> ==
>>> We could use a note ref to store the pre-merge information. Each commit
>>> would
On Tue, Apr 23, 2013 at 5:29 PM, Junio C Hamano wrote:
> Antoine Pelisse 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 informatio
Antoine Pelisse 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
unhappy, and t
On Tue, Apr 23, 2013 at 4:53 PM, Junio C Hamano wrote:
> Johan Herland 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?
>
> [snipped..]
> And that was why I wanted to have a data st
Johan Herland 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 recreate an evil
On Tue, Apr 23, 2013 at 8:34 AM, Johan Herland wrote:
> On Wed, Apr 10, 2013 at 10:35 PM, Antoine Pelisse wrote:
>> 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
On Wed, Apr 10, 2013 at 10:35 PM, Antoine Pelisse 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 containing
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
16 matches
Mail list logo
