git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Daniel Barkalow <barkalow@iabervon.org>,
	Petr Baudis <pasky@ucw.cz>,
	git@vger.kernel.org
Subject: Re: [RFC] General object parsing
Date: Mon, 18 Apr 2005 14:45:36 +1000	[thread overview]
Message-ID: <1113799537.11910.76.camel@localhost.localdomain> (raw)
In-Reply-To: <Pine.LNX.4.58.0504171807590.7211@ppc970.osdl.org>

On Sun, 2005-04-17 at 18:15 -0700, Linus Torvalds wrote:
> In particular, is there some easy way to walk backwards by time? "git log"  
> definitely needs that, and merge-base clearly wants something similar. 

Actually the ideal output of 'git log' isn't strictly chronological.
IIRC my bkexport scripts used to make a chronologically sorted list, and
I ended up changing it.

Simple example: if there are changesets which have been lurking in some
tree for months waiting for you to pull, and the only thing you did
since I ran 'git log' on your tree yesterday is pull from that tree,
then those changesets are what I want to see at the top of 'git log'
output.

In fact this probably means that the depth-first tree walking of the
original gitlog.sh is probably the right thing to do, but when we hit a
merge we want to try to make sure we process the _remote_ parent first.

Are we sorting the 'parent' links in merges so that two merges of the
same branches are guaranteed to be identical (assuming identical
contents otherwise)? Or is it just that we didn't think about it, and so
merges are putting the local and remote parents in the 'wrong' order by
coincidence?

-- 
dwmw2


      parent reply	other threads:[~2005-04-18  4:42 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-18  0:25 [RFC] General object parsing Daniel Barkalow
2005-04-18  1:15 ` Linus Torvalds
2005-04-18  2:15   ` Daniel Barkalow
2005-04-18  2:33     ` [0/5] Parsers for git objects, porting some programs Daniel Barkalow
2005-04-18  2:35       ` [1/5] Header files for object parsing Daniel Barkalow
2005-04-18  2:36       ` [2/5] Implementations of parsing functions Daniel Barkalow
2005-04-18  2:37       ` [3/5] Port rev-tree to " Daniel Barkalow
2005-04-18  2:40       ` [4/5] Port fsck-cache to use " Daniel Barkalow
2005-04-18  2:42       ` [5/5] Switch implementations of merge-base, port to parsing Daniel Barkalow
2005-04-18 18:34       ` [0/5] Parsers for git objects, porting some programs Linus Torvalds
2005-04-18 20:12         ` Daniel Barkalow
2005-04-19  1:15           ` Junio C Hamano
2005-04-19  1:23             ` Daniel Barkalow
2005-04-19  2:04             ` Daniel Barkalow
2005-04-18  3:51     ` [RFC] General object parsing Daniel Barkalow
2005-04-18  4:45   ` David Woodhouse [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=1113799537.11910.76.camel@localhost.localdomain \
    --to=dwmw2@infradead.org \
    --cc=barkalow@iabervon.org \
    --cc=git@vger.kernel.org \
    --cc=pasky@ucw.cz \
    --cc=torvalds@osdl.org \
    /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).