2019-12-10 02:24:31 +03:00
|
|
|
#chg-compatible
|
|
|
|
|
|
2018-10-22 22:45:46 +03:00
|
|
|
$ enable amend rebase
|
filemerge: print the potentially conflicting destination commits for each conflict
Summary:
One thing that makes dealing with merge conflicts difficult at Facebook is that it can be tough to know *why* you have merge conflicts.
Because rebase processes one commit at a time, it's clear which of *your* commits is the problem, but finding the "other" commit is surprisingly hard. Often we rebase onto `master`, and in a monorepo, `master` is often a random commit that has no relationship to your code at all.
This diff attempts to improve the situation a bit by listing all of the commits between the common ancestor and the destination commit that modified the file. The user can then identify which are likely culprits:
```
warning: 2 conflicts while merging b! (edit, then use 'hg resolve --mark')
3 commits might've introduced this conflict:
- [0942ca9aff3d] random commit 1
- [3ebd0a462491] foo bar biz
- [3e5843b4b236] blah blah blah
```
When the destination is public, this approach requires one loose file download (~0.5s?) per conflicted file (this pulls in the full filectx history DAG, so further downloads aren't needed), which is likely acceptable as it only runs on conflicts, and provides value to the user. But it's also configurable for users performing massive codemods.
I'll add metrics to gather the average number if matched commits and the time taken to generate.
This doesn't put this information into the conflict markers, so a lot of people (Nuclide users or the default `editmerge` users) won't see it. We need to think creatively about how to expose it to them.
The ideal solution would tell you which commits edited the actual conflicted section(s), not just those that touched the file.
This requires fast remotefilelog downloads (cc @[100000771202578:Arun] :)). Once we have those, we can construct a local `linelog` of the commits involved, and used this to identify precisely which commits edited the conflicted sections of the file.
Reviewed By: quark-zju
Differential Revision: D9816270
fbshipit-source-id: 04e08dea7a9429eaeab0d40310cd34355104bb74
2018-10-25 23:59:35 +03:00
|
|
|
$ setconfig merge.printcandidatecommmits=True
|
2018-10-22 22:45:46 +03:00
|
|
|
|
|
|
|
|
Encountering a merge conflict prints the number of textual conflicts in each file:
|
|
|
|
|
$ newrepo
|
|
|
|
|
$ hg debugdrawdag <<'EOS'
|
|
|
|
|
> e
|
|
|
|
|
> | # "b" has two conflicts between c and d:
|
|
|
|
|
> c d # b/b = 1\n2\n3\n4\n5\n6\n7\n8
|
|
|
|
|
> |/ # c/b = b\n2\n3\n4\n5\nq\n7\n8
|
|
|
|
|
> b # d/b = 0\n2\n3\n4\n5\n9\n7\n8
|
|
|
|
|
> |
|
|
|
|
|
> | # "a" has two conflicts between c and d:
|
|
|
|
|
> | # c/a = one
|
|
|
|
|
> a # d/a = two
|
|
|
|
|
> EOS
|
|
|
|
|
$ hg rebase -r d -d e
|
2019-10-16 02:28:01 +03:00
|
|
|
rebasing 211accd27e10 "d" (d)
|
2018-10-22 22:45:46 +03:00
|
|
|
merging a
|
|
|
|
|
merging b
|
|
|
|
|
warning: 1 conflicts while merging a! (edit, then use 'hg resolve --mark')
|
filemerge: print the potentially conflicting destination commits for each conflict
Summary:
One thing that makes dealing with merge conflicts difficult at Facebook is that it can be tough to know *why* you have merge conflicts.
Because rebase processes one commit at a time, it's clear which of *your* commits is the problem, but finding the "other" commit is surprisingly hard. Often we rebase onto `master`, and in a monorepo, `master` is often a random commit that has no relationship to your code at all.
This diff attempts to improve the situation a bit by listing all of the commits between the common ancestor and the destination commit that modified the file. The user can then identify which are likely culprits:
```
warning: 2 conflicts while merging b! (edit, then use 'hg resolve --mark')
3 commits might've introduced this conflict:
- [0942ca9aff3d] random commit 1
- [3ebd0a462491] foo bar biz
- [3e5843b4b236] blah blah blah
```
When the destination is public, this approach requires one loose file download (~0.5s?) per conflicted file (this pulls in the full filectx history DAG, so further downloads aren't needed), which is likely acceptable as it only runs on conflicts, and provides value to the user. But it's also configurable for users performing massive codemods.
I'll add metrics to gather the average number if matched commits and the time taken to generate.
This doesn't put this information into the conflict markers, so a lot of people (Nuclide users or the default `editmerge` users) won't see it. We need to think creatively about how to expose it to them.
The ideal solution would tell you which commits edited the actual conflicted section(s), not just those that touched the file.
This requires fast remotefilelog downloads (cc @[100000771202578:Arun] :)). Once we have those, we can construct a local `linelog` of the commits involved, and used this to identify precisely which commits edited the conflicted sections of the file.
Reviewed By: quark-zju
Differential Revision: D9816270
fbshipit-source-id: 04e08dea7a9429eaeab0d40310cd34355104bb74
2018-10-25 23:59:35 +03:00
|
|
|
1 commits might have introduced this conflict:
|
|
|
|
|
- [21906429c027] c
|
2018-10-22 22:45:46 +03:00
|
|
|
warning: 2 conflicts while merging b! (edit, then use 'hg resolve --mark')
|
filemerge: print the potentially conflicting destination commits for each conflict
Summary:
One thing that makes dealing with merge conflicts difficult at Facebook is that it can be tough to know *why* you have merge conflicts.
Because rebase processes one commit at a time, it's clear which of *your* commits is the problem, but finding the "other" commit is surprisingly hard. Often we rebase onto `master`, and in a monorepo, `master` is often a random commit that has no relationship to your code at all.
This diff attempts to improve the situation a bit by listing all of the commits between the common ancestor and the destination commit that modified the file. The user can then identify which are likely culprits:
```
warning: 2 conflicts while merging b! (edit, then use 'hg resolve --mark')
3 commits might've introduced this conflict:
- [0942ca9aff3d] random commit 1
- [3ebd0a462491] foo bar biz
- [3e5843b4b236] blah blah blah
```
When the destination is public, this approach requires one loose file download (~0.5s?) per conflicted file (this pulls in the full filectx history DAG, so further downloads aren't needed), which is likely acceptable as it only runs on conflicts, and provides value to the user. But it's also configurable for users performing massive codemods.
I'll add metrics to gather the average number if matched commits and the time taken to generate.
This doesn't put this information into the conflict markers, so a lot of people (Nuclide users or the default `editmerge` users) won't see it. We need to think creatively about how to expose it to them.
The ideal solution would tell you which commits edited the actual conflicted section(s), not just those that touched the file.
This requires fast remotefilelog downloads (cc @[100000771202578:Arun] :)). Once we have those, we can construct a local `linelog` of the commits involved, and used this to identify precisely which commits edited the conflicted sections of the file.
Reviewed By: quark-zju
Differential Revision: D9816270
fbshipit-source-id: 04e08dea7a9429eaeab0d40310cd34355104bb74
2018-10-25 23:59:35 +03:00
|
|
|
1 commits might have introduced this conflict:
|
|
|
|
|
- [21906429c027] c
|
2018-10-22 22:45:46 +03:00
|
|
|
unresolved conflicts (see hg resolve, then hg rebase --continue)
|
|
|
|
|
[1]
|
|
|
|
|
$ cat b
|
2019-12-17 05:10:38 +03:00
|
|
|
<<<<<<< dest: 2c5d04f1a41f e - test: e
|
2018-10-22 22:45:46 +03:00
|
|
|
b
|
|
|
|
|
=======
|
|
|
|
|
0
|
|
|
|
|
>>>>>>> source: 211accd27e10 d - test: d
|
|
|
|
|
2
|
|
|
|
|
3
|
|
|
|
|
4
|
|
|
|
|
5
|
2019-12-17 05:10:38 +03:00
|
|
|
<<<<<<< dest: 2c5d04f1a41f e - test: e
|
2018-10-22 22:45:46 +03:00
|
|
|
q
|
|
|
|
|
=======
|
|
|
|
|
9
|
|
|
|
|
>>>>>>> source: 211accd27e10 d - test: d
|
|
|
|
|
7
|
|
|
|
|
8 (no-eol)
|
|
|
|
|
$ cat c
|
|
|
|
|
c (no-eol)
|
|
|
|
|
|
filemerge: print the potentially conflicting destination commits for each conflict
Summary:
One thing that makes dealing with merge conflicts difficult at Facebook is that it can be tough to know *why* you have merge conflicts.
Because rebase processes one commit at a time, it's clear which of *your* commits is the problem, but finding the "other" commit is surprisingly hard. Often we rebase onto `master`, and in a monorepo, `master` is often a random commit that has no relationship to your code at all.
This diff attempts to improve the situation a bit by listing all of the commits between the common ancestor and the destination commit that modified the file. The user can then identify which are likely culprits:
```
warning: 2 conflicts while merging b! (edit, then use 'hg resolve --mark')
3 commits might've introduced this conflict:
- [0942ca9aff3d] random commit 1
- [3ebd0a462491] foo bar biz
- [3e5843b4b236] blah blah blah
```
When the destination is public, this approach requires one loose file download (~0.5s?) per conflicted file (this pulls in the full filectx history DAG, so further downloads aren't needed), which is likely acceptable as it only runs on conflicts, and provides value to the user. But it's also configurable for users performing massive codemods.
I'll add metrics to gather the average number if matched commits and the time taken to generate.
This doesn't put this information into the conflict markers, so a lot of people (Nuclide users or the default `editmerge` users) won't see it. We need to think creatively about how to expose it to them.
The ideal solution would tell you which commits edited the actual conflicted section(s), not just those that touched the file.
This requires fast remotefilelog downloads (cc @[100000771202578:Arun] :)). Once we have those, we can construct a local `linelog` of the commits involved, and used this to identify precisely which commits edited the conflicted sections of the file.
Reviewed By: quark-zju
Differential Revision: D9816270
fbshipit-source-id: 04e08dea7a9429eaeab0d40310cd34355104bb74
2018-10-25 23:59:35 +03:00
|
|
|
A merge conflict prints the possible conflicting commits:
|
|
|
|
|
$ newrepo
|
|
|
|
|
$ hg debugdrawdag <<'EOS'
|
|
|
|
|
> j
|
|
|
|
|
> | # d conflicts with c and h. e changed the file but doesn't
|
|
|
|
|
> i # conflict. We'll see that it gets included in the list as
|
|
|
|
|
> | # the algorithm isn't smart enough yet to know that.
|
|
|
|
|
> h # b/b = 1\n2\n3\n4\n5\n6\n7\n8
|
|
|
|
|
> | # c/b = b\n2\n3\n4\n5\nq\n7\n8
|
|
|
|
|
> g # d/b = 0\n2\n3\n4\n5\n9\n7\n8
|
|
|
|
|
> | # e/b = b\n2\n3\n4\n5\nq\n7\n8\nnot_conflicting
|
|
|
|
|
> f # h/b = c\n2\n3\n4\n5\nq\n7\n8\nnot_conflicting
|
|
|
|
|
> |
|
|
|
|
|
> e
|
|
|
|
|
> |
|
|
|
|
|
> c d
|
|
|
|
|
> |/
|
|
|
|
|
> b
|
|
|
|
|
> |
|
|
|
|
|
> | # "a" has two conflicts between g and d:
|
|
|
|
|
> | # g/a = one
|
|
|
|
|
> a # d/a = two
|
|
|
|
|
> EOS
|
|
|
|
|
$ hg rebase -r d -d j
|
2019-10-16 02:28:01 +03:00
|
|
|
rebasing 211accd27e10 "d" (d)
|
filemerge: print the potentially conflicting destination commits for each conflict
Summary:
One thing that makes dealing with merge conflicts difficult at Facebook is that it can be tough to know *why* you have merge conflicts.
Because rebase processes one commit at a time, it's clear which of *your* commits is the problem, but finding the "other" commit is surprisingly hard. Often we rebase onto `master`, and in a monorepo, `master` is often a random commit that has no relationship to your code at all.
This diff attempts to improve the situation a bit by listing all of the commits between the common ancestor and the destination commit that modified the file. The user can then identify which are likely culprits:
```
warning: 2 conflicts while merging b! (edit, then use 'hg resolve --mark')
3 commits might've introduced this conflict:
- [0942ca9aff3d] random commit 1
- [3ebd0a462491] foo bar biz
- [3e5843b4b236] blah blah blah
```
When the destination is public, this approach requires one loose file download (~0.5s?) per conflicted file (this pulls in the full filectx history DAG, so further downloads aren't needed), which is likely acceptable as it only runs on conflicts, and provides value to the user. But it's also configurable for users performing massive codemods.
I'll add metrics to gather the average number if matched commits and the time taken to generate.
This doesn't put this information into the conflict markers, so a lot of people (Nuclide users or the default `editmerge` users) won't see it. We need to think creatively about how to expose it to them.
The ideal solution would tell you which commits edited the actual conflicted section(s), not just those that touched the file.
This requires fast remotefilelog downloads (cc @[100000771202578:Arun] :)). Once we have those, we can construct a local `linelog` of the commits involved, and used this to identify precisely which commits edited the conflicted sections of the file.
Reviewed By: quark-zju
Differential Revision: D9816270
fbshipit-source-id: 04e08dea7a9429eaeab0d40310cd34355104bb74
2018-10-25 23:59:35 +03:00
|
|
|
merging a
|
|
|
|
|
merging b
|
|
|
|
|
warning: 1 conflicts while merging a! (edit, then use 'hg resolve --mark')
|
|
|
|
|
1 commits might have introduced this conflict:
|
|
|
|
|
- [395beecc0ab6] g
|
|
|
|
|
warning: 2 conflicts while merging b! (edit, then use 'hg resolve --mark')
|
|
|
|
|
3 commits might have introduced this conflict:
|
|
|
|
|
- [0942ca9aff3d] h
|
|
|
|
|
- [3ebd0a462491] e
|
|
|
|
|
- [3e5843b4b236] c
|
|
|
|
|
unresolved conflicts (see hg resolve, then hg rebase --continue)
|
|
|
|
|
[1]
|
