I made a change in gerrit which was code reviewed and after 7 revisions approved. But, now it cannot be merged and trying to rebase in gerrit website is not working due to merge conflict. How can I resolve this merge conflict and merge the same approved change and not create a new one.
(Full steps from cloning the repo would be appreciated.)
1) Clone the Gerrit repository
git clone https://USER#GERRIT-SERVER/a/REPO-FULL-PATHNAME
2) Go to the change page on Gerrit and copy the checkout patch command
git fetch https://USER#GERRIT-SERVER/a/REPO-FULL-PATHNAME refs/changes/XX/YYYYY/Z && git checkout FETCH_HEAD
3) Rebase the change
git rebase origin/BRANCH
4) Solve the conflicts
git mergetool
5) Continue the rebase
git rebase --continue
Repeat the steps 4 and 5 until the end of conflicts
git commit --amend
Note: Keep the same Change-Id
6) Send the new patchset to Gerrit
git push origin HEAD:refs/for/BRANCH
The accepted solution works but I personally disagree with this workflow. It is unnecessarily cumbersome.
I prefer a workflow with exactly one merge and therefore less steps.
Clone the Gerrit repository if not already available
git clone https://[USER]#[GERRIT-SERVER]/a/[REPO-FULL-PATHNAME]
Checkout the Gerrit patch
git fetch https://[USER]#[GERRIT-SERVER]/a/[REPO-FULL-PATHNAME] refs/changes/46/12346/N && git checkout FETCH_HEAD
Soft-reset the change and stash it
git reset --soft HEAD~1 && git stash
Checkout branch or the Gerrit patch you want to rebase onto
git checkout origin/BRANCH
# or fetch other Gerrit patch:
# git fetch https://[USER]#[GERRIT-SERVER]/a/[REPO-FULL-PATHNAME] refs/changes/45/12345/N && git checkout FETCH_HEAD
Unstash the previously stashed changes
git stash pop
Solve the conflicts with your favourite 3-way merge tool.
Commit the merged changes - NOT (!!) amend them - and use the same Change-Id from the merged patch in the message:
git commit -am "[COMMIT-MESSAGE]\
\
Change-Id: [FORMER-CHANGE-ID]"
Send the new patchset to Gerrit
git push origin HEAD:refs/for/BRANCH
Done. One merge!
I additionally use the gitreview tool. That makes it extra easy. Steps 2, 3, 4 and 5 then can be chained.
git review -d 12346 && git reset --soft HEAD~1 && git stash && git review -d 12345 && git stash pop
Related
I'm using git submodule commands to add this FSM repo in my project. I want to checkout a specific release commit. By default the master branch is checked out.
After adding the git repo, when I run
$ git submodule
It gives
d1b66d66cfa95f238a7498465908a262f4b2326a directory_path/fsmlite
The commit number here belongs to a master branch commit. How can I checkout another commit instead, using its commit number?
There might be some other way to do this, but I got the desired commit by
$ cd directory_path/fsmlite
$ git checkout v0.7.1 (this is the branch I wanted to point to)
$ git submodule update
$ cd parent_dir
$ git submodule
+de19ea0a71cb6082fe9311694a27e8f0cc2f972a directory_path/fsmlite (v0.7.1)
which is the specific commit number I wanted
I'm using 'git svn' to clone source from svn repository.
And use a branch to create new features.
The git log graph like
S1-S2+S3-S4-S5-S6-S7 (master)
+B1-B2-...-B9 (new-feature)
The newest svn version is 'S7' and the latest local branch is 'B9'. I want the graph be rebased like
S1-S2+S3-S4-S5-S6-S7+ (master)
+B2-B9 (new-feature)
My operation commands:
git checkout master
git svn rebase # it updated master to S7
git checkout new-feature
git rebase master
It will occurs many blank space conflicts, as I know that's because B1,B3...B8 have already checked in svn by other people. Is there smarter method to let me just keep some my patches which is not just space conflict? Here the B2,B9 are just examples. In fact, I don't know which patches should be replaced or merged or skipped in advanced. I just know, some of the svn check in are duplicate with some of Bx patches.
You should be able to simply do git svn rebase on your new-feature branch, no need to change to master iirc.
Regarding discarding the B2-B9 commits, you could e. g. do git checkout -B new-feature B1 && git cherry-pick B9. This will recreate the new-feature branch from B1 and cherry-pick the B9 commit. Or you do an interactive rebase like git rebase -i B1, then remove the lines for B2-B8 in the todo list and leave the editor. Or you can do a non-interactive rebase like git rebase --onto B1 B8 new-feature.
I cloned a SVN repository into a git repository using git svn clone. At that point in time, I did not have a username at that site and hence didn't use the --username option of clone. As I can now commit to the SVN repository with my new username, I would like to add that username. Without it, dcommit simply fails:
% LANG=C git svn dcommit
Committing to <THE URL> ...
RA layer request failed: Server sent unexpected return value (405 Method Not Allowed) in response to MKACTIVITY request for '/svn/!svn/act/0ceca4c5-f7b4-4432-94be-0485559a6040' at /usr/lib/git-core/git-svn line 945.
Is there a way to tell git about a new username? The git-svn manual doesn't seem to help: adding a username is only allowed on init and branch. I don't know how git works with SVN internally, but I guess there should be a way to add a username afterwards.
Note that I am using SVN over http.
You can specify the username in the dcommit command, e.g.
git svn dcommit --username=isapir
I think you can use this procedure (from the git svn manpage) to create a clone of your existing svn repository, but change the git svn init step so that it specifies a username. Your new git-svn repository will then have a username.
# Clone locally - make sure the refs/remotes/ space matches the server
mkdir project
cd project
git init
git remote add origin server:/pub/project
git config --replace-all remote.origin.fetch '+refs/remotes/*:refs/remotes/*'
git fetch
# Prevent fetch/pull from remote git server in the future,
# we only want to use git svn for future updates
git config --remove-section remote.origin
# Create a local branch from one of the branches just fetched
git checkout -b master FETCH_HEAD
# Initialize 'git svn' locally (be sure to use the same URL and -T/-b/-t options as were used on server)
git svn init --username my_new_name http://svn.example.com/project
# Pull the latest changes from Subversion
git svn rebase
Note that if you specify a username, you would not be able to dcommit a merge commit, not before Git 2.16.x/2.17 (Q1 2018).
That is because "git svn dcommit" did not take into account the fact that a
svn+ssh:// URL with a username# (typically used for pushing) refers
to the same SVN repository without the username# and failed when
svn.pushmergeinfo option is set.
See commit 8aaed89 (15 Sep 2017) by Jason Merrill (jwmerrill).
(Merged by Jason Merrill -- jwmerrill -- in commit 8aaed89, 17 Sep 2017)
git-svn: fix svn.pushmergeinfo handling of svn+ssh usernames.
Previously, svn dcommit of a merge with svn.pushmergeinfo set would
get error messages like
merge parent <X> for <Y> is on branch svn+ssh://gcc.gnu.org/svn/gcc/trunk,
which is not under the git-svn root svn+ssh://jason#gcc.gnu.org/svn/gcc!"
So, let's call remove_username (as we do for svn info) before comparing
rooturl to branchurl.
How can I do a git svn reset to HEAD revision without specifying the revision number?
It sounds like what you want is not a git svn reset but a simple git checkout. I'm not sure what you mean when you say you reverted to an older revision, but it may have been something like
$ git log
# scan through the log looking for a particular commit.
# You find it and its SHA1 is abc123...
$ git checkout abc123
You are now in 'detached HEAD' state blah blah blah...
Now, HEAD (in your git repository) refers to the commit with SHA1 abc123, whereas HEAD (in the central SVN repository) refers to the newest commit on the SVN repository. If you have things set up in a fairly typical way, then you can just do git checkout master and then git svn rebase and you're back to normal working conditions.
My typical git-svn workflow is:
git checkout -b story-xyz
git commit -a -m "work"
git commit -a -m "more work"
git checkout master
git svn fetch
git merge remotes/trunk
git checkout story-xyz
git rebase master (sometimes with -i)
git checkout master
git merge story-xyz
At this point I have my master and story-xyz branches pointing to the same commit, one or more commits ahead of remotes/trunk. Everything since remotes/trunk is in one linear history.
last svn commit [remotes/trunk] <--- work <--- more work [master, story-xyz]
I then run
git svn dcommit
I expected to see the commits between remotes/trunk and master become Subversion revisions, and end up with a single linear history with remotes/trunk, master and story-xyz all pointing to the latest revision, like so:
last svn commit <--- work <--- more work [master, story-xyz, remotes/trunk]
My Subversion revisions go in fine, but I end up with a two-branched structure. The common root of the branch is the Subversion HEAD before I committed. Both branches contain the same series of commits, in the sense that they contain the same diffs. The branch story-xyz is at the head of one branch, remotes/trunk and master at the other:
last svn commit <--- work <--- more work [master, remotes/trunk]
|
\- work <--- more work [story-xyz]
The git commits that I had before running git svn dcommit are on the lower branch (story-xyz), with my git commit messages, git user name and email, and git commit timestamps. The commits on the upper branch are new git commits. They use my Subversion username, the timestamp when I ran the dcommit, and the commit messages have the git-svn-id field appended to them.
This is all OK, and I can carry on working. The problem is that I look in gitk and see what looks like an unmerged branch story-xyz. It's pretty hard to tell the difference between a story branch that I have merged back into master, and one that I haven't. The most obvious way to spot it is the duplicate commit messages. I could delete the story-xyz branch, but that feels like I'm not using git properly and I've lost some of my history.
Am I missing something that would stop git-svn from doing this? Or is this just one of the ways that interacting with Subversion dilutes the power and freedom of git?
I don't think you're really missing anything. You might be doing some unnecessary work, though. In this case, you have two pointers to the "more work" commit, and you are asking git-svn to move one of them. The other one still stays where it is.
You don't really need the master branch. Git-svn doesn't care about what branch you are dcommiting. IIRC, it uses the first svn-remote it can find among the ancestors of the current commit.
I'll offer another version of the workflow:
git checkout -b story-xyz remotes/trunk
git commit -a -m "work"
git commit -a -m "more work"
git svn fetch
git rebase remotes/trunk (with -i, perhaps)
git svn dcommit
This should give you a tree without the extra branch. You need to be careful with fast-forward merges, though.