![]() (The actual lines are too small to draw here-there's just not enough room between lines-but git log -graph -all -decorate will show them: this time we leave out -oneline so there are more lines as will graphical viewers like gitk. In this case, just imagine that the labels ( HEAD, master) are slid up along the lines connecting the *s. * 009cda1 (HEAD, master) all somewhat alike ![]() In cases like that, the git log -all -decorate -graph -oneline (the order of these options does not matter) output looks more like: * 7cf123a (origin/master) lots of twisty In this case your git merge sees that it can simply "slide your branch up" to match theirs, which is a "fast forward" operation. The normal case-normal for your setup anyway-is that they can have commit(s) that you don't, but every commit you have, they also have. The -hard means "and also, throw away my current work-tree and replace it with the one attached to the commit I'm moving to now." The reset command means "take whatever my current branch is"-in this case, master-"and make it point to the exact same commit as I name here: origin/master". In both cases you can simply force your master to move to the same commit as their origin/master, with: git reset -hard origin/master With your latest git merge you're asking git to combine their old commit(s) and their new ones, and those are conflicting. But they've retracted these commit(s), and then perhaps made more new ones. You have them because you grabbed them at some point, with an earlier git fetch, and then put them on your master branch with an earlier git merge. ![]() If you did not make this (or these) commit(s), they must have retracted some commit(s). Then again, you have a commit they don't. | * 9124325 (HEAD, master) there a commit message 1 If you see: * 676699a (origin/master) here a commit message * d1574b8 (origin/master) another commit message If you see something like this: * f96824d (HEAD, master) some commit message (The git fetch step is just in case you're using an older git, where git pull runs git fetch in such a way that it skips a step, which will make the git log output misleading.) The log will show you where your branch-probably named master-ends, and where the "remote" ( origin/master) ends. The easiest way to do that is to run these two commands: git fetch Next, it's probably worth figuring out why git wants to do a merge in the first place. (You did use both, via git pull, and it was the merge that failed.) To end the attempt to merge, since you're in this state where it failed, you can just use: git merge -abort In any case, the first thing to do (if you don't want to just re-clone everything from scratch) is to terminate the conflicted merge, so that you're back to where you would be if you had used git fetch and not also used git merge. I'm taking you at your word that you have not done your own git commits. ![]() Note that if you are actively making your own changes, the merge conflict is not unusual after all. So, the solution to the problem lies in figuring out the "something unusual" and/or the person involved.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |