Re: [RFC/PATCH 0/7] Rework git core for native submodules

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

 



Jens Lehmann wrote:
> Hmm, at least the unstaged .gitmodules file has to be parsed from
> the file system.

You seem to be touting it as a distinct advantage.  In my opinion,
.gitmodules is a wart that needs to be done away with: it should _not_
be on the filesystem, just like a commit object isn't on the
filesystem.  Getting links to unstage is two hours of work, tops.  And
I'm the one writing the whole thing, so I don't see what everyone else
is complaining about.

> And Heiko's current work on parsing .gitmodules
> directly from the object store will help here too, right?

Ofcourse, you _can_ parse a blob into a struct.  It's just extremely
gross to treat a blob located in a certain tree path differently from
other blobs.  It's a perverse violation of git's fundamental design,
and I'm strongly against such a change.

What I still fail to understand is why you keep mentioning
work-in-progress.  You've had five years in which you haven't been
able to do things that I did in two days.  Yes, you _can_ keep
.gitmodules and hack around everything, but why do you _want_ to do
that?  Preserving backward compatibility is not *that* important, in
my opinion.
--
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]