Failure to submit due to path conflict but no real conflict.

250 views
Skip to first unread message

Ahmon Dancy

unread,
Apr 16, 2010, 5:56:10 PM4/16/10
to Repo and Gerrit Discussion
I saw an older post on this subject but I've like to revive the
discussion and maybe get some idea of why things work as they do now:

http://groups.google.com/group/repo-discuss/browse_thread/thread/8d9759789cf34b15/dcdac655b7a667ce?lnk=gst&q=conflict#dcdac655b7a667ce

The gist is "Gerrit is currently very conservative and refuses to
submit a change
if another user touched a same file in the meantime, even if the two
changes done in that file don't conflict with one another."

I'd like to understand why gerrit makes no attempt to merge the
changes on your behalf.

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

Shawn Pearce

unread,
Apr 16, 2010, 6:14:51 PM4/16/10
to Ahmon Dancy, Repo and Gerrit Discussion
On Fri, Apr 16, 2010 at 14:56, Ahmon Dancy <da...@dancysoft.com> wrote:
> I saw an older post on this subject but I've like to revive the
> discussion and maybe get some idea of why things work as they do now:
>
> http://groups.google.com/group/repo-discuss/browse_thread/thread/8d9759789cf34b15/dcdac655b7a667ce?lnk=gst&q=conflict#dcdac655b7a667ce
>
> The gist is "Gerrit is currently very conservative and refuses to
> submit a change
> if another user touched a same file in the meantime, even if the two
> changes done in that file don't conflict with one another."
>
> I'd like to understand why gerrit makes no attempt to merge the
> changes on your behalf.

Two reasons:

1) The Android team initially preferred this setting, because that is
how Perforce works. Perforce by default won't attempt a content level
merge on a file unless you tell it to. Coming from Perforce, they
felt this was a safer tool to use. Now that they have been using git
rebase for a long time to resolve these messages in Gerrit, they might
be more open to the idea of Gerrit doing these merges on its own more
often.

2) JGit, the Git library underneath of Gerrit that does all of the
"real work", doesn't support content level merges. Its being actively
developed right now. So we still don't have the implementation
available to be invoked. Yea, we could have called out to the C code,
but we try to avoid that, it gets messy fast as the C merge wants a
working directory. Ick.

Kevin

unread,
Apr 17, 2010, 9:46:15 PM4/17/10
to Repo and Gerrit Discussion
Shawn, thanks for the info. I must say, this is a huge fly in the
ointment for us. We've been in production for a whole day and it's
already come up that a developer submitted 3 changes that each touched
at least one file. Because of this mis-feature, here's the workflow I
have to go through with the developer:

1. developer submits 3 changes
2. I cherry-pick, test, approve and submit #1, then #2, getting an
error.
3. developer has to rebase #2 and resubmit.
4. I approve #2 and submit, approve #3 and submit, getting and error.
5. developer has to rebase #3 and resubmit.
6. I approve #3 and submit

That is a *lot* of back and forth when there shouldn't be any at all.

I've already got developers bitching at me, too.

Any idea when JGit will have the necessary features for Gerrit to
use? When it is, do you feel the feature will be implemented?

Thanks.

Kevin

On Apr 16, 3:14 pm, Shawn Pearce <s...@google.com> wrote:
> On Fri, Apr 16, 2010 at 14:56, Ahmon Dancy <da...@dancysoft.com> wrote:
> > I saw an older post on this subject but I've like to revive the
> > discussion and maybe get some idea of why things work as they do now:
>
> >http://groups.google.com/group/repo-discuss/browse_thread/thread/8d97...

Simon Wilkinson

unread,
Apr 18, 2010, 5:19:49 AM4/18/10
to Kevin, Repo and Gerrit Discussion

On 18 Apr 2010, at 02:46, Kevin wrote:

> Shawn, thanks for the info. I must say, this is a huge fly in the
> ointment for us. We've been in production for a whole day and it's
> already come up that a developer submitted 3 changes that each touched
> at least one file. Because of this mis-feature, here's the workflow I
> have to go through with the developer:

If you're having to do this amount of back and forth, then you've
either got a tree that has a spectacular level of churn in it, or your
developers aren't using git particularly well.

It isn't clear to me from your example, but is your developer
submitting 3 changes that all touch the same file? If so, then those
changes should be created on the same topic branch. They may need to
rebase and resubmit the whole topic branch if the file has changed
since the branch was created, but after that each change will apply
without a problem.

Personally, having dealt with cases where automated merges have gone
spectacularly wrong, I'd much rather have gerrit be conservative in
this regard.

Cheers,

Simon.

Shawn Pearce

unread,
Apr 18, 2010, 9:22:35 PM4/18/10
to Simon Wilkinson, Kevin, Repo and Gerrit Discussion
Eventually it will be an option to do file-level content merges in
Gerrit, but I don't see it happening in the immediate future. Its
less of a problem for most current Gerrit users than you might think,
because as Simon points out, you usually can avoid a lot of this
back-and-forth by using a proper topic branch, and avoiding churn in a
file by better organizing who is working on what. So right now we're
more focused on the read access controls and fixing some of the more
critical transport related bugs.

Ahmon Dancy

unread,
Apr 19, 2010, 11:24:44 AM4/19/10
to Shawn Pearce, Simon Wilkinson, Kevin, Repo and Gerrit Discussion
Shawn/Simon, I'm confused about your position on topic branches.  It was always my understanding that if you have, say, two unrelated features/bugs/whatever to work on, you do the work for each topic on a separate topic branch.  But you seem to suggest that this is the wrong way to use topic branches.

Shawn Pearce

unread,
Apr 19, 2010, 12:31:17 PM4/19/10
to Ahmon Dancy, Simon Wilkinson, Kevin, Repo and Gerrit Discussion
On Mon, Apr 19, 2010 at 08:24, Ahmon Dancy <da...@dancysoft.com> wrote:
> Shawn/Simon, I'm confused about your position on topic branches.  It was
> always my understanding that if you have, say, two unrelated
> features/bugs/whatever to work on, you do the work for each topic on a
> separate topic branch.  But you seem to suggest that this is the wrong way
> to use topic branches.

It depends.

If the changes are touching different files, yes, they probably belong
in different topic branches.

If the changes are touching the same file, but you really can't
predict in what order the maintainer wants to merge them in, then they
belong in different topic branches so they can be worked on
independently more easily. But at some point these have to be merged,
and the merge result has to be tested. And this is where the Gerrit
workflow will require a lot of back-and-forth between the author and
the reviewer, as they work through the merge permutations, test each
merge, review it, and eventually submit it.

If on the other hand there are multiple changes to the same files and
there is a logical progression of those changes, they belong in a
single topic branch. This makes it easier for others to follow along
with the development, and its cleaner to apply that series because the
merge conflicts have already been resolved and dealt with. So
sometimes, yes, you can branch too much or too aggressively in Git,
and just need to fall back to a slightly larger granularity on your
branch.
Reply all
Reply to author
Forward
0 new messages