Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > On Mon, 13 Oct 2008, Junio C Hamano wrote: > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: >> >> > - all the editors that this guy tested keep the hard links, so it was >> > kinda hard to understand why Git insists on behaving differently, >> > >> > - if the user asked for hard links, it is not Git's place to question >> > that decision, >> >> These are non-arguments, > > Actually, they are arguments. > > The thing is: these editors do what they do for a reason. Which is > exactly the second reason. > > When a user makes hard links, it is not just for fun and bullocks. It is > not for copy-on-write either, that's not what hard links are supposed to > do. It is for cases when you need the _same_ information in two places. > > I am not that big a user of hard links myself, but when I do, I know > exactly what I am doing. And with my patch and that config variable set > to true, Git will not interfer with that. Ok, such a possible benefit should be described and defended better then. I only thought of the scenario Shawn has brought up, which is a downside of using this option without any conceivable upside, when I read your patch and your rationale you repeated in a few messages that followed. You could have said something like "The users may want to have a checkout, and keep the same contents always appear elsewhere i.e. 'installing by hardlinking'. In such a setup, editing the source with an editor configured not to break hardlinks would still work fine, but git-checkout will unconditionally break such links, which is undesirable. Such a setup would want a configuration variable like this." "It is not for fun and bullocks" is not a description any clearer than what you kept repeating, but if you stated it like the above, then I would not have had trouble understanding what you wanted to say. The documentation update needs to warn about the Shawn's scenario. I also do not know what this should do when you have two tracked paths with identical contents hardlinked to each other. Because we do not track hardlinks, I _think_ breaking links would be the right thing to do for such paths regardless of this configuration variable. It also raises another question. Don't you want this to be an attribute for paths, not all-or-nothing configuration per repository? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
