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

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?

Thanks Marco

P.S: $ git version git version 1.4.4.1.g7002 $ stg --version Stacked GIT 0.11 git version 1.4.4.1.g7002 Python version 2.4.3 (#2, Oct 6 2006, 15:32:41)

"Marco Costalba" <mcostalba@gmail.com> writes:

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.

Ok.

Anyway, getting garbage when asking for a git-rev-list --all if in a StGit repo at least could be considered a little integration issue.

Internal bookkeeing should be, well,  _internal_  :-)

On 11/27/06, Marco Costalba <mcostalba@gmail.com> wrote:

"Marco Costalba" <mcostalba@gmail.com> writes:

I doubt it. Next thing people would start talking about is what to do with the remote tracking branches, and what we are talking about is rev-list, one of the lower level of plumbing that would be better left without knowing much about the Porcelain's use of refs/ namespaces.

If you (as a Porcelain) want to get all refs under refs/heads/, there are (unfortunately) two ways to get that list. I would suggest obtain the refs you want that way, pass them as command line arguments to rev-list.

$ git for-each-ref --format='%(refname)' refs/heads $ git show-ref --heads | sed -e 's/^[^ ]* //'

Add the --refs=<pattern> option, which can be used to select a subset of refs matching the specified glob pattern.

Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---

 If --all-branches is too specific for the mentioned use case,
 what about adding a more general glob pattern match?

 Documentation/git-rev-list.txt |    9 +++++++++
 revision.c                     |   21 ++++++++++++++++++---
 2 files changed, 27 insertions(+), 3 deletions(-)

Sergey Vlasov <vsu@altlinux.ru> writes:

Traditionally any new option to rev-list must be accompanied with a matching change to rev-parse. I do not know offhand how strictly we should adhere to this rule these days; it depends on how people's script use rev-list.

Before revision.c "revision walking library" was done, many Porcelain-ish commands were implemented as a pipeline that plugs rev-list output to diff-tree. These shell scripts took parameters from the command line, and rev-parse was used to separate parameters (both "flags" that begin with a dash and "non-flags" that don't) that should be given to rev-list and the other parameters (meant to be used by the shell script itself but often are given straight to the downstream diff-tree). The rev-parse command has even the --sq option to facilitate this usage:

	rev_opts=`git rev-parse --sq --default=HEAD --revs "$@"`
	diff_opts=`git rev-parse --sq --no-revs "$@"`
        eval "git-rev-list $rev_opts" |
        eval "git-diff-tree --stdin $diff_opts"

so that it can even pass -S'I want to find this string' to diff-tree without worrying about spaces.

I personally feel that part of rev-parse outlived its usefulness (--flags, --no-flags, --revs-only, and --no-revs). It was a useful hack, and served us well, but it was a hack.

In that sense it probably is Ok to leave it unmaintained, but it might be a good idea to plan deprecating it, given that we have been talking about UI warts. If there are pipelines that can be easily formed (with the help of rev-parse "parameter sifter"), but whose functionality cannot be easily emulated with the current crop of Porcelain-ish, we should work on polishing the Porcelain-ish to make the pipelines unnecessary.

The remaining parts of rev-parse (the most important of which is the --verify option) should probably stay. The original question of "list all the branches" can be done with:

	git rev-parse --symbolic --branches

On 11/27/06, Junio C Hamano <junkio@cox.net> wrote:

Unfortunatly that does not work in case a branch and a tag have the same name.

I was bitten by this trying to do what you now suggest, there were a tag and a branch called 'test', and calling

git-rev-list master origin test

raised a warning.

Only among the _same_ 'family' (branches, tags, etc..) unique names are enforced.

"Marco Costalba" <mcostalba@gmail.com> writes:

I am not quite grokking what the problem you are trying to solve is, so this is a shot in the dark, but

	git rev-list refs/heads/test refs/tags/test

to disambiguate, perhaps?

On 11/28/06, Junio C Hamano <junkio@cox.net> wrote:

Interesting!

I didn't think about 'full path' explicitation. If the barnches are always and only under refs/heads this should work.

Thanks