Vincent van Ravesteijn [off-list ref] writes:
Op 12-3-2012 21:01, Junio C Hamano schreef:
...
quoted
I haven't find it necessary in practice, as the re-fix for me
typically would go like this:
$ git merge other-branch
... rerere kicks in; eyeball the results
... ah, my earlier resolution is no longer correct
$ edit $the_path
... test the result of manual edit in the context of the merged whole
... and be satisified
$ git rerere forget $the_path
$ git add $the_path
$ git commit
... rerere records the updated resolution
What scenario do you have in mind that you would need to re-fix more
resolution than you need?
Context:
I have a number of topic branches that modify the fileformat version
and also the fileformat conversion routines. When merging all those
branches into an integration branch (like you regenerate pu),...
...
But well, if the experts don't feel the need, I will search further to
implement something that you do think is useful ;).
"It is not useful for experts" is not a reason to reject a feature.
As long as it is useful for general audience, it is OK to have it;
the experts can just choose not to use it.
I have experienced the same "Ah, no longer that earlier resolution
is a good one" or "Oops, that earlier resolution was busted" when
reintegrating 'pu', just like you do in your integration branch, and
the way I illustrated above is only a small part of the larger
workflow. I run the automated integration the usual way, rewind the
HEAD to the problematic commit, run the above procedure to update
the rerere database, and then re-run the automated integration.
That way, I have a chance to _test_ the updated entry in the rerere
databae in isolation, without the other noise that comes on top of
the problematic merge in 'pu'.
The problem I have with "rerere edit" is it is an offline process,
and to validate that the update is correct, I would have to have the
problematic merge in my working tree once _anyway_. And at that
point, updating the target file in the working tree and recording
the updated resolution using the usual "git rerere" feels a more
natural way to do so, and more importantly, it is a more convenient
way to do the "update and validate". On the other hand, "rerere
edit" is a more convenient way to "update but not validate the
result".
So I do not think the distinction is "expert" vs "others".
Op 12-3-2012 21:34, Junio C Hamano schreef:
Vincent van Ravesteijn[off-list ref] writes:
quoted
Op 12-3-2012 21:01, Junio C Hamano schreef:
...
quoted
I haven't find it necessary in practice, as the re-fix for me
typically would go like this:
$ git merge other-branch
... rerere kicks in; eyeball the results
... ah, my earlier resolution is no longer correct
$ edit $the_path
... test the result of manual edit in the context of the merged whole
... and be satisified
$ git rerere forget $the_path
$ git add $the_path
$ git commit
... rerere records the updated resolution
What scenario do you have in mind that you would need to re-fix more
resolution than you need?
Here I was mistaken. I assumed that you could run 'git rerere forget'
always and thus removing all conflict resolutions for a certain path.
Now I see that the documentation clearly says "current conflict in
<pathspec>"
The problem I have with "rerere edit" is it is an offline process,
and to validate that the update is correct, I would have to have the
problematic merge in my working tree once _anyway_. And at that
point, updating the target file in the working tree and recording
the updated resolution using the usual "git rerere" feels a more
natural way to do so, and more importantly, it is a more convenient
way to do the "update and validate". On the other hand, "rerere
edit" is a more convenient way to "update but not validate the
result".
This last part probably makes the difference indeed. In my case the
merge resolution was very very easy (the conflicting hunks have
fileformat version numbers), but it is a bit annoying and it requires
some 'vim'-skills to redo the merge conflict just to correct a newline
somewhere, or a missing ','.
As I wrote, the merge resolutions in my case were very easy (logically),
but just annoying (motorically).
These could even be resolved by some merge-conflict hook.
Examples:
- for this file we know the conflict always has to be resolved by adding
the oldest hunk before the newest hunk. For example, new file formats
will be added sequentially to a file.
- for this file we can resolve it anyway we want. For example, a release
notes file which just enumerates all changes in random order.
Anyway, has anyone thought about such a hook ?
Vincent
Vincent van Ravesteijn [off-list ref] writes:
As I wrote, the merge resolutions in my case were very easy
(logically), but just annoying (motorically).
These could even be resolved by some merge-conflict hook.
Examples:
- for this file we know the conflict always has to be resolved by
adding the oldest hunk before the newest hunk. For example, new file
formats will be added sequentially to a file.
- for this file we can resolve it anyway we want. For example, a
release notes file which just enumerates all changes in random order.
Anyway, has anyone thought about such a hook ?
Isn't it what custom merge drivers (for file-level merge) are for?
I think there can be found somewhere merge driver for changelog...
You can also use custom merge strategies, but that is probably
overkill, and I am not sure that it would work (adding new strategy)
without modifying git.
--
Jakub Narebski