-
-
Notifications
You must be signed in to change notification settings - Fork 899
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make separate sub-tree-view vs just-git-tree classes or git.Tree runtime modes #1505
Comments
Thanks a lot for the detailed description of the problem and for making it reproducible, it's much appreciated. My stance since the comment in #851 didn't change and improving the situation is appreciated. In the linked comment I called it a bug which would allow a fix without a major version bump, and probably that's something to review as I now tend to play it safe and put a fix behind a major version bump. Maybe you have some ideas about this as well that you would like to share to flesh out the path forward a little more. |
Here's some rough thoughts I can throw out here. One decision fork is whether to represent git-tree-in-git-db and subdir-in-git-index as separate classes or some binary runtime state that git.Tree can be in. I'm guessing here that keeping git.Tree as one class, not introducing more classes, and just letting git.Tree flip between two possible runtime types is the more practical path given our reality. So I'll proceed assuming this. But maybe this is the wrong approach so feel free to question this assumption. Assuming dual runtime state for git.Tree is the way to go, one idea that comes to mind is whether An additional idea is that there be a
rather than use Lots of possible directions and further implications. But I'll leave you with this idea. Let me know what you think. I'm mostly just brainstorming here. |
Thanks a lot for sharing! In I love the idea of adding another way of accessing tree objects (or entries) for that matter without breaking what's there necessarily. one = repo.head.commit.tree.entry('1') # detach -> entry
two = repo.head.commit.tree.entry('2') Maybe the above can be sugared into one = repo.head.commit.tree('1') # difference between ['1'] and ('1')
two = repo.head.commit.tree('2') if that's possible in python at all (which it might). And even if it was possible, maybe What do you think? |
Good point about the name and file mode in the git db. That makes more sense to return that extra entry information in addition to the git db tree/blob. You can achieve
So overall, sounds like a good idea. Are you thinking a new class? something like And then within |
Good to hear that
I'd think of it as
I don't think I have a clear answer, but rather some intuition on how I'd like to use such object. a = repo.head.commit.tree.entry('1/a') # access to any entry with implicit tree traversal
a.name == "a" # true
a.id == <hash> # I don't know what the object id type is in GitPython, but probably that :D.
a.mode == 0o<octet> # probably a 32 bit number, I think that's used in GitPython already. Could be something that's easier to use as well if needed if that's already present in GitPython
# now, `a` could have all kinds of utility methods, the most obvious might be…
a.object() # returns the object obtained with `.id`
# possibly, it could support returning its own `path()` being `1/a`, but that would require it to keep an additional field to know it's parent path, and I feel it's not needed as the caller already knows that. Looking at it, the above example does not try to identify an Maybe you can take the above and put it into a shape you find more acceptable? I am not past ideation here, and more options and suggestions would definitely be welcome. |
👍
👍 |
Regarding a path() method in
with the example at the start of this gitub issue. If it is true then they should not return a path. If it is false then Entry should provide different paths. I don't have a strong opinion one way or the other on I have more of an opinion on |
To accomplish the objective of this git issue/enhancement, my thought is that the following runs without assert fails (given the example at the start of this github issue/enhancement):
I don't have a good sense of whether it should be To me it makes sense that there should not be a But for backwards compatibility I assume |
Also, I'm not so sure |
Great catch, it's definitely an argument for not having
I love the idea of letting a
And… I love this idea too - it's not making anything up and instead 'just' exposes the tree in the simplest possible way. Yes, let's not support resolution of paths (i.e. paths with Note that I would refrain from deprecating the current API for this as I hope there won't be another major release before |
OK. Given the impressive work you're doing on gitoxide, I can see the reason to freeze this API and let it be replaced by a new backwards incompatible replacement based on gitoxide. |
This enhancement proposal is motivated by confusion in the behavior of subtrees. Issue #851 is one example. This stackoverflow question is another example.
As further example consider the following bash+python script behavior:
and then
which prints out:
What I think most people would expect is that "hi.txt" is contained in both
one
andtwo
and1/hi.txt
and2/hi.txt
are contained in neitherone
nortwo
. This is essentially the same issue noted in #851.I think most people would also not expect these Tree objects to be
==
-equal but then also have a propertypath
that has different values.It seems to me the fundamental problem is that the
Tree
class is trying to behave like two things that are different things:In the sample above,
one
andtwo
are the same git tree but they are not the same subdirectory added to a git index. A git tree does not have apath
but a subdirectory added to a git index does. The current__contain__
logic is kind-of-OK if the objects are subdirectories added to a git index, but make no sense for a git tree.Due to backwards compatibility, this seems a challenging issue to address. I don't know the code and backwards compatibility situation well enough to make any recommendations. But I'm happy to help. I can suggest some different approaches, but I figure it's best to seek your @Byron input on this first.
The text was updated successfully, but these errors were encountered: