From: Junio C Hamano <gitster@pobox.com>
To: Teemu Likonen <tlikonen@iki.fi>
Cc: Adam Simpkins <adam@adamsimpkins.net>, git@vger.kernel.org
Subject: Re: log --graph --first-parent weirdness
Date: Thu, 05 Jun 2008 11:31:10 -0700 [thread overview]
Message-ID: <7vbq2f3f9t.fsf@gitster.siamese.dyndns.org> (raw)
In-Reply-To: <20080605095033.GC5946@mithlond.arda.local> (Teemu Likonen's message of "Thu, 5 Jun 2008 12:50:33 +0300")
Teemu Likonen <tlikonen@iki.fi> writes:
> Well, I disagree :-) Merges are interesting points in history (they
> introduce features etc.) and for a "--graph --first-parent" user
> a certain already known merge is easier to find if there is a stable
> identifier for them.
Step back a bit. Regular commits also introduce features. If you want to
argue for marking a merge as more significant than single parent commits,
you need to justify the reason why a bit better.
When you are looking at a history (be it 'first-parent' or regular), each
transition introduces changes, but especially when you are talking about
first-parent, a merge is merely a squashed commit of everything that
happened on the side branch, which may be trivial one-liner fix or an
addition of full new command. Why a merge of trivial one-liner fix should
be treated as more significant than a more involved change that directly
was done on the master branch?
A full and perfect implementation of a new command may have happened on a
side branch as a single commit. If the master branch was dormant while it
was being done, the final merge of that side branch will result in a
fast-forward, and the introduction of the new command would appear as a
non-merge, regular commit. If on the other hand there were activities on
master since the side branch forked, the introduction of the new command
would appear as a merge. Why do you paint the latter as more significant
than the former?
If somebody argues for making the marking different (perhaps by color-code
the asterisk differently) depending on how much each commit changes the
tree relative to its parents, I would say it might be a great feature.
Such a display would treat the two cases I mentioned above equally.
I however do not think the number of recorded parents deserves such a
special treatment to clutter the output and distract people, especially
when "is it a merge?" can be easily seen by two other means (log message
and graph lines).
prev parent reply other threads:[~2008-06-05 18:32 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-04 15:00 log --graph --first-parent weirdness Teemu Likonen
2008-06-04 15:08 ` Teemu Likonen
2008-06-04 17:12 ` Junio C Hamano
2008-06-04 17:38 ` Teemu Likonen
2008-06-04 18:04 ` Adam Simpkins
2008-06-05 8:56 ` [PATCH] graph API: fix "git log --graph --first-parent" Adam Simpkins
2008-06-04 18:05 ` log --graph --first-parent weirdness Junio C Hamano
2008-06-05 1:37 ` Ping Yin
2008-06-05 9:28 ` Adam Simpkins
2008-06-05 9:50 ` Teemu Likonen
2008-06-05 18:31 ` Junio C Hamano [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=7vbq2f3f9t.fsf@gitster.siamese.dyndns.org \
--to=gitster@pobox.com \
--cc=adam@adamsimpkins.net \
--cc=git@vger.kernel.org \
--cc=tlikonen@iki.fi \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.