Re: Possible BUG with git-rev-list --all in a StGit repository

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

 



"Marco Costalba" <mcostalba@xxxxxxxxx> writes:

> In a StGit repository the --all option causes a lot of spurious
> revisions, possibly stgit related.
>
> $ git branch
> * master
>  origin
>  test
>
> $ git rev-list master origin test -- src/settingsimpl.cpp | wc
>     13      13     533
>
> $ git rev-list --all -- src/settingsimpl.cpp | wc
>     26      26    1066
>
>
> The extra revisions have shortlogs of the kind of:
>
> push        a3bc76fd0bdd154149c26a3c208f0344e9cd873b
> new e7baf56544cd8b4f8601a35fad274b8de97fd558
> refresh     8fa01a56a40b04ed9c6d006c669ca9d370176728
>
>>From qgit these are easily seen from file history tab of a file
> modified by stgit patches or when filtering in main view on the same
> file.
>
> Shouldn't 'git-rev-list --all'  print  *the same output* of when the
> list  with all branches is given in command line?

Should it?  The "--all" option is about "all refs", not "all
user branches" and it has been so from the beginning.  For one
thing it has to do the reachability thing also for tags
(otherwise it cannot be used as the upstream for git-repack
pipeline).

You are looking at .git/refs/bases/ refs that StGIT uses for its
internal bookkeeping.


-
To unsubscribe from this list: 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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]