pull/merge --no-commit

pull/merge --no-commit

[kurt_p_lloyd]

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

Re: pull/merge --no-commit

[kurt_p_lloyd]

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

kurt_p_lloyd wrote:
> 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

Re: pull/merge --no-commit

[Junio C Hamano]

kurt_p_lloyd <kplloyd@alcatel-lucent.com> 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.

Re: pull/merge --no-commit

[kurt_p_lloyd]

comments intermixed below

Junio C Hamano wrote:
 > kurt_p_lloyd <kplloyd@alcatel-lucent.com> 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.

Spot on :)

 > 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.

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.

 > 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".

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

 > 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.

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

Re: pull/merge --no-commit

[Junio C Hamano]

kurt_p_lloyd <kplloyd@alcatel-lucent.com> writes:

> 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.

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

> 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.

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.

Re: pull/merge --no-commit

[Kevin Green]

On 06/07/07 14:31:25, kurt_p_lloyd wrote:
> Junio C Hamano wrote:
> >
> >
> > 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".
> 
> 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.
> 

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

Re: pull/merge --no-commit

[Keith Duthie]

On Thu, 7 Jun 2007, kurt_p_lloyd wrote:

> 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.

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.

Re: pull/merge --no-commit

[kurt_p_lloyd]

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

Keith Duthie wrote:
> On Thu, 7 Jun 2007, kurt_p_lloyd wrote:
> 
>> 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.
> 
> 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).

Re: pull/merge --no-commit

[J. Bruce Fields]

On Thu, Jun 07, 2007 at 04:32:35PM -0400, kurt_p_lloyd wrote:
> 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

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

> 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).)

... 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.

Re: pull/merge --no-commit

[Keith Duthie]

On Thu, 7 Jun 2007, kurt_p_lloyd wrote:

> 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).)

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.