undefined | Better HN

0 pointstinco13y ago0 comments

> I am going to do my best.

Great :)

> One of the disputes here is that the maintainers are of the opinion that config files are actually good, on the face of them. They point to examples of well-settled uses like .gitignore to claim that config files are The Git Way.

Yes but .gitignore only configures your git client, the gitsubmodules say something about the repository instead. If that was the git way, wouldn't branch names be in a .gitbranches as well?

> I don't want to get into a big meta-meta flamewar here, but there are many people who do reject the merits of refactoring

I might be an extremist on this topic, so it's good to just leave it be.

> This is why I suspect the solution here is to have two distinct APIs, that access the same underlying storage mechanism.

I agree, but I think Ram. is correct in asserting that both ways could be achieved by having a link object with some configuration in it. (it could just be the .gitmodules file moved to the .git directory for all the end users care)

> The compatability-break burden is extremely high.

I understand, and it should not be taken lightly. But no one was suggesting this feature would be added to the master and shipped in the next release of git. It could even be delayed until there is another compatibility breaking change. Ram. never pretended his current work would be the final way of doing it.

Thank you for elaborating your understanding of the discussion :)

0 comments

drewcrawford13y ago

This is one of the nicest disagreements I have ever had. If we don't already, we should compare notes and find something to work on together, because when two people can disagree but still understand each other, that is where you make progress on complex problems. :-)

> Yes but .gitignore only configures your git client, the gitsubmodules say something about the repository instead.

This feature is often used to configure the repository, and I in fact use it that way. By way of example, https://github.com/new operates under the assumption that you use .gitignore to configure a repository. Perhaps it is best to say that config files offer flexibility in this dimension, whereas a link file is more rigid.

> It could even be delayed until there is another compatibility breaking change.

I believe that perhaps the discussion on the point of backwards incompatibility has been framed in a way that is nonproductive. Of course, once one has decided on a course of action, it is proper to consider how to reduce the impact of that decision. I agree with you that there are a wide variety of harm reduction strategies available here.

But these inquiries only become relevant once one has decided that the patch is in general an improvement in some dimensions. As an outside observer, I do not see an improvement.

I can see the logic that if it is true that git-add-and-friends have omitted support for submodules on the basis that such support is difficult, this patch could solve that problem. But I have not been convinced of the premise; there is no citation of the people who maintain the UI tools making claims of difficulty. Furthermore, Junio seems to argue at least that add's behavior is by design, I do not know enough about it to know if that is a sensible design, but it does suggest to me that the problem with UI tooling is not a function of implementation difficulty, but there is perhaps some design or ideological reason for the behavior of these tools that explains the state of them today.

The other problem that I have is as follows: if I accept the premise that the trouble with git-add is a matter of implementation difficulty, it seems to me that the trouble can be resolved at some other tool layer rather than in the FS proper. So if the hypothesis underlying the patch is correct, it seems to me that one should adopt the implementation that doesn't break compatibility over the implementation that does.

It is unfortunate that the matter of backwards compatibility was raised early and vociferously in the thread, because as you have pointed out there is a lot that can be done about backwards compatibility that doesn't address the real merits of whether the idea is good or bad. (Although I can understand why compatibility would be at the top of any maintainer's mind.) Perhaps this exchange between Junio and Ram. is an example of two people being far enough along their own lines of inquiry that they are having trouble making any sense of one another.