Re: [PATCH] filter-branch: resolve $commit^{tree} in no-index case

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

 



Jeff King <peff@xxxxxxxx> writes:

> Actually, I ended up not including the part about doing that comparison.
> So the commit message isn't _wrong_, but it is incomplete. This
> paragraph:
>
>   However, the value of $tree here is technically
>   user-visible. The user can provide arbitrary shell code at
>   this stage, which could itself have a similar assumption to
>   what is in git_commit_non_empty_tree. So the conservative
>   choice to fix this regression is to take the 20% hit and
>   give the pre-348d4f2 behavior.
>
> should start with something like:
>
>   We could try to make git_commit_non_empty_tree more clever.
>
> to make it clear why we care about the user-visibility of the variable
> in the first place.
>
> Here is a re-roll with that fixup.

Thanks.  I failed to spot and realize that $tree is also part of
what we expose and end-user scripts may already be looking at when I
commented, and I agree with the reasoning behind this conservative
route.

Will queue.
--
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]