On Thu, 29 Oct 2015 01:41:23 -0700 (PDT)
nmh <nidhimitta...@gmail.com> wrote:

> I did a 
> 
> 1) git clone 
> 2) git branch -b B1
> 3) git checkout B1

The steps 2-3 look strange.
You either do `git branch B1` followed by `git checkout B1`
or just `git checkout -b B1` which combines the former two steps.

> 4) made few changes to file a, b, c,d
> 5) git commit -a 
> 6) git review.(submitted to gerrit)
> 
> Got some review commentsfor file b,c
> i want to make changes to files b,c
> 
> 
> 1) git checkout B1
> 2) made changes to b,c
> 3) git status shows changed files as b,c only.
> 
> 
> before commiting i want to update the B1 with latest 
> changes.
> 
> what command should i use so that..

That's what `git rebase` is for.

You did not show us which branch B1 was forked off, so let's assume
that was "master".  If yes, you'd do:

  git fetch origin
  git rebase origin/master B1

The `git rebase` command will first reset your B1 for it to look like
the up-to-date state of "master", and then replay your changes on top
of it.  If there will be any conficts, `git rebase` will ask you to
resolve them and hint on how to proceed further so pay close attention
to what it tells to you.

> i get latest version of files a,b,c,d and i do not lose my changes.
> 
> i tried 
> 
> 1) git stash ..
> 2) git checkout filename
> 3) git stash pop
> 
> is this a right way ?

I doubt this.

> My doubt is .. if i do git stash .. what will it stash .. 
> either only latest changes of files b,c or all changes of files
> a,b,c,d???

The `git stash` saves any *uncommitted* changes.
Uncommitted means whatever changes are there compared to HEAD.
There are two places where such changes may be present: the index and
the work tree, and so `git stash` actually saves these two states: the
state of the index and the state of the work tree.
(Sometimes it may be useful to also consider untracked files as local
changes, and `git stash` can be told to save them as well.)

In contrast, `git rebase` operate on commits.  You commit your work and
them make `git rebase` arrange for that work to be relocated on top of
the current state of the branch your current branch has been originally
forked off.

Please also note that you're talking about Gerrit, and Gerrit is not
Git in that it might put additional constraints on your workflow --
that is, it might expect you to manage your changes in some
Gerrit-friently way.  Hence we here deal with Git and not Gerrit, I'd
ask your question on some Gerrit support channel to get more sensible
help.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to