git@vger.kernel.org list mirror (unofficial, one of many)
 help / color / Atom feed
* How to exchange rerere/redo resolutions?
@ 2019-05-09 23:23 Philip Oakley
  2019-05-09 23:49 ` Ævar Arnfjörð Bjarmason
  2019-05-10 14:05 ` Torsten Bögershausen
  0 siblings, 2 replies; 10+ messages in thread
From: Philip Oakley @ 2019-05-09 23:23 UTC (permalink / raw)
  To: Git List; +Cc: Torsten Bögershausen, Junio C Hamano

Hi,

Is there a mechanism for exchanging the rerere resolutions, so that 
future fixups, e.g. future clashes on pu rather than master, can be sent 
with patch series?

My current use case that there is a large patch [1] for updating long to 
size_t for use on Windows, which notes that it will have clashes with 
pu, but doesn't appear to have any method  of sending a rerere 
resolution (which the author is already aware of) to the list. Being 
able to flag up such fixes should simplify such conflict resolutions.

I had some very rough ideas about how the resolutions should look rather 
similar to three-way conflict markers, with the resolution as the 'base' 
(between the ||| - ||| marks), which would be resolved via a --base 
merge strategy.

However if there is already a method for exchanging resolutions, where 
should I look?

Philip

[1] <20190413151850.29037-1-tboegi@web.de> [PATCH v3 1/1] Use size_t 
instead of 'unsigned long' for data in memory

-- 
Philip


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: How to exchange rerere/redo resolutions?
  2019-05-09 23:23 How to exchange rerere/redo resolutions? Philip Oakley
@ 2019-05-09 23:49 ` Ævar Arnfjörð Bjarmason
  2019-05-10 14:59   ` Philip Oakley
  2019-05-10 14:05 ` Torsten Bögershausen
  1 sibling, 1 reply; 10+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2019-05-09 23:49 UTC (permalink / raw)
  To: Philip Oakley; +Cc: Git List, Torsten Bögershausen, Junio C Hamano


On Fri, May 10 2019, Philip Oakley wrote:

> Is there a mechanism for exchanging the rerere resolutions, so that
> future fixups, e.g. future clashes on pu rather than master, can be
> sent with patch series?
>
> My current use case that there is a large patch [1] for updating long
> to size_t for use on Windows, which notes that it will have clashes
> with pu, but doesn't appear to have any method  of sending a rerere
> resolution (which the author is already aware of) to the list. Being
> able to flag up such fixes should simplify such conflict resolutions.
>
> I had some very rough ideas about how the resolutions should look
> rather similar to three-way conflict markers, with the resolution as
> the 'base' (between the ||| - ||| marks), which would be resolved via
> a --base merge strategy.
>
> However if there is already a method for exchanging resolutions, where
> should I look?
>
> Philip
>
> [1] <20190413151850.29037-1-tboegi@web.de> [PATCH v3 1/1] Use size_t
> instead of 'unsigned long' for data in memory

You can publish your merged branch somewhere, and others can use
contrib/rerere-train.sh to learn from the resolution.

Supposedly, I've never actually used it...

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: How to exchange rerere/redo resolutions?
  2019-05-09 23:23 How to exchange rerere/redo resolutions? Philip Oakley
  2019-05-09 23:49 ` Ævar Arnfjörð Bjarmason
@ 2019-05-10 14:05 ` Torsten Bögershausen
  2019-05-10 15:10   ` Philip Oakley
  1 sibling, 1 reply; 10+ messages in thread
From: Torsten Bögershausen @ 2019-05-10 14:05 UTC (permalink / raw)
  To: Philip Oakley; +Cc: Git List, Junio C Hamano

On Fri, May 10, 2019 at 12:23:28AM +0100, Philip Oakley wrote:
> Hi,
>
> Is there a mechanism for exchanging the rerere resolutions, so that future
> fixups, e.g. future clashes on pu rather than master, can be sent with patch
> series?
>
> My current use case that there is a large patch [1] for updating long to
> size_t for use on Windows, which notes that it will have clashes with pu,
> but doesn't appear to have any method  of sending a rerere resolution (which
> the author is already aware of) to the list. Being able to flag up such
> fixes should simplify such conflict resolutions.
>
> I had some very rough ideas about how the resolutions should look rather
> similar to three-way conflict markers, with the resolution as the 'base'
> (between the ||| - ||| marks), which would be resolved via a --base merge
> strategy.
>
> However if there is already a method for exchanging resolutions, where
> should I look?
>
> Philip
>
> [1] <20190413151850.29037-1-tboegi@web.de> [PATCH v3 1/1] Use size_t instead
> of 'unsigned long' for data in memory
>
> --
> Philip
>

That is not an answer to the question.
If it helps, I can rebase the first patch onto git.git/master, and the
cherry-pick the next patches. That can happen next week or so.
And then let it go through the normal pu->next->master->git-for-windows workflow.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: How to exchange rerere/redo resolutions?
  2019-05-09 23:49 ` Ævar Arnfjörð Bjarmason
@ 2019-05-10 14:59   ` Philip Oakley
  2019-05-13 22:24     ` Philip Oakley
  0 siblings, 1 reply; 10+ messages in thread
From: Philip Oakley @ 2019-05-10 14:59 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason, Philip Oakley
  Cc: Git List, Torsten Bögershausen, Junio C Hamano

On 10/05/2019 00:49, Ævar Arnfjörð Bjarmason wrote:
> On Fri, May 10 2019, Philip Oakley wrote:
>
>> Is there a mechanism for exchanging the rerere resolutions, so that
>> future fixups, e.g. future clashes on pu rather than master, can be
>> sent with patch series?
>>
>> My current use case that there is a large patch [1] for updating long
>> to size_t for use on Windows, which notes that it will have clashes
>> with pu, but doesn't appear to have any method  of sending a rerere
>> resolution (which the author is already aware of) to the list. Being
>> able to flag up such fixes should simplify such conflict resolutions.
>>
>> I had some very rough ideas about how the resolutions should look
>> rather similar to three-way conflict markers, with the resolution as
>> the 'base' (between the ||| - ||| marks), which would be resolved via
>> a --base merge strategy.
>>
>> However if there is already a method for exchanging resolutions, where
>> should I look?
>>
>> Philip
>>
>> [1] <20190413151850.29037-1-tboegi@web.de> [PATCH v3 1/1] Use size_t
>> instead of 'unsigned long' for data in memory
> You can publish your merged branch somewhere, and others can use
> contrib/rerere-train.sh to learn from the resolution.
>
> Supposedly, I've never actually used it...
The tricky part is when the patch series doesn't apply so the conflict 
isn't yet on any branch..

I'm looking to write up some suggestions as a potential project, so that 
we can all make better use of this capability (hence the `redo` synonym 
alias suggestion).
Philip

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: How to exchange rerere/redo resolutions?
  2019-05-10 14:05 ` Torsten Bögershausen
@ 2019-05-10 15:10   ` Philip Oakley
  0 siblings, 0 replies; 10+ messages in thread
From: Philip Oakley @ 2019-05-10 15:10 UTC (permalink / raw)
  To: Torsten Bögershausen; +Cc: Git List, Junio C Hamano

Hi Torsten,

On 10/05/2019 15:05, Torsten Bögershausen wrote:
> On Fri, May 10, 2019 at 12:23:28AM +0100, Philip Oakley wrote:
>> Hi,
>>
>> Is there a mechanism for exchanging the rerere resolutions, so that future
>> fixups, e.g. future clashes on pu rather than master, can be sent with patch
>> series?
>>
>> My current use case that there is a large patch [1] for updating long to
>> size_t for use on Windows, which notes that it will have clashes with pu,
>> but doesn't appear to have any method  of sending a rerere resolution (which
>> the author is already aware of) to the list. Being able to flag up such
>> fixes should simplify such conflict resolutions.
>>
>> I had some very rough ideas about how the resolutions should look rather
>> similar to three-way conflict markers, with the resolution as the 'base'
>> (between the ||| - ||| marks), which would be resolved via a --base merge
>> strategy.
>>
>> However if there is already a method for exchanging resolutions, where
>> should I look?
>>
>> Philip
>>
>> [1] <20190413151850.29037-1-tboegi@web.de> [PATCH v3 1/1] Use size_t instead
>> of 'unsigned long' for data in memory
>>
>> --
>> Philip
>>
> That is not an answer to the question.
> If it helps, I can rebase the first patch onto git.git/master, and the
> cherry-pick the next patches. That can happen next week or so.
> And then let it go through the normal pu->next->master->git-for-windows workflow.
>
Thanks for the offer, but I should be OK. dscho has already asked that 
for testing on Git for Windows I rebase my series back onto master, 
rather than pu. The series is at 
https://github.com/git-for-windows/git/pull/2179#issuecomment-491095412
--
Philip

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: How to exchange rerere/redo resolutions?
  2019-05-10 14:59   ` Philip Oakley
@ 2019-05-13 22:24     ` Philip Oakley
  2019-05-13 22:46       ` Junio C Hamano
  2019-05-14  8:21       ` Ævar Arnfjörð Bjarmason
  0 siblings, 2 replies; 10+ messages in thread
From: Philip Oakley @ 2019-05-13 22:24 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: Git List, Torsten Bögershausen, Junio C Hamano

Hi All,

On 10/05/2019 15:59, Philip Oakley wrote:
>> You can publish your merged branch somewhere, and others can use
>> contrib/rerere-train.sh to learn from the resolution.
>>
>> Supposedly, I've never actually used it...

Does the contrib/rerere-train.sh actually work? I'm reading the code to 
ensure I understand what rerere/redo is doing, and in the training it 
tries to detect MERGE_RR via L87

     if test -s "$GIT_DIR/MERGE_RR"

It's not clear if that is an internal implementation detail, or a 
mistaken use of a historic path name. Can anyone enlighten me?

> The tricky part is when the patch series doesn't apply so the conflict 
> isn't yet on any branch.. 
When copying patches across to Git for Windows, the conflict resolution 
can be tricky.
--
Philip


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: How to exchange rerere/redo resolutions?
  2019-05-13 22:24     ` Philip Oakley
@ 2019-05-13 22:46       ` Junio C Hamano
  2019-05-14  8:21       ` Ævar Arnfjörð Bjarmason
  1 sibling, 0 replies; 10+ messages in thread
From: Junio C Hamano @ 2019-05-13 22:46 UTC (permalink / raw)
  To: Philip Oakley
  Cc: Ævar Arnfjörð Bjarmason, Git List,
	Torsten Bögershausen

Philip Oakley <philipoakley@iee.org> writes:

> Does the contrib/rerere-train.sh actually work?

Yes, but it predates many esoteric things like multiple worktrees.


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: How to exchange rerere/redo resolutions?
  2019-05-13 22:24     ` Philip Oakley
  2019-05-13 22:46       ` Junio C Hamano
@ 2019-05-14  8:21       ` Ævar Arnfjörð Bjarmason
  2019-05-14 23:11         ` Philip Oakley
  2019-05-15  1:12         ` Junio C Hamano
  1 sibling, 2 replies; 10+ messages in thread
From: Ævar Arnfjörð Bjarmason @ 2019-05-14  8:21 UTC (permalink / raw)
  To: Philip Oakley; +Cc: Git List, Torsten Bögershausen, Junio C Hamano


On Tue, May 14 2019, Philip Oakley wrote:

> Hi All,
>
> On 10/05/2019 15:59, Philip Oakley wrote:
>>> You can publish your merged branch somewhere, and others can use
>>> contrib/rerere-train.sh to learn from the resolution.
>>>
>>> Supposedly, I've never actually used it...
>
> Does the contrib/rerere-train.sh actually work? I'm reading the code
> to ensure I understand what rerere/redo is doing, and in the training
> it tries to detect MERGE_RR via L87
>
>     if test -s "$GIT_DIR/MERGE_RR"
>
> It's not clear if that is an internal implementation detail, or a
> mistaken use of a historic path name. Can anyone enlighten me?

Historic? No, this is path.c now on master:

    path.c:1454:REPO_GIT_PATH_FUNC(merge_rr, "MERGE_RR")

Internal, sure. We don't document it so it could change in theory, but
then we'd probably change rerere-train.sh along with it...

>> The tricky part is when the patch series doesn't apply so the
>> conflict isn't yet on any branch..
> When copying patches across to Git for Windows, the conflict
> resolution can be tricky.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: How to exchange rerere/redo resolutions?
  2019-05-14  8:21       ` Ævar Arnfjörð Bjarmason
@ 2019-05-14 23:11         ` Philip Oakley
  2019-05-15  1:12         ` Junio C Hamano
  1 sibling, 0 replies; 10+ messages in thread
From: Philip Oakley @ 2019-05-14 23:11 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: Git List, Torsten Bögershausen, Junio C Hamano

Hi Ævar,

On 14/05/2019 09:21, Ævar Arnfjörð Bjarmason wrote:
> On Tue, May 14 2019, Philip Oakley wrote:
>
>> Hi All,
>>
>> On 10/05/2019 15:59, Philip Oakley wrote:
>>>> You can publish your merged branch somewhere, and others can use
>>>> contrib/rerere-train.sh to learn from the resolution.
>>>>
>>>> Supposedly, I've never actually used it...
>> Does the contrib/rerere-train.sh actually work? I'm reading the code
>> to ensure I understand what rerere/redo is doing, and in the training
>> it tries to detect MERGE_RR via L87
>>
>>      if test -s "$GIT_DIR/MERGE_RR"
>>
>> It's not clear if that is an internal implementation detail, or a
>> mistaken use of a historic path name. Can anyone enlighten me?
> Historic? No, this is path.c now on master:
Hmm, I'd now agree it's not a mistake, but the implementation detail is 
historic. I've now found [1,2,3,4] from before I knew of Git! And it's 
not mentioned in any of the documentation.
>
>      path.c:1454:REPO_GIT_PATH_FUNC(merge_rr, "MERGE_RR")
>
> Internal, sure. We don't document it so it could change in theory, but
> then we'd probably change rerere-train.sh along with it...
Hopefully it'll be integrated into rerere/redo before that ;-), along 
with a bit more documentation on the capability for those who arrived 
late to the party. The use of this implementation detail came up 
yesterday in [5].
>>> The tricky part is when the patch series doesn't apply so the
>>> conflict isn't yet on any branch..
>> When copying patches across to Git for Windows, the conflict
>> resolution can be tricky.
--
Philip

[1] git-rerere: reuse recorded resolve, 29 Jan 2006, 
https://public-inbox.org/git/7v4q3no0v7.fsf@assigned-by-dhcp.cox.net/
[2] StGIT and rerere, 26 Oct 2006, 
https://public-inbox.org/git/7vfydbkn64.fsf@assigned-by-dhcp.cox.net/
[3] git-explain, 04 Dec 2006, 
https://public-inbox.org/git/7vwt57j94c.fsf_-_@assigned-by-dhcp.cox.net/
[4] Make git-rerere a builtin, 20 Dec 2006, 
https://public-inbox.org/git/Pine.LNX.4.63.0612201738000.19693@wbgn013.biozentrum.uni-wuerzburg.de/ 

[5] merge: add --quit, 14 May 2019 , 
https://public-inbox.org/git/nycvar.QRO.7.76.6.1905141540300.44@tvgsbejvaqbjf.bet/

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: How to exchange rerere/redo resolutions?
  2019-05-14  8:21       ` Ævar Arnfjörð Bjarmason
  2019-05-14 23:11         ` Philip Oakley
@ 2019-05-15  1:12         ` Junio C Hamano
  1 sibling, 0 replies; 10+ messages in thread
From: Junio C Hamano @ 2019-05-15  1:12 UTC (permalink / raw)
  To: Ævar Arnfjörð Bjarmason
  Cc: Philip Oakley, Git List, Torsten Bögershausen

Ævar Arnfjörð Bjarmason <avarab@gmail.com> writes:

>>     if test -s "$GIT_DIR/MERGE_RR"
>>
>> It's not clear if that is an internal implementation detail, or a
>> mistaken use of a historic path name. Can anyone enlighten me?
>
> Historic? No, this is path.c now on master:
>
>     path.c:1454:REPO_GIT_PATH_FUNC(merge_rr, "MERGE_RR")
>
> Internal, sure. We don't document it so it could change in theory, but
> then we'd probably change rerere-train.sh along with it...

Doesn't the function defined by REPO_GIT_PATH_FUNC() do far more
than a simple concatenation?  I suspect that he questions why
"$GIT_DIR/MERGE_RR" is an OK substitute for that.

The $GIT_DIR variable in the script is set by inclusion of
git-sh-setup, that runs "git rev-parse --git-dir"; in post "git
worktree" world, where ".git" may be a "gitdir: $real_location" text
file, this will give the actual directory, not the path to a regular
file at the top of the working tree whose name is ".git", so the
answer to the question is that the concatenation we see should be
OK, even in the "git worktree" world.


^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, back to index

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-05-09 23:23 How to exchange rerere/redo resolutions? Philip Oakley
2019-05-09 23:49 ` Ævar Arnfjörð Bjarmason
2019-05-10 14:59   ` Philip Oakley
2019-05-13 22:24     ` Philip Oakley
2019-05-13 22:46       ` Junio C Hamano
2019-05-14  8:21       ` Ævar Arnfjörð Bjarmason
2019-05-14 23:11         ` Philip Oakley
2019-05-15  1:12         ` Junio C Hamano
2019-05-10 14:05 ` Torsten Bögershausen
2019-05-10 15:10   ` Philip Oakley

git@vger.kernel.org list mirror (unofficial, one of many)

Archives are clonable:
	git clone --mirror https://public-inbox.org/git
	git clone --mirror http://ou63pmih66umazou.onion/git
	git clone --mirror http://czquwvybam4bgbro.onion/git
	git clone --mirror http://hjrcffqmbrq6wope.onion/git

Newsgroups are available over NNTP:
	nntp://news.public-inbox.org/inbox.comp.version-control.git
	nntp://ou63pmih66umazou.onion/inbox.comp.version-control.git
	nntp://czquwvybam4bgbro.onion/inbox.comp.version-control.git
	nntp://hjrcffqmbrq6wope.onion/inbox.comp.version-control.git
	nntp://news.gmane.org/gmane.comp.version-control.git

 note: .onion URLs require Tor: https://www.torproject.org/

AGPL code for this site: git clone https://public-inbox.org/ public-inbox