[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] from a file's point of view

From: Miles Bader
Subject: Re: [Gnu-arch-users] from a file's point of view
Date: Mon, 22 Sep 2003 19:12:15 -0400
User-agent: Mutt/1.3.28i

On Mon, Sep 22, 2003 at 10:39:23AM -0700, Tom Lord wrote:
> To know what the correct path is at each
> revision, you will have to trace changes to path as you search logs
> backwards.   If a containing directory is renamed, you have to adjust
> the path of the file your looking for (I'm not sure whether or not
> Mile's script does -- haven't looked yet).

No, no, not at all, it just handles the most trivial cases.  It's just a
slightly more bloated version of the `5 liner' script I posted to this list a
while back.

I haven't actually sat down and thought about it a lot, but the feeling I got
was things only started getting really messy if you wanted accurate
accounting for multiple interacting branches; if you mainly care about a
single branch, then you have a nice linear ordering to rely on.

On the other hand, I suspect that for everyday use, this is actually what's
wanted anyway.  `Histories' of trees are often pretty unreadable, and
focusing on a single line-of-development (whoa I used that term!) with
`changes to this file were merged from this branch...' annotations is more
appropriate.  Actually this is one thing that seems annoying to do with the
current patch-log format: you can tell a file was changed in a patch, and you
can tell another branch was merged, but it's hard to tell if whether a
changed file was affected by a merge or not (you'd have to actually search
back through the merged branch -- including merges into it -- until you found
a change to the file, and it's difficult to know when you should stop

I'd rather be consing.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]