06393993

> 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...

> 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...

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....

While none of the following questions should block the merge, they are probably worth answering: 1. It seems that this change only handles the snapshot path. I am wondering if...

I am asking in details just because this CL is very different from [my design](https://github.com/06393993/jj/blob/gitattr-design/docs/design/gitattributes.md), that I plan to propose early this August, and am nervous about the unfortunate conflict:...

Thanks. The plan for my design is to go through [the formal design process](https://jj-vcs.github.io/jj/latest/design_docs/#process) to avoid surprises on code review. I was somewhat actively discussing the design in the dicord...

Re udaya2899, I am not a maintainer, so I can't make the decision. But I personally am not against this PR, because we can always introduce fixes afterwards. However, this...

> working-copy.eol-conversion with values "none"/"input"/"input-output" Let's take those names. > I think we should rename core.fsmonitor to working-copy.fsmonitor, btw. Will be in one of my future PRs then. > Maybe...

Can you take another look at the commit that derived the executable field and the copy id field from the existing sides if not ambiguous? Thanks.

> I wonder if we should apply EOL conversion on each term of the conflict instead. The update path is simple: https://github.com/jj-vcs/jj/blob/b9317da0f88534b0efa33d98eba4c8a300d341e4/lib/src/local_working_copy.rs#L2233-L2244 Instead of passing the original file contents to...