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
Related
1347
Is there any way to revert or undo git pull so that my source/repos will come to old state that was before doing git pull ? I want to do this because it merged some files which I didn't want to do so, but only merge other remaining files. So, I want to get those files back, is that possible?
You can do git reset --hard HEAD~1 to revert to the commit before the merge commit (assuming that's the latest). If you've made additional commits after the merge one, you would do git reset --hard HEAD~n where n is the number of commits after the merge + 1.
I was wondering if a branch is cloned from master. And now you remove some commits from master and force push. Will those commits be deleted on the cloned branch as well?
No: a branch starting from a commit of another branch will still reference that commit, even if that other branch changes (through a forced push) its HEAD.
You might want to rebase your branch on top of the new reset master, if you don't want to continue referencing those old commits.
git fetch
# see that origin/master has been reset
git checkout mybranch
git rebase --onto origin/master master myBranch
In that scenario, master is still locally at the old HEAD (from which you current branch is starting).
origin/master has been reset (and is up-to-date after the git fetch)
After that, you can reset your own local master:
git checkout master
git reset --hard origin/master
(make sure you don't have any work in progress when doing a git reset --hard)
I searched this but unable to find my answer.
And I just want to know the non command line way to do this....
Or is there any other way to achieve this same ?
You can delete files (from a repo you own, like a fork)
But you cannot directly from the web interface delete commits.
For that you would need to clone, do an interactive rebase (dropping the commits you don't want) and git push --force.
Even a revert does not seem possible.
The OP adds:
Actually I have 3 branches one is master and rest two are patch-1 and patch-2 and I messed up with master branch before creating patch-1 and patch-2 branches so some useless commits are also cloned from master to patch-1 and patch-2 branch so please can you help me to delete those commits which are cloned from master?
No without cloning the repo though:
git clone /url/of/your/fork
cd yourfork
git remote add upstream /url/original/repo
git fetch upstream
git checkout -b patch-1 origin/patch-1
git checkout -b patch-2 origin/patch-2
Then replay your patches on top of upstream master:
git rebase --onto upstream/master master patch-1
git rebase --onto upstream/master master patch-2
Finally reset master to the upstream master branch:
git checkout master
git reset --hard upstream/master
And then push everything back to your fork:
git push --force --mirror
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
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.