git pull vs git fetch

[Anthony]

A lot of users end up causing merge conflicts because they use `git
pull` provided by Gerrit. Unfortunately git can't easily squash this
(as far as I know), so right now I tell them to work around it by
doing something like `repo start TMP . && git cherry-pick -m 1 <sha of
merge>`.

I think it would be a lot nicer if Gerrit gave a fetch command instead
(and maybe a cherry-pick with it even), like:
git fetch .... && git cherry-pick FETCH_HEAD

Thoughts?

[Nasser Grainawi]

Sounds reasonable to me. I think our users would appreciate that since it's not
blatantly clear to non-git pros that they could just change the command a bit
to have it do a fetch and then a cherry-pick (and that is the mode that most
people use the git-pull line in now).

Nasser

[Jean-Baptiste Queru]

I think it could be cool if repo download could leave you on a "real"
head (i.e. not a detached head), configured to be publishable, to know
what has been published already, and to remember the change number for
the next repo upload --replace. An extra option to automatically
rebase on top of the latest would be gravy :)

JBQ

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



--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

[Mike Lockwood]

Yes, I also avoid the git pull. I do "git fetch <url>" followed by
"git cherry-pick FETCH_HEAD"

Mike

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



--

Mike Lockwood
Google android team

[Shawn Pearce]

On Wed, Nov 18, 2009 at 08:33, Mike Lockwood <lock...@android.com> wrote:
> Yes, I also avoid the git pull.  I do "git fetch <url>" followed by
> "git cherry-pick FETCH_HEAD"

Me too.

I think what we're all saying is, we need to change that command. :-)

[Jean-Baptiste Queru]

BTW, when doing code reviews (and especially on AOSP), I do use git
pull as my primary tool : it's the easiest way to have an idea about
what's going to happen on the server, and to anticipate future merge
conflicts. So, there's a use case for it, but it's not what most
people (and especially non-experts) need to use for their common use
case.

JBQ

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



--

[Anthony]

I also use `git pull` for all my code review, but I don't think this
case would be any different if we changed it to a fetch/cherry-pick,
because you would still see the merge conflict.

I can see how `repo download` would be helpful, but I never use it.
For the workflow around here, I think just changing `repo download` to
do a fetch/cp would be best and get rid of the other option. If a lot
of others use this command, maybe a second command or a parameter
could be added. Perhaps `repo download --original` or something for
what `repo download` does right now?

On Nov 18, 10:42 am, Jean-Baptiste Queru <j...@android.com> wrote:
> BTW, when doing code reviews (and especially on AOSP), I do use git
> pull as my primary tool : it's the easiest way to have an idea about
> what's going to happen on the server, and to anticipate future merge
> conflicts. So, there's a use case for it, but it's not what most
> people (and especially non-experts) need to use for their common use
> case.
>
> JBQ
>
>
>
> On Wed, Nov 18, 2009 at 8:37 AM, Shawn Pearce <s...@google.com> wrote:

> > On Wed, Nov 18, 2009 at 08:33, Mike Lockwood <lockw...@android.com> wrote:
> >> Yes, I also avoid the git pull.  I do "git fetch <url>" followed by
> >> "git cherry-pick FETCH_HEAD"
>
> > Me too.
>
> > I think what we're all saying is, we need to change that command.  :-)
>

> >> On Wed, Nov 18, 2009 at 11:24 AM, Anthony <m.bn...@gmail.com> wrote:
> >>> A lot of users end up causing merge conflicts because they use `git
> >>> pull` provided by Gerrit. Unfortunately git can't easily squash this
> >>> (as far as I know), so right now I tell them to work around it by
> >>> doing something like `repo start TMP . && git cherry-pick -m 1 <sha of
> >>> merge>`.
>
> >>> I think it would be a lot nicer if Gerrit gave a fetch command instead
> >>> (and maybe a cherry-pick with it even), like:
> >>> git fetch .... && git cherry-pick FETCH_HEAD
>
> > --
> > To unsubscribe, email repo-discuss...@googlegroups.com

> > More info athttp://groups.google.com/group/repo-discuss?hl=en

[Jean-Baptiste Queru]

Actually, fetch+cherry-pick wouldn't show the path conflicts as
"easily" as git pull does.

Anyway, let's be practical instead of speaking in a vacuum. I'd be
happy with two new options in repo download:

-b <branch> : creates a new branch for the change being downloaded
(analogous to git checkout)

-r --rebase : attempts to rebase the change on top of the latest head.
In case of failure to rebase, this option has no effect.

JBQ

> More info at http://groups.google.com/group/repo-discuss?hl=en