Hi Raphael,
On Tuesday 06 September 2011, Raphael Manfredi wrote:
> This is going to create lots of entries because I do "git push" and
> "git pull" a lot between my sandboxes or with github. I don't need
> any commit message unless something was actually done.
>
> Is there a way to retro-actively suppress this noise? And to ask git
> to only create a commit when something was actually done (e.g. a
> merge with conflicts).
The short answer: You can tell "git log" to suppress the output of these
commits with the --no-merges switch.
The long answer is quite involved and amounts to something between "No"
and "Git will create less noise if you behave better". ;-)
First be aware that "pull" is only a short-hand for "fetch" followed by
"merge", so everytime you pull, you tell Git to merge (the same is _not_
true for push). If you don't want to merge, but only copy a different
branch's state, take a look at "reset" instead of "merge".
Git keeps track of (possibly non-linear) coding history in the form of a
directed acyclic graph (DAG). That's not optional; it is absolutely
integral to Git and is the basis for what Git is really good at: merging
diverged branches. Every commit is a node in this graph. Every commit
has 0...n parent commits. A commit with more than one parent is called a
merge commit.
Please take a look at gtk-gnutella's graph with a graphical history
browser such as gitk (which is part of Git's main distribution). You
will notice what an (unnecessarily) complex graph you created in the
first half of 2011-09-06, and that's what caused the noise.
Git will (by default) create a distinct merge commit only if your merge
request results in a "real merge". But Git's notion of a "real merge" is
different from yours, because you talk about commit _messages_, whereas
Git must care about the commit _graph_. You define a "real merge" in
terms of conflicts. To Git, every merge that cannot be done as a so-
called "fast-forward merge" is necessarily a "real merge".
Fast-forward merges are a strategy to avoid "merge ping-pong", which is
similar to what you played. Imagine two branches repeatedly pulling each
other. Even without any code changes, you would get an infinite number of
merge commits with two parents in each branch. To avoid this, Git will
detect if the merged branch's history contains the tip of your current
branch. If yes, Git will simply reset the current branch to match the
other instead of creating a merge commit. That way, all code changes are
guaranteed to be incorporated, and the graph demarks this guarantee even
without an extra commit.
Side note: You need a fast-forward situation when you push, because push
can only reset, never merge. (Using the -f switch on push will cause a
reset even when it is not equivalent to a fast-foward merge, but do that
only if you know the implications for the other developers.)
Now take a look at your very last merge on 2011-09-06 (commit
f525a6442). It is completely unnecessary, because it didn't incorporate
any new code change at all; all non-merge commits were already in its
first parent's history, and none of the incorporated merges solved any
conflicts. It was a pure "graph operation". Git knew this (so it left all
code files untouched), but it couldn't make a fast-forward merge because
of the two noise commits in the (unnecessarily) merged branch. It needed
to create a distinct merge commit to let the graph demark the
_guarantee_ that all changes are incorporated. This guarantee is what
you ask for by calling "git merge". (For example, "git branch -d" will
let you delete only branches that carry this machine-readable promise.)
As a human, you shouldn't need such a machine-readable promise, and,
more importantly, as the original coder, you shouldn't need such a
promise at all (machine-readable or otherwise). You shouldn't have
merged that branch at all, but simply deleted it (or reset to match
another branch). In that case, you would now have three noise commits
less in your history.
Apart from the three pure noise merges coming with commit f525a6442, I
think there are more merges that could have been saved. You seem to
merge another branch after every single commit, which, I suspect, is not
technically necessary (you may rightfully argue with that, of course).
This didn't result in invisible fast-forward commits, because your then-
current branch had two own commits ("Removed RCSID() ..." and "Use
variable ...", respectively) waiting to be published, although these
commits (you may correct me) are orthogonal to the ones from the merged
branches. Such a strategy causes unnecessary merge noise.
Conclusion: You should keep your different feature branches more
separate. When you are working on feature A, you should merge branch B
(which may be master or another feature branch) into A only when B's
latest changes really influence what you do in A. As long as they are
independent, leave them separate. When A is done, merge it into master,
which you can then push.
Also, name your branches after the respective feature. That way, the
merge commits tell you, _which_ feature was actually merged in. They
will then say, for example, "Merge branch 'dove' ..." etc., which frees
them of their image of being just noise.
Bye,
Hauke
------------------------------------------------------------------------------
Using storage to extend the benefits of virtualization and iSCSI
Virtualization increases hardware utilization and delivers a new level of
agility. Learn what those decisions are and how to modernize your storage
and backup environments for virtualization.
http://www.accelacomm.com/jaw/sfnl/114/51434361/
_______________________________________________
gtk-gnutella-devel mailing list
gtk-gnutella-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gtk-gnutella-devel
