Closed caesar0301 closed 4 years ago
Welcome to join me on branch dev
I'm not sure to get it, looking at dev
branch commits I find no trace of my previous commits, did you remove them?
Ah I guess you squashed commits
@leonardbinet Yes, I squashed and reviewed the patch last weekend. Your *_in_tree
functions are replaced by new predecessor and successors interfaces, which deprecate previous bpointer
and fpointer
. An optional arg tree_id
is appended to functions such as is_leaf
and is_root
without proposing new interfaces.
TODO: before we finish #127:
tree_id
as optional arg in setter and getter of predecessor & successors. #127 is an enhanced feature of logic subtrees. It should not effect the clearness of existing interfaces for some simple use cases.@caesar0301 well done for the implementation, I agree with you it is more elegant this way π
However why was it necessary for you to squash commits? If you want me to squash my commits in a single one to avoid having too many, no problem I understand π. But the problem here is that you totally deleted my contribution from the history of the repository (as detailed here: https://github.com/isaacs/github/issues/1303).
This quite matters to me, since I see contributions to open-source projects are the main way for me to showcase my capabilities to potential recruitors etc. In this case I won't appear in git blame, history, or contributors of the repo, whereas I spend quite an effort trying to make a meaningful contribution. Would you consider restoring the history?
If so, you could simply repush feature/tree-wise-node-pointer
branch (https://github.com/caesar0301/treelib/pull/129) so I can fetch it, squash my commits in a single one, and rebase with your following commits, I would then push this branch in dev2
so you can validate if that suits you.
Actually, I could restore history without requiring the feature/tree-wise-node-pointer
branch. I simply squashed my commits and cherry-picked your following ones:
The dev2
branch is now at the exact same point than dev
branch, with only difference being my squashed commit 4dde1fd833bb69a5e8375072575c4c091308ad60
:
β treelib git:(dev2) git fetch upstream
β treelib git:(dev2) git reset upstream/dev2
β treelib git:(dev2) git status
On branch dev2
nothing to commit, working tree clean
β treelib git:(dev2) git reset upstream/dev
β treelib git:(dev2) git status
On branch dev2
nothing to commit, working tree clean
I now only need to force-push dev2
branch into dev
branch and we're good to go, is it ok for you?
FYI I would rather first solve above situation before merging #130 and #134.
FYI to merge #130 and #134 I pushed the branch with restored history in dev
, and kept a copy of your initial branch dev
-> dev_save
so you can compare.
@caesar0301 do you want to include serialization/deserialization #85 in this release? or should we release the current state and make another release in which we'll have time to discuss this separate subject?
@leonardbinet It is fair to remain your efforts on the project through git logs. I compare both dev and dev_save branch and that is OK. I agree with you to start a new release on #85 and #95. Before the release, I should fix the TODOs in https://github.com/caesar0301/treelib/issues/128#issuecomment-564052527 on issue #127.
@caesar0301 for the TODO:
make
tree_id
as optional arg in setter and getter of predecessor & successors. #127 is an enhanced feature of logic subtrees. It should not effect the clearness of existing interfaces for some simple use cases.
-> I disagree, it is a fix, not an additional feature. If you don't set this tree_id
argument you will have unexpected behaviour while using a node
in multiple trees
(using sub_tree
/remove_subtree
for instance) methods since a node won't have same predecessor and successors in different trees
. And I don't think choosing arbitrary the first tree
in which the node has been placed is a good idea (I've commented this subject on this issue: https://github.com/caesar0301/treelib/issues/121).
more UTs to cover the potential errors after introducing this tree-wise feature.
-> IMO it's not that bad but I might help on this, on which methods do you want to increase test coverage?
In the library I plan to release I make use of this feature https://github.com/caesar0301/treelib/pull/138, would you agree to merge such feature in this release?
make
tree_id
as optional arg in setter and getter of predecessor & successors. #127 is an enhanced feature of logic subtrees. It should not effect the clearness of existing interfaces for some simple use cases.-> I disagree, it is a fix, not an additional feature. If you don't set this
tree_id
argument you will have unexpected behaviour while using anode
in multipletrees
(usingsub_tree
/remove_subtree
for instance) methods since a node won't have same predecessor and successors in differenttrees
. And I don't think choosing arbitrary the firsttree
in which the node has been placed is a good idea (I've commented this subject on this issue: #121).
It is reasonable to think about tree_id
when we are talking about multree features. But it doesn't convince me to accept an implementation mannar that expose inner complexities of software or library to users when they merely need basic features in most cases.
I agree with you that it is a fix. It is better to leave it for future release.
In the library I plan to release I make use of this feature #138, would you agree to merge such feature in this release?
It seems a helpful feature and not complicated to do. Let's release 161 when you finish this feature.
v1.6.1 Feature List: