Gerrit: Fast Forward Only and Cherry-Pick

[johnny]

In Gerrit, we tried to use Fast Forward Only policy. But we found that
for an active project that have many developers working on it, almost
every patch need to be rebased and sent again. It is too inefficient.
So we fall back to Cherry-Pick, it works. However, I don't like the
commit messages Gerrit adds automatically, something like

Reviewed by: xxxx
Tested by: xxx
Submitted by: xxx
....

I wonder if I can configure Gerrit to remove those auto-generated
message.

Or whether there is other policy we can use. We don't want to use
merge related policy as we don't want to see the merge commit in the
branch, because we need release the code to customer in patches.

Regards,
Johnny

[Luciano Carvalho]

Why don't you use Always Merge or Merge as Needed ?

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

[Shawn Pearce]

On Sat, Sep 18, 2010 at 03:36, johnny <john...@gmail.com> wrote:
> In Gerrit, we tried to use Fast Forward Only policy. But we found that
> for an active project that have many developers working on it, almost
> every patch need to be rebased and sent again. It is too inefficient.
> So we fall back to Cherry-Pick, it works. However, I don't like the
> commit messages Gerrit adds automatically, something like
>
> Reviewed by: xxxx
> Tested by: xxx
> Submitted by: xxx
> ....
>
> I wonder if I can configure Gerrit to remove those auto-generated
> message.

Currently no. These are always added with the cherry-pick submit
type. But we might be able to add a new submit type that doesn't add
these footers, but that won't arrive until at least when 2.1.6 is
released later in October.

> Or whether there is other policy we can use. We don't want to use
> merge related policy as we don't want to see the merge commit in the
> branch, because we need release the code to customer in patches.

Nope, at that point you need to use "fast forward only" and rebase
manually, or use cherry-pick and deal with the footers.

[Shawn Pearce]

On Sat, Sep 18, 2010 at 11:28, Luciano Carvalho <lsca...@gmail.com> wrote:
> Why don't you use Always Merge or Merge as Needed ?

The original poster doesn't want merge commits in the branch. They
wish to have a single string of pearls, so they can easily generate a
list of patches from that string and hand those patches off to their
customer. Merge commits make for a less linear history, which can
make it a lot harder to understand patch ordering, etc.

[Brad Larson]

On Sep 20, 9:16 am, Shawn Pearce <s...@google.com> wrote:

> On Sat, Sep 18, 2010 at 11:28, Luciano Carvalho <lscar...@gmail.com> wrote:
> > Why don't you use Always Merge or Merge as Needed ?
>
> The original poster doesn't want merge commits in the branch.  They
> wish to have a single string of pearls, so they can easily generate a
> list of patches from that string and hand those patches off to their
> customer.  Merge commits make for a less linear history, which can
> make it a lot harder to understand patch ordering, etc.

In this case, maybe a 'cherry pick if necessary' submit type would
fit? I think it would make sense for that submit type to not amend
the commit message.

[Mihai Rusu]

We would like something like this too. It is very annoying for many
users to have to rebase their changes very often as it happens now
(which also resets the review score and spams reviewers/project
watches again). At the same time they don't want merge commits in
those branches.

--
Mihai Rusu

[johnny]

Shawn,

What's the status of version 2.1.6? Is it still on track?

Regards,
Johnny

On 9月20日, 下午10时15分, Shawn Pearce <s...@google.com> wrote:
> On Sat, Sep 18, 2010 at 03:36, johnny <johnny...@gmail.com> wrote:
> > InGerrit, we tried to useFastForwardOnlypolicy. But we found that

> > for an active project that have many developers working on it, almost
> > every patch need to be rebased and sent again. It is too inefficient.

> > So we fall back toCherry-Pick, it works. However, I don't like the
> > commit messagesGerritadds automatically, something like

>
> > Reviewed by: xxxx
> > Tested by: xxx
> > Submitted by: xxx
> > ....
>

> > I wonder if I can configureGerritto remove those auto-generated

[laurent....@ullink.com]

Hello,

We are right now using 2.7, and we also have this request, ie. Having a "Cherry Pick If necessary". So it will avoid developer to reset local his changes, if merge can be fast forward.

Is this planned, or something already exist and I missed it ?

Thanks for your help,

Laurent 

[Edwin Kempin]

2013/10/17 <laurent....@ullink.com>

Hello,

We are right now using 2.7, and we also have this request, ie. Having a "Cherry Pick If necessary". So it will avoid developer to reset local his changes, if merge can be fast forward.

Is this planned, or something already exist and I missed it ?

Have you tried the 'Rebase If Necessary' strategy?
  http://gerrit-documentation.googlecode.com/svn/Documentation/2.7/project-setup.html#submit_type

 

Thanks for your help,

Laurent 

On Monday, September 20, 2010 4:16:56 PM UTC+2, Shawn Pearce wrote:

On Sat, Sep 18, 2010 at 11:28, Luciano Carvalho <lsca...@gmail.com> wrote:
> Why don't you use Always Merge or Merge as Needed ?

The original poster doesn't want merge commits in the branch.  They
wish to have a single string of pearls, so they can easily generate a
list of patches from that string and hand those patches off to their
customer.  Merge commits make for a less linear history, which can
make it a lot harder to understand patch ordering, etc.

--

--
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/groups/opt_out.

[Laurent Barbisan]

Thanks for your quick Answer,

Actually we were using Rebase If Necessary before Cherry Pick, and the drawback of this is :

When dev are not using branches and do each fix on master, commit are dependent of each other, then a change set is not merged until previous change set is merged.

Note : we are still asking dev to do a branch each time they do a fix, but it's pretty hard to get them understand this coming from cvs world.

One think also I might need your help is : does cherry-pick conflict resolution more "tolerant" than rebase or it does use the same algorithm ?

--

Laurent BARBISAN | Software Architect - Trading Solutions | ULLINK | T: +33 1 44 50 77 49 | I: 22 88 | 23-25 rue de Provence | 75009 Paris | laurent....@ullink.com |

[Edwin Kempin]

2013/10/17 Laurent Barbisan <laurent....@ullink.com>

Thanks for your quick Answer,

Actually we were using Rebase If Necessary before Cherry Pick, and the drawback of this is :

When dev are not using branches and do each fix on master, commit are dependent of each other, then a change set is not merged until previous change set is merged.

Note : we are still asking dev to do a branch each time they do a fix, but it's pretty hard to get them understand this coming from cvs world.

One think also I might need your help is : does cherry-pick conflict resolution more "tolerant" than rebase or it does use the same algorithm ?

They use the same algorithm. What matters is here is the project setting for 'Automatically Resolve Conflicts' which decides whether a content merge should be tried or not.

[Laurent Barbisan]

Thanks for your replay. We get back to 'Rebase if Necessary' In then end.

On Thursday, October 17, 2013 2:59:09 PM UTC+2, Edwin Kempin wrote:

2013/10/17 Laurent Barbisan