Gerrit Syncing

[Don Garrett]

Okay, I'm giving up and asking. I have looked for docs but probably missed it.

1) What exactly is the right way to update a local git repo from
Gerrit that has local changes in it?

2) What exactly is the right way to update a local git repo from
Gerrit if the local change has been pushed?

 I keep having a variety of random problems and each time I think I understand the workflow, something else weird happens.

Examples include:
  My local change disappears but can be cherry-picked from the reflog.
  Same as above, but the cherry-pick results in merge problems that go out of control.
  Merge changes get created which screw up future upload/sync type operations.
  Etc.

--
Don

[Gaurav Shah]

-team, +chromium-os-dev

On Wed, May 18, 2011 at 11:18 AM, Don Garrett <dgar...@google.com> wrote:

  Okay, I'm giving up and asking, and I have looked for docs but probably missed it.

1) What exactly is the right way to update a local git repo from Gerrit that has local changes in it?

Here's what I do:

$ <on my topic branch>

# Make sure all change files have been staged or locally committed (git add), or git won't let you change the branch.

$ git checkout cros/master

$ repo sync .

$ git checkout <topic branch>

# Re-base (optional)

$ git rebase cros/master

 

2) What exactly is the right way to update a local git repo from Gerrit if the local change has been pushed?

$ <let's say your change branch topic1 has already been merged>

$ repo abandon topic1

# This should drop you back to cros/master

$ repo sync .

"repo prune" is supposed to automatically get rid of topic branches whose changes have already been merged but I haven't been able to get it to work.

 

 I keep having a variety of random problems and each time I think I understand the workflow, something else weird happens.

Examples include:

  My local change disappears but can be cherry-picked from the reflog.

  Same as above, but the cherry-pick results in merge problems that go out of control.

  Merge changes get created which screw up future upload/sync type operations.

  Etc.

--

Don

--
You received this message because you are subscribed to the Google
Groups "Chrome OS-team" group.
To post to this group, send email to chrome...@google.com
To unsubscribe from this group, send email to
chromeos-tea...@google.com
For more options, visit this group at
http://groups.google.com/a/google.com/group/chromeos-team?hl=en
For more information about Google Chrome OS please visit: http://go/chromeos

--
-g

[Chris Sosa]

My usual workflow is to:

repo start <branch> .
<make changes>
git commit -am "branch stuff"
repo sync .
repo rebase .
repo upload .

If I finish commiting the first and want to work on another change
that is associated with this branch, I just stay on it.

Make changes.
git commit -am "new branch msg"
repo sync .
repo rebase . <this time it'll say that it found my previous commit
upstream and say it's already been merged>
repo upload .

Eventually when I don't need this branch I can repo abandon .

> --
> Chromium OS Developers mailing list: chromiu...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-os-dev?hl=en
>

[Don Garrett]

On Wed, May 18, 2011 at 6:14 PM, Chris Sosa <so...@chromium.org> wrote:

My usual workflow is to:

repo start <branch> .
<make changes>
git commit -am "branch stuff"
repo sync .
repo rebase .
repo upload .

That work flow is what I started doing naturally, but has sometimes led to my changes vanishing from the branch, but I can't figure out why. If that happens, they can be found in the reflog and cherry-picked back in.... mostly.

--
Don

[Chris Masone]

On Wed, May 18, 2011 at 7:58 PM, Don Garrett <dgar...@chromium.org> wrote:

On Wed, May 18, 2011 at 6:14 PM, Chris Sosa <so...@chromium.org> wrote:

My usual workflow is to:

repo start <branch> .
<make changes>
git commit -am "branch stuff"
repo sync .
repo rebase .
repo upload .

That work flow is what I started doing naturally, but has sometimes led to my changes vanishing from the branch, but I can't figure out why. If that happens, they can be found in the reflog and cherry-picked back in.... mostly.

This is what I do too, and I've never had the issue you're talking about.  I did have a surprising experience once when I did repo sync -d .

you could do repo rebase -i . to manage what patches it will apply and such...

[Bill Richardson]

On Wed, May 18, 2011 at 7:58 PM, Don Garrett <dgar...@chromium.org> wrote:

That work flow is what I started doing naturally, but has sometimes led to my changes vanishing from the branch, but I can't figure out why. 

I've occasionally had that problem too, and I recommend gitk.  I was able to see what happened by using 'gitk --all' and editing the view to enable "All (local) branches".  Instead of just rebasing my local branch to include the new gerrit commit, it ended up creating a local unnamed branch/merge with the same change in it. Or something. I can usually figure out what git has done and it seems to make sense in retrospect, but I'm sometimes surprised.

Bill 

--

Art for Art's Sake

Engineering for Money

[Mandeep Singh Baines]

Chris Masone (cma...@chromium.org) wrote:
> On Wed, May 18, 2011 at 7:58 PM, Don Garrett <dgar...@chromium.org> wrote:
>
> >
> > On Wed, May 18, 2011 at 6:14 PM, Chris Sosa <so...@chromium.org> wrote:
> >
> >> My usual workflow is to:
> >>
> >> repo start <branch> .
> >> <make changes>
> >> git commit -am "branch stuff"
> >> repo sync .
> >> repo rebase .
> >> repo upload .
> >>
> >>
> > That work flow is what I started doing naturally, but has sometimes led to
> > my changes vanishing from the branch, but I can't figure out why. If that
> > happens, they can be found in the reflog and cherry-picked back in....
> > mostly.
> >
>
> This is what I do too, and I've never had the issue you're talking about. I
> did have a surprising experience once when I did repo sync -d .
>

This is also what I do.

I would recommend emailing/searching repo-discuss in the future for any
repo-related issues. The nice thing about repo is that there is a large
community behind it.

http://groups.google.com/group/repo-discuss