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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 20 Jul 2007, Linus Torvalds wrote:



On Fri, 20 Jul 2007, Johan Herland wrote:

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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux