pull/merge --no-commit

Hello,
I'm new to git, thought I'd take it for a spin.
Found what seems to me to be a problem,
hoping someone can shed light on it.

I /really/ want --no-commit to work, bit it doesn't seem to:

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? BTW, merge --no-commit gives me the same problem. It merges fine but does the commit.

I put a 'set -x' in the git-merge shell script (which gets called by pull) from one of my 'pull' runs, I have the output if anyone wants it.

-Kurt

PS - Sorry, I should have mentioned the git version: 1.5.2.1

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.

comments intermixed below

Spot on :)

Ah, the difference in terminology biting me here .... I'm used to ClearCase, where the term "merge" includes so-called "trivial merges", where a change is merely copied from one branch to another, with no parallel changes on the receiving branch.

Except here's the model that I am trying to follow....
It seems that 'pull' can be partitioned into 3 separate responsibilities:

1. Retrieve changes from the remote user's replica (without modifying any /local/ branches).
2. Bring changes from "remote" into a local branch (without commit).
3. Commit.

My thoughts are that if I could have these be 3 different, sequential steps, after step 1 I could peruse the "database" to see what "remote" changed, and whether or not I may like such changes, and would want to /consider/ "taking" them. If no then I do nothing. If yes then I do step 2.
After step 2 I may find that I don't really like those changes after all. I only commit if I really do like those changes.

I don't want to overdo it here on the ClearCase stuff, but this scenario is one which is very natural in that system:

1. multisite syncreplica
2. cleartool merge # even for "trivial merges"
3. cleartool checkin (or cleartool uncheckout if I don't like the changes)

more way below

I must compliment you on your excellent communication. Maybe there is a different workflow to effectively achieve what I want via steps 1, 2, and 3 (way above). In other words, OK I do a 'pull', and all 3 steps occur together. Then suppose that I contemplate the changes that got committed, and that I disapprove of either a majority or all of those changes. I'd like to be able to cleanly and easily recover from this with no related commits and "revert commits" in git log. I'll add my own deliberate commits if and when I decide that I really /would/ like some or all of those changes eventually, in which case I would still like the proper context to exist in the "database" for me to bring the selective remote changes into my local branch in a natural way. Are there git commands to best cover this scenario?

Kind regards,
-Kurt

I'm new to git and trying to pick it up and learn this week!! :)

I think what you want is:

$ git fetch
$ git merge origin/master

You want to fetch the remote changes into a separate branch and then probably check the log to see what's changed... Once you're happy, merge the branches. Git will still fast-forward because you haven't made any local changes.

--Kevin

Let's say you did this:

 $ git pull $other_party

A "pull" is a "fetch" (download their history and objects) followed by a "merge" (integrate that history with your history). When it goes without merge conflicts you need to resolve by hand, the above will move your HEAD to reflect the new histroy of your project, including the fact that you merged with the $other_party, at this point. The above command gives you the overview of the change in the form of diffstat.

You would naturally want to inspect and convince yourself that you did not pull crap from the $other_party. A special symbol ORIG_HEAD is set up after a "merge" (be it a "fast forward" or a true merge) that lets you easily access where the tip of your branch was before the merge.

To view the damage the $other_party inflicted on you as a whole:

 $ git diff ORIG_HEAD..

Or to inspect individual patches:

 $ git log -p ORIG_HEAD..

Some people seem to prefer "git log --reverse -p ORIG_HEAD..", which would give their changes in chronological order.

If it turns out that you pulled crap from the $other_party, you can get rid of that away from the history of your branch with:

 $ git reset --hard ORIG_HEAD

In git managed projects that care about the readability of global history, this often is done by asking $other_party to redo the branch, discarding broken/undesirable bits.

But if you do not have the clout to do so over the $other_party, then you could, after the above sequence, cherry pick good bits from what the $other_party has and you don't. This however will make your history and their history to have different commits that record the result of the same patch application; if you later pull from the $other_party again, you will end up having two copies of the (logically) same commit in your history.

I believe you can accomplish step one with a remote tracking branch ("git-remote add localname git://whereever/project.git" to add the branch to the repository, then "git-remote update localname" to update it to the current remote state).

The universe hates you, but don't worry - it's nothing personal.

Many thanks to Junio, Kevin, and Keith for the helpful comments. I'll give some play time to all of these suggestions :)

One thing I was thinking might be useful would be a command to make (just) my repository unavailable for 'fetch' or 'pull' from others, temporarily. And then a command to make it available again, after I finish things that could end up needing "database" surgery, like maybe something that could result in having to do a git reset. I was thinking maybe something like:

  $ git config maintenance true
  .... do something that may end up needing "database" surgery
  $ git config maintenance false

Just an idea. Of course, if something like this already exists .... (I'd rather not shut down sshd, nor have to create a separate "public"
repository (for certain types of "projects" anyway).)

-Kurt

You could probably do that with file permissions, but...

... why not? Having a separate public repository also allows you to do this and much more. And it should be cheap and easy--if you're worried about the space, clone with --shared or something.

--b.

Actually, a separate public repository is probably exactly what you want here. If you clone the repository with the local and shared flags you'll only need to have one copy of the objects on disk (if I understand things correctly), and you can just push your development branch to the public repository whenever you're happy with the state of your code.

And if you're going to give other people access to your development repository then you're probably best off having a branch (or branches) that are there specifically for other people to pull from, and make sure you don't merge anything into those branches without it being ready for release. And then tell people it's their own fault if they grab one of your work-in-progress branches instead ;-)

The universe hates you, but don't worry - it's nothing personal.