The --no-commit blues

The --no-commit blues

[Brian L. Troutwine]

I've got two branches, one which I commit to quite frequently and another only 
periodically, call them inward and outward. Inward is where I do my work, 
outward tracks an SVN repository. I'd like to merge inward to outward without 
committing the merge so that I may provide a commit message appropriate for 
checking in to the SVN repo. 

`git merge --no-commit inward' from branch outward, I thought, should do it. 
Performing a `git status' and a `git log' directly afterward seem to indicate 
that the merge was committed. `git commit' insists the branch is now up to 
date.

Am I going about this the wrong way? What does --no-commit mean, if I am?

(Also, I asked this on #git earlier. If anyone happens to idle there, pardon 
me for re-posting this so quickly. I've got terrible lag this morning, enough 
to time out frequently.)

Re: The --no-commit blues

[Alex Riesen]

On 6/18/07, Brian L. Troutwine <goofyheadedpunk@gmail.com> wrote:
> I've got two branches, one which I commit to quite frequently and another only
> periodically, call them inward and outward. Inward is where I do my work,
> outward tracks an SVN repository. I'd like to merge inward to outward without
> committing the merge so that I may provide a commit message appropriate for
> checking in to the SVN repo.
>
> `git merge --no-commit inward' from branch outward, I thought, should do it.
> Performing a `git status' and a `git log' directly afterward seem to indicate
> that the merge was committed. `git commit' insists the branch is now up to
> date.

Either it was a fast-forward (IOW, the outward had no changes since you
changed inward, and inward is derived from outward), or we have a bug
(which I cannot reproduce).

> Am I going about this the wrong way? What does --no-commit mean, if I am?

exactly what it say: do not commit. Fast-forwards do not commit, just update
your HEAD, index and working directory with the new changed (from inward
in your case).

Re: The --no-commit blues

[Sergio]

Brian L. Troutwine <goofyheadedpunk <at> gmail.com> writes:

> 
> I've got two branches, one which I commit to quite frequently and another only 
> periodically, call them inward and outward. Inward is where I do my work, 
> outward tracks an SVN repository. I'd like to merge inward to outward without 
> committing the merge so that I may provide a commit message appropriate for 
> checking in to the SVN repo. 
> 
> `git merge --no-commit inward' from branch outward, I thought, should do it. 
> Performing a `git status' and a `git log' directly afterward seem to indicate 
> that the merge was committed. `git commit' insists the branch is now up to 
> date.
> 

If you want the "whole" set of changes from inward to appear in outward as a
/single/ commit with an appropriate commit message, probably you want to use
also the --squash option of git merge.

Otherwise, git will preserve the "structuring" of the history in many commits.
This means that:

- if outward does not need any real merge (because it only needs to be advanced
to a newer status and not to join some changes of its own with changes from
inward), git merge will make a "fast-forward". In other words, you will see
outward becoming up to date without the need of any merge-commit at all. BTW
that is why --no-commit appears to have no effect in this case: there wouldn't
be any merge commit in any case. 

- if outward needs a real merge, then git merge will set up everything up to the
point of making the merge commit.  Then, depending on the presence of the
--no-commit option it will or will not make the actual commit.  

> Am I going about this the wrong way? What does --no-commit mean, if I am?
> 
> (Also, I asked this on #git earlier. If anyone happens to idle there, pardon 
> me for re-posting this so quickly. I've got terrible lag this morning, enough 
> to time out frequently.)