Re: If merging that is really fast forwarding creates new commit

From: Junio C Hamano <junkio@cox.net>
Date: 2006-11-08 05:23:23
Liu Yubao <yubao.liu@gmail.com> writes:

> I want to separate a branch, not to separate commits by some author,
> for example, many authors can contribute to git's master branch, I
> want to
> know what happened in the master branch like this:
>      good work from A;
>      good work from C;
>      merge from next;   -----> I don't care how this feature is realized.
>      good work from A;
>      ....

So you want to see list of commits that happened to be at the
tip of my 'master' branch.  I would not say that view does not
exist, but it is probably not very useful.  And the uselessness
of it depends majorly on the reason why you say "I don't care
how this feature is realized" in the above picture.  Care to
elaborate why not?

side note: I do not merge next to master so "from next" above in
reality would be "from a topic branch" or "from maint", but it
is otherwise a good example.

What appeared in 'master' recently are three kinds of changes:

 - Many fixes that still apply to 1.4.3 codebase were sent from
   the list (thanks, everybody!), which were applied to 'maint',
   and merged into 'master'.

 - Some other obviously correct fixes and changes that address
   issues on features added after the 1.4.3 release (hence
   missing from 1.4.3 codebase and 'maint' but in 'master') were
   applied directly on 'master'.

 - Yet some other fixes and changes that concern post-1.4.3
   codebase (i.e. 'master only' changes) were forked off of the
   tip of 'master' when the patches were received, cooked in
   their own topic branches (which were merged in 'next'), and
   then merged into 'master'.

So, we have two kinds of obviously correct changes to 'master'
that come both from merges and direct applications.  Things that
happen to address older issues come as merges because they
equally apply to 'maint' and merged into 'master', things that
address newer issues are applied directly.  Put it another way,
things that come as merges to 'master' are also of two kinds.
Obviously correct one that came through 'maint', and the ones
that might have looked slightly wrong in the initial version and
later perfected while in its own topic branch and then merged
into 'master'.

The decision between cooking in a topic branch and immediately
applying to 'master' is not based on the size but more on
perceived usefulness of the change (something that is correct in
the sense that it does not break the system may not deserve to
be merged if it does not do useful things) and quality of the
design and implementation.  The size of the series obviously
affect the perception by me but that is secondary.

Even when a patch is something that I should be able to judge as
obviously correct when I am relaxed and sane, I might lack time
and concentration to follow it fully, and instead decide to drop
it into its own topic branch and later merge it into 'master'
without need for much cooking.  That kind of patch _could_ have
(and should have) been applied directly to 'master' but comes as
a merge.

Sometimes I apply a patch to 'master' and then later realize
that change is needed and applicable to 'maint' as well.  That
is cherry-picked to 'maint', resulting in two independent
commits.  They _could_ have (and should have) come through a
merge from 'maint' to 'master'.

So the change a patch introduces itself may not even have
relevance to the difference between direct application and merge
at all.  In other words, the avenue a particular patch took,
difference between direct application and merge, should not
concern you.  I hope this would illustrate why a view that tries
to summarize what merges brought in and to give full description
of what were applied directly does not make much sense.

By the way, there are two reasons why you cannot have my
ref-logs.  First of all, I do not have one on 'master' nor
'next' myself.  More importantly, I rewind and rebuild these
branches before pushing out (of course I have some safety valve
to prevent me from rewinding beyond what I have already pushed
out), and the ref-log entries for those tips that were rewound
are not useful to you, and something I would rather not have
people to even know about (think of it as giving me some
privacy).

If you really care about the branch tip history of my
repository, you can set up ref-log yourself on your remote
tracking branch.

Strictly speaking, that is the history of fetches by you, not
the history of merges and commits by me, but that is what
matters more to you.  If I pushed my changes out twice a day but
you were away for two days, you would have seen the state of my
repository four rounds back before you left and when you fetched
from me today you would have the latest; three states in between
were not something you can know.  But it does not matter -- your
repository did not have those three states, so not knowing
exactly which commit they were would not hurt you when
bisecting.  "It worked before I pulled yesterday morning but now
it is broken when I pulled this afternoon" would help your
bisect get started, but multiple state changes between the times
you fetched cannot matter.

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Received on Wed Nov 08 05:23:36 2006

This archive was generated by hypermail 2.1.8 : 2006-11-08 05:24:34 EST