kurt_p_lloyd <kplloyd@xxxxxxxxxxxxxxxxxx> writes:
> I run: git pull --no-commit ssh://<blah blah blah>
>
> then I run: git status
>
> it says: nothing to commit (working directory clean)
>
> then I run: git log
>
> it shows the commit message from the other user below a
> commit sha1, and the change I pulled was indeed merged to
> my file.
>
> Does this seem to be a bug, or am I doing something wrong?
No bug, no user error.
I suspect you did not have _ANY_ of your own development. If
that is the case, then it worked as you told it to. You asked
no merge commit to be made, and it did not create a new merge
commit.
Illustration. Earlier you had (probably your git-clone created
this) this history:
---A---B---C---D
^ HEAD
and your tip of the branch (and HEAD) was at commit D. You did
not do any of your own development yourself, and then you
pulled.
In the meantime, the other repository had been busily working
and has a few more commits:
---A---B---C---D---E---F---G---H
^ ^
Your HEAD The tip of the branch you
was here. pulled is here.
In this case, because you do not have anything new to add to the
history (remember, git history is a global DAG -- you and the
other repository are building it by pushing and pulling), we
move your HEAD to H (the tip of the branch you are pulling).
There is no need to create a new merge commit, with or without
the --no-commit option. This is called "fast forward".
In a more interesting case, you will see a different behaviour.
Let's suppose you started from the same state (i.e. cloned up to
D), and built your own changes on top of it:
Your HEAD
v
X---Y---Z
/
---A---B---C---D
while the other repository had the same E...H development line.
You pull from them. Remember, pull is a fetch followed by a
merge. After the fetch, you get this:
Your HEAD
v
X---Y---Z
/
---A---B---C---D---E---F---G---H
^
The tip of the branch you
pulled is here.
This is not a "fast forward" situation and "git pull" would need
a new merge commit, like this:
Your HEAD used to be here
v
X---Y---Z-------M <- A new merge commit
/ / becomes HEAD
---A---B---C---D---E---F---G---H
^
The tip of the branch you
pulled is here.
What --no-commit does is to prepare a tree to be used to create
the merge commit "M", without actually creating a commit. So if
you did "git pull --no-commit", your HEAD would stay at Z and
your index and working tree is prepared to create the tree
suitable to be committed as "M". After that, you have a chance
to make further changes to your working tree before creating a
commit with "git commit", to affect what is recorded in the
resulting merge commit "M".
In the case of "fast forward", --no-commit still moves the HEAD,
and this is deliberate. Imagine if we did not move the head.
Because the merge is "fast forward" in reality, what is left in
the index and the working tree to be committed should exactly
match what is in H. You may futz with the working tree further
before actually creating the commit, and the next "git commit"
would give you this graph:
.---------------M
/ /
---A---B---C---D---E---F---G---H
^ ^
Your HEAD The tip of the branch you
is still here. pulled is here.
The difference between H and M is strictly what you did to the
index and the working tree between "pull --no-commit" and
"commit".
That is insane. Why? Because what you really did was to start
from the tree of H, did your own development (i.e. "diff H M"),
and made a commit. This is the reason why --no-commit does not
do anything special when the pull is a fast forward.
The resulting history should not be the above merge, but just
like this:
---A---B---C---D---E---F---G---H---M
You did a "fast forward", and did your own development to make a
single commit, which is what this history should look like.
There was no merge performed. Just a straight line of
development on top of what you got from the other side.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
