On Mon, Aug 11, 2014 at 04:59:15PM +1200, Chris Packham wrote:
> Is there any way where we could share the conflict resolution around
> but still end up with a single merge commit. I'm thinking of something
> like the following workflow
This came up once a while back. Here's the discussion:
ht
On Mon, Aug 11, 2014 at 4:29 PM, Chris Packham wrote:
>> So, the "recording" phase may go something like this:
>> ...
>> git checkout merge-fix/$this-$that
>> git read-tree -m -u HEAD $this
>> git commit -a -m 'merge-fix/$this-$that postimage'
>>
>> The rough idea is "git show merge-f
On Tue, Aug 12, 2014 at 6:44 AM, Junio C Hamano wrote:
> Chris Packham writes:
>
>> Is there any way where we could share the conflict resolution around
>> but still end up with a single merge commit.
>
> One idea that immediately comes to me is to use something like
> "rerere" (not its implement
IIUC, this might help,
http://www.mail-archive.com/git@vger.kernel.org/msg56418.html
http://www.mail-archive.com/git@vger.kernel.org/msg56468.html
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://
Le 11 août 2014 07:50, "Christian Couder" a écrit :
>
> This should be possible using "git imerge" which is separate tool.
Sorry I sent the above using the gmail app on my mobile phone and
unfortunately I can't make it send plain text emails.
(Emails which are not plain text are rejected by vger.
Chris Packham writes:
> Is there any way where we could share the conflict resolution around
> but still end up with a single merge commit.
One idea that immediately comes to me is to use something like
"rerere" (not its implementation and storage, but the underlying
idea) enhanced with the tric
6 matches
Mail list logo