Thread (16 messages) flat view 16 messages, 7 authors, 2016-06-15

Re: [RFC PATCH] Re: Empty directories...

From: Julian Phillips <hidden>
Date: 2016-06-15 22:43:22

On Fri, 20 Jul 2007, Linus Torvalds wrote:

On Fri, 20 Jul 2007, Johan Herland wrote:
quoted
Does this mean that you are firmly opposed to the concept of storing
directories in the index/tree as such, or that you are only opposed to
(some of) the implementation ideas that have been discussed so far?
I've already sent out a *patch* to do so, for chissake. It handled all
these cases perfectly fine, as far as I know, but I didn't test it all
that deeply (and made it clear when I sent that patch out).

In fact, in this whole pointless discussion, I think I'm so far the only
one to have done anything constructive at all. Sad.
There was Dscho's .gitignore based patch too ...
So here's my standpoint:

- people who use git natively might as well use the ".gitignore" trick.
  It really *does* work, and there really aren't any downsides. Those
  directories will stay around forever, until you decide that you don't
  want them any more. Problem solved.

  Sure, if you export the git archive into some other format, you might
  well want to do something about the ".gitignore" files (like just
  delete them, since they won't be meaningful in an SVN environment, for
  example, but you might also just convert them into SVN's "attributes"
  or whatever it is that SVN uses to ignore files).
Personally I quite like this approach - I'm going to use it to keep all 
the empty directories from Subversion in my importer.  It seems to address 
everthing quite neatly.

I don't really understand the objections ... especially since I can't see 
why you want an empty directory if you're not going to put _something_ in 
it - in which case, presumably you want to ignore it (so maybe a 
.gitignore containing * would be better than an empty one)?  However, I'm 
sure that if people want it, they have a reason.
SCM is too important to play games with. Git gets things right, and I
doubt people really _realize_ that the "tracks content" is why git is so
much better, and why git can do merges so much faster and more reliably
than anybody else.
This is the thing that made me interested in git back in April '05.  I 
couldn't see what we were going to end up with at that point - but I was 
_convinced_ that due to the underlying design it was worth watching. 
Being a python type (sorry ... :$) hg looked interesting when it sprang up 
- but they threw away what I considered to be one of the most compelling 
features of git (at the time there wasn't the wealth of really nice tools 
that we now have).

In fact, I really should say "Thank you Linus", since I came that close to 
writing an SCM from scratch myself - having been using Subversion with 
branches for quite some time (and CVS before that - and yes I do mean 
branches + CVS).  Now I no longer feel the need to write an SCM - just a 
longing to use git.  git is probably better than anything I would have 
come up with too. :D

-- 
Julian

  ---
She is descended from a long line that her mother listened to.
 		-- Gypsy Rose Lee
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help