Re: [Bug] In `git-rev-list(1)`, using the `--objects` flag doesn't work well with the `--not` flag, as non-commit objects are not excluded

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

 



On Wed, Aug 16, 2023 at 8:24 PM Junio C Hamano <gitster@xxxxxxxxx> wrote:
>
> Karthik Nayak <karthik.188@xxxxxxxxx> writes:
>
> > The provided reproduction recipe unfortunately uses a linear
> > history and therefore, is not the same as the example provided by
> > me. Here is a reproducible recipe following the same commands you
> > used:
> > $ rm -fr new ; git init new ; cd new
> > $ echo foo >foo
> > $ git add -A; git commit -m one; git rev-parse HEAD
> > 26fb965d7439c1760677377bf314d8933de0b716
> > $ mkdir bar; echo goo >bar/goo
> > $ git add -A; git commit -m two; git rev-parse HEAD
> > $ git checkout -B branch
> > $ git reset --hard @~1
> > HEAD is now at 26fb965 one
> > $ git add -A; git commit -m three; git rev-parse HEAD
> > 91ef508167eb683486c3df6f8d07622b61ed698d
> >
> > $ git rev-list --objects HEAD ^master
> > 91ef508167eb683486c3df6f8d07622b61ed698d
> > ff05824d2f76436c61d2c971e11a27514aba6948
> > 8baef1b4abc478178b004d62031cf7fe6db6f903 abc
> > 086885f71429e3599c8c903b0e9ed491f6522879 bar
> > 7a67abed5f99fdd3ee203dd137b9818d88b1bafd bar/goo
>
> Thanks, but the above is not recreating the same as your original
> (where did "moo" go???).  Also "git rev-parse HEAD" for the sanity
> checking should be spelled "git rev-parse HEAD:" if you want to help
> others looking into the issue---anybody trying to reproduce will NOT
> have the same commit object name, but the point of these checks is
> to show the tree object name, which should reproduce for them.
>

It's not re-creating the exact structure I had in my original post, but it is
a shorter version which demonstrates the issue at hand.

I don't see the importance of "moo" here, the original repository structure
was something I was playing around with and found the issue.

Sorry about the misspelling, was just trying to provide a more deterministic
method of re-creating the issue. And I think that it still holds true.
In the newer
example you can see that although "branch" and "master" are TREESAME
with regards to the "bar" path, the tree for "bar" and its children
are still output
from git-rev-list(1). Even though we specify "^master".So ideally only objects
reachable from "branch" and not reachable from "master" should have been
output.




[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]

  Powered by Linux