Marco Costalba <mcostalba@xxxxxxxxx> writes:
>> ... I wonder why you care. Wouldn't this work just as well?
>>
>> $ git rev-list --header --topo-order --parents --remove-empty \
>> --all -- <path>
>>
>
> Yessss!!!
I think I spoke too early. I think --remove-empty does not
prevent rev-list from traversing branches that <path> _never_
appears in their history, so if the <path> given was TODO, it
will go all the way back to the very first commit by Linus, and
the very first commit for gitk by Paul, without finding a commit
that touches that file.
One option is "--remove-empty --all" with <path> to omit heads
and tags that do _not_ have given <path>s from the set of
starting points, but then you cannot grab history of rev-tree.c
between v0.99.7 and 9dcc829 (v0.99.7 was the last tagged commit
that had rev-tree.c, but removal of the file happened 39 commits
after that), so that is not really an option.
I guess we need to live with this; git.git repository is quite
special. If you clone from it, you would get todo, html and man
branches, so it *appears* that these are part of the same
repository, but logically these branches are not part of the
project history proper.
The commits that belong to these three branches do not appear in
my private development repository. The todo branch is pushed
into git.git from a completely separate repository from my side,
and html and man branches are pushed from other separate
repositories of their own on a kernel.org machine, automatically
built after I push new stuff into the "master" branch of git.git
repository, by the post-update hook.
The only reason I have these three branches in git.git
repository is historical. I do not have write access on
kernel.org machine in /pub/scm/git itself. I can only write in
/pub/scm/git/git.git/, and I never bothered to ask the operators
to make /pub/scm/git itself writable by me; otherwise I would
have made /pub/scm/git/git-{todo,html,man}.git repositories.
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html