From: Michael Haggerty <mhagger@alum.mit.edu>
To: Thomas Rast <trast@student.ethz.ch>
Cc: Junio C Hamano <gitster@pobox.com>,
Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>,
git@vger.kernel.org
Subject: Re: [PATCH v2] rev-list docs: clarify --topo-order description
Date: Thu, 16 Aug 2012 12:01:11 +0200 [thread overview]
Message-ID: <502CC4E7.5060508@alum.mit.edu> (raw)
In-Reply-To: <87pq6rw77l.fsf@thomas.inf.ethz.ch>
On 08/16/2012 10:51 AM, Thomas Rast wrote:
> [...]
> is misleading. I suppose the real problem is that the "true" ordering
> is completely obvious as the one ordering that does not require
> preprocessing, but ugly to specify in words. Perhaps we can bikeshed a
> little? How about
>
> By default, commits are shown in an order that coincides with
> `--date-order` on well-behaved history, but is faster to compute.
Maybe the problem is not the description of the options, but the options
themselves. Why does the behavior default to some mysterious order that
we don't even want to document? Only for the sake of computational
efficiency. This is the tail wagging the dog.
Why not turn the behavior on its head:
* Change the default behavior to be something well-defined, easy to
document, and convenient for humans, such as "topological order with
ties broken by timestamp" or "approximate timestamp order, but
respecting dependencies".
* Add a new option, --arbitrary-order, that explicitly chooses
efficiency instead of a defined order.
That way the easiest thing to type is also the most convenient, whereas
when you care about efficiency and *don't* care about order (i.e.,
mainly in scripts) you can explicitly request the high-performance option.
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
next prev parent reply other threads:[~2012-08-16 10:08 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-13 22:21 [PATCH] rev-list docs: clarify --topo-order description Junio C Hamano
2012-08-13 22:46 ` Martin von Zweigbergk
2012-08-13 23:05 ` Junio C Hamano
2012-08-14 5:33 ` Martin von Zweigbergk
2012-08-14 14:54 ` Junio C Hamano
2012-08-14 8:22 ` Michael Haggerty
2012-08-14 8:45 ` Thomas Rast
2012-08-14 14:30 ` Junio C Hamano
2012-08-14 14:51 ` Thomas Rast
2012-08-14 15:47 ` Junio C Hamano
2012-08-15 20:02 ` [PATCH v2] " Junio C Hamano
2012-08-16 6:06 ` Martin von Zweigbergk
2012-08-16 6:20 ` Junio C Hamano
2012-08-16 6:26 ` Junio C Hamano
2012-08-16 8:51 ` Thomas Rast
2012-08-16 10:01 ` Michael Haggerty [this message]
2012-08-16 12:00 ` Thomas Rast
2012-08-16 16:10 ` Junio C Hamano
2012-08-17 9:34 ` Thomas Rast
2012-08-17 9:50 ` Thomas Rast
2012-08-17 17:18 ` Junio C Hamano
2012-08-17 17:37 ` Thomas Rast
2012-08-17 18:11 ` Junio C Hamano
2012-08-17 17:40 ` Junio C Hamano
2012-08-16 16:35 ` Michael Haggerty
2012-08-16 8:42 ` Thomas Rast
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=502CC4E7.5060508@alum.mit.edu \
--to=mhagger@alum.mit.edu \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=martin.von.zweigbergk@gmail.com \
--cc=trast@student.ethz.ch \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).