This is my current git-svn workflow:
git checkout -b feature master
# hack commit hack commit
git checkout master
git svn rebase
git merge feature
git svn dcommit
This usually works fine, git replays at the trunk all the commits from the local branch, and the only 'lost data' are the original commit's timestamps, no big deal.
But it looks like today there was something different about the merge and dcommit that caused the commit message on the SVN repo to be simply "Merge branch 'feature'", maybe because the feature was 'smaller', with only 2 or 3 commits.
How can I avoid this to happen and ensure that all commits and commit messages from git are replayed on the SVN repo?
That comment should be the result of a dcommit of a git merge, as illustrated in "Is git-svn dcommit after merging in git dangerous?":
(master)$> git log --graph --oneline --decorate
* 56a779b (work, master) Merge branch 'work'
|\
| * af6f7ae msg 3
| * 8750643 msg 2
| * 08464ae msg 1
|/
* 21e20fa (git-svn) last svn commit
In other words, if those three "msgx" commits had been done directly on master, they would have been replayed (with their original comments) on the svn side.
But here, only the resulting merge commit gets replayed, with the "generic" comment on it.
You will need to rebase from the feature branch first:
git checkout feature
git rebase master
This ensures that when you merge into your master, you only get a Fast-Forward rather than an actual merge.
My flow is usually more like this:
git checkout master
git svn rebase
git checkout feature
<hack...hack...hack>
git commit
git rebase master
git checkout master
git merge feature
I just make sure to do an svn rebase and then rebase all my feature branches to keep everything nice and linear the way that SVN likes it.
Also, if you're not aware of it, there is the git svn dcommit --dry-run option. I always use --dry-run and count the number of commits to make sure that git-svn is going to commit what I expect.
Related
I accidentally made the same commit twice, and then somehow merged them and now there's this commit called "Merge remote-tracking branch 'origin/lab1' into lab1" Also my local repository is apparently not synced, this seems simple but I'm stuck
Tried squashing commits into one on github desktop, but it says "Unable to squash. Squashing replays all commits up to the last one required for the squash. A merge commit cannot exist among those commits."
I know how to fix this on my local repository, but how do I remove that merge commit from github?
If that merge commit is the latest one on lab1, you can simply reset one commit earlier (make sure you don't have any work in progress):
git switch lab1
git reset --hard lab1~
git fetch
git rebase origin/lab1
git push
But you have done commits after that merge commit, then you need mark them and replay them:
git switch lab1
git branch <sha1 of the merge commit> m
git branch lab1 tmp
git reset --hard m~
git fetch
git rebase origin/lab1
git rebase --onto lab1 m tmp
git switch lab1
git merge tmp
git push
Basically, I would like to revert a central SVN repository back to a previous commit, kinda like this:
svn update
svn merge -r 150:140 .
svn commit -m "Rolled back to r140"
But I'm using git-svn and cannot seem to find an equivalent.
I've tried setting everything up locally on a new branch by checking out an earlier commit that was an ancestor of trunk (the current commit of the central repo). I made a few additional changes and now I cannot git svn rebase or git svn dcommit without getting an error from SVN.
I tried checking out that same commit without making the additional changes and then running git svn dcommit, this says it is committing to the central repo but doesn't actually seem to do anything.
How do I go back to a previous commit and then start making new changes?
Your task is essentially to reset your git HEAD into the state of r140, but in a way that would allow a straightforward git svn dcommit.
One way of doing this:
# checkout git revision of the desired state
git svn find-rev r140 | xargs git checkout
# reset HEAD to the revision 150, assuming it was the latest svn commit in trunk
git reset trunk
git add -u
git commit -m "Rolled back to r140"
git svn dcommit
You could also take a look on thread Revert multiple git commits
I have a forked project, and now the master repository has added a new branch which I want on my forked project.
Is it best practice to add the branch locally and then merge from the master repository, or is there a more correct way of doing this?
My guess is this, but I don't want to mess things up:
hg branch theNewBranch
hg pull -r theNewBranch ssh://hg#bitbucket.org/master_repository/theproject
hg merge 0011223344ff
hg commit -m "Merged in master repository branch"
There's no need to add it locally. Every commit has the branch it is on burned into it. If they have a commit on theNewBranch you'll get it.
If you want everything they have mirrored locally just do:
hg pull ssh://hg#bitbucket.org/master_repository/theproject
And if you want to merge in into your local branch do:
hg checkout mylocalbranch
hg merge theNewBranch
Can anyone please help me out doing a rebase on git?
It's really confusing, I'm not able to understand its functionality.
I want to rebase branch on master origin.
How do I do that? I also want to squash commits into one.
Take a look at the manual here.
Swith on your branch:
git checkout myBranch
Rebase it on your master:
git rebase master
If you want to squash some commits (for example on the last 10 commits) you've do an interactive rebase while you're on your branch:
git rebase -i HEAD~10
Then in your editor you can use the squash keyword to meld a commit in it previous commit.
We ran into a problem where, if you rebase your branch on top of master and then push, the other guy who was working on your branch pulls and gets all kind of merge conflicts, because the rebase has rewritten the history and the commits are not the same as they were on the branch. Is there any way around this, assuming that the other guy has some commits he wants to push to the branch?
Others should be able to rebase the branch after your push by using
git pull --rebase
You can check the "Recovering From Upstream Rebase" section of the git rebase man page.
Basically, your colleague will have to do (considering here 'subsystem' as having been rebased):
git rebase subsystem
(if his changes are on a separate branch)
or:
git rebase --onto subsystem subsystem#{1}