repo sync error: branch XYZ is published (but not merged) and is now 1 commits behind
nature lover
second patchset, was asked to make
some more modifications for an improvement. The overall change/patch
itself is pending approval, and has
not yet been merged.
I made the modificatione needed, and did “git add” on 6 (6 files had
changed since the last patchset) of the
total 7 files that are part of the change, and did a "git commit --
amend -s".
Then I remembered that one of the files had been set incorrectly with
non-default values for two debug flags
in the above commit. So I went back and changed that one file again,
then did an “git add” of that one file,
and a “git commit --amend -s”, which went through withour errors, same
as the first “git add” and “commit
--amend -s” above.
When I did a repo sync again prior to doing the repo upload, I got the
following error:
"error: <git project path name>: branch topic1 is published (but not
merged) and is now 1 commits behind"
What is the best/easiest way to fix this and do the repo upload?
thanks in advance.
Magnus Bäck
nature lover <ejk...@gmail.com> wrote:
> I had submitted two patchsets for a change, and after the review of
> second patchset, was asked to make
> some more modifications for an improvement. The overall change/patch
> itself is pending approval, and has
> not yet been merged.
[...]
> When I did a repo sync again prior to doing the repo upload, I got the
> following error:
>
> "error: <git project path name>: branch topic1 is published (but not
> merged) and is now 1 commits behind"
Yes, someone else apparently merged a change between the last time you
synced (and you started your work) and now.
> What is the best/easiest way to fix this and do the repo upload?
This is not a fatal error; the sync was successful and you'll still be
able to upload your change. However, you might not be able to submit it
after approval. You might as well rebase the commit first.
git rebase origin/master
(Or whatever your upstream is named.)
--
Magnus Bäck Opinions are my own and do not necessarily
SW Configuration Manager represent the ones of my employer, etc.
Sony Ericsson
nature lover
Thanks very much for your feedback.
I know for sure that there were no changes to any of the files in my
patchset that were
done by anyone else in our team, in between, as you had surmised.
To summarize what I did in this scenario, for clarity:
1) Submitted two patchsets. The first one was done using "commit -s",
and the second one
using "commit --amend -s", which were peer reviewed under gerrit.
The overall
change/patch has not been approved or merged as yet.
2) Made more changes to some of the files, and added and "commit --
amend -s" done on six files.
3) Did a repo sync, got no errors, but before doing a repo upload, I
made one more change in one
of the six files, and added and did "commit --amend -s" on that one
file. No errors so far.
4) Did a repo sync, and got the error as mentioned above. Did not do a
repo upload yet.
To recover from this error, you had suggested "git rebase origin/
master". To clarify, here are
the details in my case:
branch: topic1 (started with "repo start topic1 --all" after "repo
init" and "repo sync"
were done in the directory <my home dir>/gingerbread
project: <my home dir>/gingerbread/hardware/intel/PRIVATE/cmfwdl/
lib/, under which the .git
directory for all the files in my patch are located.
Could you please clarify:
1) What is "origin" and "master" in the case of using "git rebase
origin/master"?
2) What is meant by "upstream" in this case?
3) If I do a rebase as you mentioned, would any of the changes be
lost?
4) What would be the next step, to complete the submission of this
patchset?
(As I am new to git, I do apologise for my ignorance of the terms
used.)
Thanks agoan for your feedback.
On Aug 9, 5:16 am, Magnus Bäck <magnus.b...@sonyericsson.com> wrote:
> On Tuesday, August 09, 2011 at 01:03 CEST,
Magnus Bäck
nature lover <ejk...@gmail.com> wrote:
> I know for sure that there were no changes to any of the files in my
> patchset that were done by anyone else in our team, in between, as you
> had surmised.
That's easy to check.
git log origin/master..HEAD
(Assuming origin/master is the upstream and you've got your topic branch
checked out.)
[...]
> 1) What is "origin" and "master" in the case of using "git rebase
> origin/master"?
"origin" is the name of the so-called remote, and "master" is the name
of the branch that your change eventually will end up in.
> 2) What is meant by "upstream" in this case?
The remote branch on the server (to which you upload your commits)
is upstream from you. You are downstream to the remote branch on the
server.
> 3) If I do a rebase as you mentioned, would any of the changes be
> lost?
No, of course not.
> 4) What would be the next step, to complete the submission of this
> patchset?
Do the rebase as described, upload the commit, verify and review it,
and press submit.
> (As I am new to git, I do apologise for my ignorance of the terms
> used.)
No apology needed, but if this is something you'll be doing on a regular
basis you might want to consider getting a good Git book (or ask a
colleague or someone from your local community to help). You have a
learning curve ahead.
nature lover
Thanks for clarifying. I'm still trying to find out with others on-
site
what exactly "origin" and "master" should be, as it is still not clear
as to what value/string/???? should be used for those parameters.
The learning curve on Git seems to be unusual for a repository/
version
control system. I've found most of the others to be fairly intuitive.
On Aug 9, 11:19 am, Magnus Bäck <magnus.b...@sonyericsson.com> wrote:
> On Tuesday, August 09, 2011 at 18:42 CEST,
