jj-vcs
design: cornerstone for gitattributes features
Checklist
N/A:
- [ ] I have updated
CHANGELOG.md - [ ] I have updated the documentation (
README.md,docs/,demos/) - [ ] I have updated the config schema (
cli/src/config-schema.json) - [ ] I have added/updated tests to cover my changes
The example implementation is at https://github.com/06393993/jj/compare/gitattr-design...gitattr-design-wip-alt.
@06393993 any desire to continue?
Yes, but I don't have much time right now, and I don't recieve too many of review yet. Probably because I didn't push the contributors enough.
@martinvonz @PhilipMetzger do you find that feature feasible for integrating in the near future?
do you find that feature feasible for integrating in the near future?
Yes, I even pushed for attention on it in the Discord recently. The thing is that both Martin and I are busy preparing for either jj-con and Git Merge.
do you find that feature feasible for integrating in the near future?
I'm fine with merging this as is even though it's still unclear to me what the impact on the code will be.
busy preparing for either jj-con and Git Merge.
Or both :(
@06393993: Reminder that you're free to merge this as far as I'm concerned.
Great to see so much activity for this highly desired feature! Can someone provide a status update and explain what is missing to get this merged and move forward?
Can someone provide a status update and explain what is missing to get this merged and move forward?
I don't want to merge this design merged without any actual usage of gitattributes, i.e., this PR should be merged with the EOL gitattributes design https://github.com/jj-vcs/jj/pull/7997 or with the filter gitattributes design https://github.com/jj-vcs/jj/pull/8144.
However, the EOL gitattributes design is blocked by a naming of a specific type, and needs more votes/comments from other maintainers. The filter gitattributes design is still WIP, and requires extra work - child process is difficult to manage and complicated to test.
Do I understand correctly that the two features we have planned for gitattribute support (EOL and filters) will support it only in the working copy?
Yes
But this doc mentions a diff attribute too.
I think you mentioned diff at, https://github.com/jj-vcs/jj/pull/7164#discussion_r2483988075, so I thought you suggested that we should ~~include that as part of this design~~. EDIT: I thought you suggested that we should mention that, not necessarily came up with a design that solved the issue.
Do you think that's something we'll have to support later? Or can we get away with not supporting that?
No, we don't have to. Filter and EOL conversion themselves are self-contained features. And I don't have any opinions on whether we should. But I do see users asking for that feature, e.g., https://github.com/jj-vcs/jj/issues/53#issuecomment-3187498799. We can open another issue to discuss whether we want to support it: if so how, if not, how do we satisfy some specific users' need or politely warn them in the document that we don't plan such features.
I think you mentioned diff at, #7164 (comment), so I thought you suggested that we should include that as part of this design.
Ah, sorry if that was confusing. I meant that we should say whether jj diff will show the content as stored in the repo or after filtering (or EOL conversion etc.).
I asked because it significantly affects the design. It seems significantly simpler to do the filtering etc. only in the working copy as the two current designs suggest. That affects only local_working_copy.rs IIUC. If we want jj diff, jj rebase, jj file show etc. to understand gitattributes, then that seems like it will affect many more parts of the code.
Sure. We can always divide and conquer.
jj rebase I think will be under the "merge" topic. jj diff and jj file show should be both under the "diff" topic. Will open 2 new issues right after this design is merged.