On Thu, Oct 26, 2017 at 10:56:14PM -0700, Mitch Negus wrote:
> When reading through this Atlassian tutorial on Git
> <https://www.atlassian.com/git/tutorials/merging-vs-rebasing>, it says that
> the set of commands
> git checkout feature
> git merge master
> can be condensed into the one-liner
> git merge master feature
> presumably to avoid needing to checkout the feature branch. I have not
> found this command to work though. Instead, when I run the one-liner in the
> master branch of my repository, it merges the feature branch into the
> master branch, rather than the opposite. Is this a mistake in the Atlassian
> tutorial, am I missing a set of circumstances where this action applies, or
> am I maybe just misinterpreting this entirely?
I would say it's a mistake (did not read the document at the provided
link though, sorry): the basic usage of the `git merge` command is as
follows:
$ git merge [OPTIONS] COMMIT [COMMIT...]
That is, it does not really merges branches, it merges commits pointed
to by whatever you specify — having first "resolved" them into commits.
Now if we suppose you have the "master" branch checked out, running the
command
$ git merge master feature
is the same as an attempt to merge the tip commit of the branch you're
on ("master") and the tip commit of "feature".
An attempt to merge in the commit you're already at is a no-op:
$ git merge HEAD
Already up-to-date.
(and I'm not sure it's possible even with the "--no-ff" command-line
option — as this would allow creating a weird merge commit with two
or more identical parents; did not check though).
So IMO the command
$ git merge master feature
run while being on the tip commit on "master" is the same as running
$ git merge feature
alone, and that's what you're observing.
Let me stress again, that `git merge` works on commits, not branches.
So if you'll go into a "detached HEAD" state by checking some past
commit reachable from the tip of "master", the
$ git merge master
*will* work.
Anothe point to make is that doing a merge w/o checking out the
"receiving" branch is (mostly) useless: "normal" merging — that is,
merging of a branch which does not fully contain the branch info which
you're merging it — may naturally result in conflicts, and these needs
to be somehow dealt with, and Git deals with them by both setting up
in a special way the index entries for the files with conflicts and
updating their contents in the work tree.
When you know your merge would result in a so-called "fast-forward"
(the case where the branch being merged in fully contains the branch
which is to be updated by the merge) you don't need the merge at all;
instead just update it by either running
$ git push . source_branch:dest_branch
or
$ git branch -B dest_branch source_branch
(the former is preferred as it has an extra safery check in place).
--
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/d/optout.
