Your change could not be merged due to a path conflict

[garjj23]

"Your change could not be merged due to a path conflict. Please merge
(or rebase) the change locally and upload the resolution for review."

I don't understand why this happens all the time in gerrit, even when
I am the only one submitting changes to a branch. But I don't even
care. What I want to know is what to do when it does happen? There is
no documentation or work flow examples I can find anywhere from
googling the message. The best I get is an anemic and ancient thread
in the gerrit discussion group about the android team have insane
preferences to do a lot of painful and mundane work to get around it,
and some explanation about jgit sucking. And also something about
using "repo sync" but I don't use repo, and I can't figure out what
git commands "repo sync" would be doing for me so I can do them
myself.

I'm new to git, but I'm not really having trouble using it. I am
however having a lot of trouble using gerrit. I don't know what it
means to "please merge (or rebase) the change locally." I currently
have 50 commits sitting in gerrit, the first of which hits this
"conflict" errror and holds up all the rest. Am I supposed to abandon
all these in gerrit and redo them? How?

Please, someone, can you outline exactly what commands I'm supposed to
run and what buttons I'm supposed to click in gerrit to solve this
craziness? I know I'm not the only one that hits this and is then
perplexed by the hand waving that is almost always given as an answer.
I don't want hand waving. I want to know how to fix this so I can get
some work done.

--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

[Shawn Pearce]

garjj23 <garyjeff...@gmail.com> wrote:
> "Your change could not be merged due to a path conflict. Please merge
> (or rebase) the change locally and upload the resolution for review."
>
> I don't understand why this happens all the time in gerrit, even when
> I am the only one submitting changes to a branch. But I don't even
> care. What I want to know is what to do when it does happen?

It occurs when the same file was modified by two different changes.

For example:

git checkout -b A master
vi README.txt
git commit -m "Adjust for A"

git checkout -b B master
vi README.txt
git commit -m "Adjust for B"

Since both branches A and B modified the same file, only one
can be submitted. The other will require the user to rebase the
change before Gerrit can submit it. This is because Gerrit cannot
(currently) merge file contents during change submit. Originally
this was a design decision, but now its simply a missing feature.

> There is
> no documentation or work flow examples I can find anywhere from
> googling the message. The best I get is an anemic and ancient thread
> in the gerrit discussion group about the android team have insane
> preferences to do a lot of painful and mundane work to get around it,

That's the design decision. The Andriod team doesn't want
file-content merges during submit. But not everyone who uses Gerrit
Code Review is the Android team at Google, and we realize Gerrit
needs to support a larger user base. So we've revised that to be
a missing feature.

> and some explanation about jgit sucking.

JGit has been missing the code necessary to provide the file-content
merge. Since it didn't exist, we couldn't call it within Gerrit.
Nor have we (Google) had time to develop it. Some folks over at
SAP have managed to build the merge code in JGit, but we haven't
had time to start calling it in Gerrit Code Review. Also, its
still really new code, it hasn't been nearly as battle-tested as
the git-core C implementation.

> And also something about
> using "repo sync" but I don't use repo, and I can't figure out what
> git commands "repo sync" would be doing for me so I can do them
> myself.

git rebase. Internally repo sync is using git rebase here.

> I'm new to git, but I'm not really having trouble using it. I am
> however having a lot of trouble using gerrit. I don't know what it
> means to "please merge (or rebase) the change locally." I currently
> have 50 commits sitting in gerrit, the first of which hits this
> "conflict" errror and holds up all the rest. Am I supposed to abandon
> all these in gerrit and redo them? How?

You don't need to abandon them.

Make sure you have the latest repository by running `git fetch`[1].

Checkout the branch for the next change you want to repair.

Use `git rebase origin/master`[2] to rebase the change onto the
current repository state.

Use the replacement upload[3] to send that new commit to Gerrit.

[1] http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html
[2] http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
[3] http://gerrit.googlecode.com/svn/documentation/2.1.2/user-upload.html#push_replace

> I don't want hand waving. I want to know how to fix this so I can get
> some work done.

Git is an incredibly powerful version control system. Using it
well really requires taking some time and learning how it works.
It doesn't try very hard to hold your hand through tasks.

Time and again we see people who are simply trying to apply recipes
fail, because they just don't understand what is going on.

Using Gerrit Code Review effectively really demands that you learn
to use Git, because it takes advantage of some of the more powerful
features. Things like amending a commit, rebasing a branch, etc.

So we don't really hand wave a lot. But instead are trying to point
folks to learn what is going on for themselves, and when they do,
they become much happier users.

[gary jefferson]

On Tue, May 11, 2010 at 6:43 PM, Shawn Pearce <s...@google.com> wrote:
> garjj23 <garyjeff...@gmail.com> wrote:
>> "Your change could not be merged due to a path conflict. Please merge
>> (or rebase) the change locally and upload the resolution for review."
>>
>> I don't understand why this happens all the time in gerrit, even when
>> I am the only one submitting changes to a branch. But I don't even
>> care. What I want to know is what to do when it does happen?
>
> It occurs when the same file was modified by two different changes.
>
> For example:
>
> git checkout -b A master
> vi README.txt
> git commit -m "Adjust for A"
>
> git checkout -b B master
> vi README.txt
> git commit -m "Adjust for B"
>
> Since both branches A and B modified the same file, only one
> can be submitted. The other will require the user to rebase the
> change before Gerrit can submit it. This is because Gerrit cannot
> (currently) merge file contents during change submit. Originally
> this was a design decision, but now its simply a missing feature.

This doesn't seem to be the pattern that leads to this message in my
case. I believe it has something to do with the fact that another
developer has my repo set as his remote origin, and then I commit all
of both of our changes, once merged, to gerrit. git supports this type
of workflow wonderfully. I think gerrit doesn't know how to deal with
it (although most of the time, it does work).

So what happens is, we're both working along, things are going great,
He's submitting stuff to me, I'm submitting stuff to gerrit all the
while (for both of us as his changes flow through me), no complaints
anywhere in the system. Then someone gets around to reviewing our
changes and approving them. I go back into gerrit to submit them, and
bam! path conflicts.

> You don't need to abandon them.
>
> Make sure you have the latest repository by running `git fetch`[1].
>
> Checkout the branch for the next change you want to repair.
>
> Use `git rebase origin/master`[2] to rebase the change onto the
> current repository state.
>
> Use the replacement upload[3] to send that new commit to Gerrit.
>
> [1] http://www.kernel.org/pub/software/scm/git/docs/git-fetch.html
> [2] http://www.kernel.org/pub/software/scm/git/docs/git-rebase.html
> [3] http://gerrit.googlecode.com/svn/documentation/2.1.2/user-upload.html#push_replace

Thank you, that is very useful.

But now I'm wondering if this is the easiest way to deal with the
mess. I currently have >70 commits sitting in gerrit, stuck. Because
my co-developer isn't talking to gerrit directly, his commits don't
have Change-Ids (even after I've cherry-picked them or otherwise
merged). All of these commits are jammed by the first one, which has a
path conflict. Step #3 looks like a lot of work to do for each of
these commits individually. Is there a quicker way? Can I tell gerrit
to just reset to the commit before the first one, then resubmit them
all with a push?

Or is that just going to get me back to "path conflict" land?

Thanks,
gj

[Shawn Pearce]

gary jefferson <garyjeff...@gmail.com> wrote:
> But now I'm wondering if this is the easiest way to deal with the
> mess. I currently have >70 commits sitting in gerrit, stuck. Because
> my co-developer isn't talking to gerrit directly, his commits don't
> have Change-Ids (even after I've cherry-picked them or otherwise
> merged).

You could still ask him to embed Change-Ids into his commits.
Just send him a copy of the commit-msg hook from Gerrit and request
that he install it if he's going to continue to send you changes.

> All of these commits are jammed by the first one, which has a
> path conflict. Step #3 looks like a lot of work to do for each of
> these commits individually. Is there a quicker way?

No. Change-Id was the invention we came up with to provide a
quicker way of doing a bulk rebase and replacement into Gerrit.

> Can I tell gerrit
> to just reset to the commit before the first one, then resubmit them
> all with a push?

No. You'll have to go through and abandon each change, and then
resubmit them all, and then get them reviewed again. Which won't
make a reviewer happy because a new change makes it impossible for
them to quickly review the delta from the prior version of that
same change.

> Or is that just going to get me back to "path conflict" land?

I still contend that you've effectively done what I described
earlier, which is to modify the same file concurrently with another
commit and now are expecting Gerrit to merge the file contents.
It won't do that and spits back this error instead.

If all 70 commits are ready to be submitted and merged, you might
be able to get them to go in by creating a merge commit between
the current branch head and the commit of the most recent change.
Upload that merge commit for review. Submit it first, then start
to submit all of the other commits in backwards order by following
down the Dependencies links in Gerrit's web UI. Eventually when
all 71 commits are in the submitted queue, Gerrit will submit the
entire group to the branch.

[Zeng Lames]

for such kind of problem, we use below steps to fix it, which can work well.

1.pull from origin

2.there should be conflict found during pull, fix the conflict and commit then

3.push to refs/for/targetBranch

4.review last commit

5.submit patchset for all dependency commit backward

On Tue, Oct 30, 2012 at 1:17 AM, s1m0n4 <simona.u...@gmail.com> wrote:

I recently ran into the same problem and the best way to fix it is to

• do an interactive rebase
• delete the change that is causing Gerrit path conflict
• go to "conflict merge land" and resolve conflicts
  
• push to refs/for/master
• review  all the changes

Now it should be OK. If you still see changes from your previous rebase attempts, it is best abandon them.

I hope it helps.

[Magnus Bäck]

On Monday, November 05, 2012 at 20:08 EST,

Zeng Lames <lezhi...@gmail.com> wrote:

> for such kind of problem, we use below steps to fix it, which can work well.
>
> 1.pull from origin
> 2.there should be conflict found during pull, fix the conflict and commit
> then

Actually, there's a good probability that there won't be an actual
conflict to resolve. Unless you have content merges enabled in Gerrit,
Gerrit will refuse to merge a change if it in any way touches a file
that's also been touched upstream. In other words, Gerrit's definition
of conflict is narrower that Git's, and it's likely that Git will
resolve the file(s) without manual intervention.

> 3.push to refs/for/targetBranch
> 4.review last commit
> 5.submit patchset for all dependency commit backward

While you can use "git pull" to solve path conflicts when you submit a
change, it's not the best course of action. You'll end up with a useless
merge commit that it doesn't make sense to review. Follow the previous
advice of rebasing the series of commits instead. Not only will you
avoid the useless merge commit (that makes the commit graph less
readable and makes bisection more difficult), but the commits will also
be easier to cherry-pick elsewhere since the commits have conflicts
resolved at the source rather than via a merge commit.

--
Magnus Bäck
ba...@google.com

[Quentin Neill]

" In other words, Gerrit's definition
of conflict is narrower that Git's"

Why exactly is that?  Is there a way to fall back to git's conflict definition?

We have "Submit: Cherry-pick" on, are using a recent version of gerrit, and it seems that:
   review1 +1 -> buildbot1 Verify+1 -> Submit [FAILS path conflict]
   review2 +1 -> buildbot2 Verify+1 -> Submit cherry pick

should really be
   review1 +1 -> buildbot1 Verify+1 -> Submit cherry pick

since __the exact same operation__ is done  (assuming rebase_1_patch == cherry_pick)

[Edwin Kempin]

2015-02-07 0:46 GMT+01:00 Quentin Neill <quenti...@gmail.com>:

" In other words, Gerrit's definition
of conflict is narrower that Git's"

Why exactly is that?  Is there a way to fall back to git's conflict definition?

We have "Submit: Cherry-pick" on, are using a recent version of gerrit, and it seems that:
   review1 +1 -> buildbot1 Verify+1 -> Submit [FAILS path conflict]
   review2 +1 -> buildbot2 Verify+1 -> Submit cherry pick

should really be
   review1 +1 -> buildbot1 Verify+1 -> Submit cherry pick

since __the exact same operation__ is done  (assuming rebase_1_patch == cherry_pick)

Check the "Automatically resolve conflict"[1] on your project.

[1] https://gerrit-review.googlesource.com/Documentation/project-configuration.html#submit_type

 

--

--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.