Re: [Gnu-arch-users] Inconsistency of Added-files and Removed-files

[Tom Lord]

    > From: Aaron Bentley <address@hidden>

    > On a related note, I'd like to understand why the new-patches header for 
    > a tag revision is a complete listing of all logs in the tree, while the 
    > new-patches header for a commit reflects all logs that aren't accounted 
    > for in the tree.

So that the patch-log contents of a revision can be computed from log
files without having to cross version boundaries (especially without
having to cross archive boundaries).

    > I've got commit --base emitting a tag-style new-patches, on the theory 
    > that "commit --out-of-date-ok --base foo bar --" should produce 
    > equivalent output to "tla tag".  That leads to some ambiguity, though, 
    > because a commit --base may actually contain new patchlogs (e.g. from 
    > replay).  There's no way I can see to distinguish between a new patchlog 
    > and an old one, based on the headers alone.

Interesting.

For consistency, please keep it as you've done it, for now.

The behavior of tag is annoying because it results in large patch log
entries.   `commit --base' will just make that worse.

This is something to put on the list for reving archive formats.
Perhaps:

1) we can factor out the log header created by tag into a separate
   file

2) replace the new/removed log headers with versions that reflect just
   the changeset, if any


-t