I have a half baked alias for this and it proved to be extremely
useful even in this state.
check = "!f() { BRANCH=${1:-HEAD}; BASE=${2:-origin/master}; git
merge-tree $(git merge-base $BRANCH $BASE) $BRANCH $BASE | sed -n
\"/+<<<<<<< .our/,/+>>>>>>> .their/p\"; }; f"
Of course with large conflicts it gets less useful. Getting only file
names from the patch isn't straightforward either.
So my question is what are the downsides to introducing a `merge
--dry-run` option and what would it look like?
17.02.2021, 20:25, "Alireza" [off-list ref]:
I have a half baked alias for this and it proved to be extremely
useful even in this state.
check = "!f() { BRANCH=${1:-HEAD}; BASE=${2:-origin/master}; git
merge-tree $(git merge-base $BRANCH $BASE) $BRANCH $BASE | sed -n
\"/+<<<<<<< .our/,/+>>>>>>> .their/p\"; }; f"
Of course with large conflicts it gets less useful. Getting only file
names from the patch isn't straightforward either.
So my question is what are the downsides to introducing a `merge
--dry-run` option and what would it look like?
As a git user, I would very much welcome this addition, and similar for cherry-pick,
provided they don't modify any files in working copy.
--
Regards,
Konstantin
On 2021-02-17 at 17:21:45, Alireza wrote:
I have a half baked alias for this and it proved to be extremely
useful even in this state.
check = "!f() { BRANCH=${1:-HEAD}; BASE=${2:-origin/master}; git
merge-tree $(git merge-base $BRANCH $BASE) $BRANCH $BASE | sed -n
\"/+<<<<<<< .our/,/+>>>>>>> .their/p\"; }; f"
Of course with large conflicts it gets less useful. Getting only file
names from the patch isn't straightforward either.
So my question is what are the downsides to introducing a `merge
--dry-run` option and what would it look like?
There aren't really any, but the current implementation of the merge
code makes it non-trivial, since it writes directly into the working
tree. The new merge-ort code that Elijah Newren (CC'd) is working on
should at least support writing conflicts only into the index, and if
you didn't want to dirty the existing index, you could create a
temporary one with GIT_INDEX_FILE and write to that. It may also
support a dry-run mode natively, but I'm not following it closely enough
to say. Hopefully Elijah can say a little bit more about things.
In the mean time, since this is a frequently requested feature, I have a
Rust-based tool called git test-merge[0] that runs a test merge between
two arbitrary trees and determines whether it succeeds or fails. It
uses libgit2 under the hood.
[0] https://github.com/bk2204/scutiger
--
brian m. carlson (he/him or they/them)
Houston, Texas, US
On Fri, Feb 19, 2021 at 2:26 PM brian m. carlson
[off-list ref] wrote:
On 2021-02-17 at 17:21:45, Alireza wrote:
quoted
I have a half baked alias for this and it proved to be extremely
useful even in this state.
check = "!f() { BRANCH=${1:-HEAD}; BASE=${2:-origin/master}; git
merge-tree $(git merge-base $BRANCH $BASE) $BRANCH $BASE | sed -n
\"/+<<<<<<< .our/,/+>>>>>>> .their/p\"; }; f"
Of course with large conflicts it gets less useful. Getting only file
names from the patch isn't straightforward either.
So my question is what are the downsides to introducing a `merge
--dry-run` option and what would it look like?
There aren't really any, but the current implementation of the merge
code makes it non-trivial, since it writes directly into the working
tree. The new merge-ort code that Elijah Newren (CC'd) is working on
should at least support writing conflicts only into the index, and if
you didn't want to dirty the existing index, you could create a
temporary one with GIT_INDEX_FILE and write to that. It may also
support a dry-run mode natively, but I'm not following it closely enough
to say. Hopefully Elijah can say a little bit more about things.
In the mean time, since this is a frequently requested feature, I have a
Rust-based tool called git test-merge[0] that runs a test merge between
two arbitrary trees and determines whether it succeeds or fails. It
uses libgit2 under the hood.
I don't have that exact feature implemented, but I've got something
that could easily be reused to provide this functionality. In my
remerge-diff branch, I've got a --remerge-diff option for log (and
show), that for any merge commit will redo the merge in-memory (not
touching the working copy or index), and then show the diff between
that result (possibly including conflict markers) and what was
actually recorded in the merge. If the merge was clean and the user
didn't amend any changes into the merge commit, then the diff will be
empty. If the user moved around files, added changes, or just ripped
out conflict markers, then you see all that in the diff.
One could use the same logic to make a merge --dry-run option that
would show the diff between the commit before merging and the
auto-merged state. It probably wouldn't even be all that much code;
may half a day's worth of work.
But, it does rely on getting merge-ort reviewed and merged. We're 6
months into that process so far. I was hoping we'd finish it before
git-2.32 is released (note that git-2.31 isn't released yet either),
but right now git-2.33 is looking more probable. See
https://lore.kernel.org/git/pull.844.git.1613289544.gitgitgadget@gmail.com/
and https://github.com/gitgitgadget/git/pulls?q=is%3Apr+author%3Anewren+Optimization+batch
if you'd like to help review and/or test the portions that are ready
for review. (Or try the 'ort' or 'remerge-diff' branches of
https://github.com/newren/git if you want to try out the full set of
changes, including bits that haven't been nicely broken up in
preparation for upstream review.)