Re: [git-users] force merge to fix conflicts?
On Thursday, August 9, 2012, THUFIR HAWAT wrote: > I think that I do want to zap the master branch; git reset --hard origin will delete everything in origin, or just everything in master on origin? In this case, I'm using github. 'git reset' always affects the branch you have checked out, not anything on the remote. What it does is *move* the current branch pointer. In Git, history is represented as a graph of commits, and a branch or a tag is a pointer to a particular commit. If your history looks like this: 7daf362 * [master] |\ 3b1d46c | * [other-branch] | |\ |/ / c516377 | * 8c5c842 * | [etc...] and you have 'master' checked out, then after you run 'git reset c516377' it will look like this: 3b1d46c * [other-branch] |\ c516377 | * [master] 8c5c842 * | [etc...] 7daf362 is still recoverable from the reflog for (by default) at least 90 days, but but eventually it will be deleted by the garbage collector. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] force merge to fix conflicts?
On Thursday, 9 August 2012 00:29:20 UTC-7, Peter J Weisberg wrote: > > On Wed, Aug 8, 2012 at 10:53 PM, THUFIR HAWAT > > > wrote: > > I get conflicts when trying to merge: https://gist.github.com/3301009 > > > > What I want to do is to take commit x to branch 4 and put it "ontop"(?) > of > > commit y on branch "master." Is that not a merge? > > > > What does it matter when there's a conflict, isn't that the very meaning > of > > merge, that you are saying, yes, these two things are different, replace > > "this one" with "that one"? > > You can use 'git merge -s ours' essentially to mark the other branch > as having been merged into the current branch, without actually > incorporating any of the changes in the other branch. There is no > corresponding "theirs" strategy. Ask yourself: why do you want to > discard the changes you made on this branch? And if you're sure you > *do* want to discard the changes on the current branch, do you really > need to keep the history of your failure? (Paraphrased from [1]) > > > When would have a merge *without* conflicts, and why? > > If the changes on the other branch didn't affect the same files as the > changes on this branch, or if the changes were far enough apart (in > terms of which lines were affected) that Git can be reasonably sure > there's no overlap. > > [1] http://marc.info/?l=git&m=121637513604413&w=2 > > -PJ > > Gehm's Corollary to Clark's Law: Any technology distinguishable from > magic is insufficiently advanced. > Aha, thanks for explaining about merge, at least now I see why that merge fails, it's too small. Interesting. I think that I do want to zap the master branch; git reset --hard origin will delete everything in origin, or just everything in master on origin? In this case, I'm using github. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To view this discussion on the web visit https://groups.google.com/d/msg/git-users/-/nrJyJ0qwOb8J. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
Re: [git-users] force merge to fix conflicts?
On Wed, Aug 8, 2012 at 10:53 PM, THUFIR HAWAT wrote: > I get conflicts when trying to merge: https://gist.github.com/3301009 > > What I want to do is to take commit x to branch 4 and put it "ontop"(?) of > commit y on branch "master." Is that not a merge? > > What does it matter when there's a conflict, isn't that the very meaning of > merge, that you are saying, yes, these two things are different, replace > "this one" with "that one"? You can use 'git merge -s ours' essentially to mark the other branch as having been merged into the current branch, without actually incorporating any of the changes in the other branch. There is no corresponding "theirs" strategy. Ask yourself: why do you want to discard the changes you made on this branch? And if you're sure you *do* want to discard the changes on the current branch, do you really need to keep the history of your failure? (Paraphrased from [1]) > When would have a merge *without* conflicts, and why? If the changes on the other branch didn't affect the same files as the changes on this branch, or if the changes were far enough apart (in terms of which lines were affected) that Git can be reasonably sure there's no overlap. [1] http://marc.info/?l=git&m=121637513604413&w=2 -PJ Gehm's Corollary to Clark's Law: Any technology distinguishable from magic is insufficiently advanced. -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To post to this group, send email to git-users@googlegroups.com. To unsubscribe from this group, send email to git-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
