Skip to content
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

DOC: Rephrase save(to_git=) docs to indicate lack of choice persistence #4290

Merged
merged 2 commits into from Mar 13, 2020

Conversation

mih
Copy link
Member

@mih mih commented Mar 13, 2020

Closes gh-1974

CI canceled, only doc change.

@mih mih added the documentation label Mar 13, 2020
adswa
adswa approved these changes Mar 13, 2020
Copy link
Member

@adswa adswa left a comment

I only found a typo (See comment)

datalad/core/local/save.py Outdated Show resolved Hide resolved
Co-Authored-By: Adina Wagner <adina.wagner@t-online.de>
@mih
Copy link
Member Author

mih commented Mar 13, 2020

Thx @adswa !

@mih mih merged commit a2da274 into datalad:master Mar 13, 2020
5 of 16 checks passed
@mih mih deleted the bf-1974 branch Mar 13, 2020
it is better to pre-configure a dataset to track particular paths,
tracking data identity only. Use with caution, there is no
guarantee that a file put directly into Git like this will
not be annexed in a subsequent save operation.
Copy link
Collaborator

@kyleam kyleam Mar 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I personally find this unclear. It sounds like it could be expected behavior for a save operation to throw unmodified git files into annex.

Guess you didn't like my suggestion in gh-1974, but I think that avoids the issue.

Copy link
Member Author

@mih mih Mar 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think given the behavior shown in gh-1974 we have to discourage this option as much as possible. I did not consider the possibility to interpret my changes in the way you point out. But just the change you suggested did not emphasize the potential pitfalls enough for my taste. Personally, I think if the new wording discourages this kind of use more than necessary, it is still a good thing.

Ultimately, I think we have to make such a call add matching .gitattribute settings.

Copy link
Collaborator

@kyleam kyleam Mar 13, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Personally, I think if the new wording discourages this kind of use more than necessary, it is still a good thing.

I don't think wording things in a way that could lead to a misunderstanding is a good thing, even if it leads to a particular behavior that we see as desirable. Anyway, we don't seem to agree on this, it doesn't particularly matter, and it is already merged, so I'll drop it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants