Willy Tarreau wrote:
> It should not turn into an endless thread led by people who want to > redefine GIT's roadmap, but experience sharing helps a lot with GIT.
Well, now that you mentioned it, if there is one thing I dislike, it's for version control to start mutilating your sources. Version Control should be completely transparent. GIT isn't.
Thanks!
-- Al
Al Boldi wrote:
> Willy Tarreau wrote: >> It should not turn into an endless thread led by people who want to >> redefine GIT's roadmap, but experience sharing helps a lot with GIT. > > Well, now that you mentioned it, if there is one thing I dislike, it's for > version control to start mutilating your sources. Version Control should be > completely transparent. GIT isn't. > > Thanks! > > -- > Al >
Care to explain? Git is quite happy handling arbitrary binary content, so I find it difficult to believe that it is changing your source code in strange ways.
Rogan
Johannes SchindelinHi,
On Wed, 28 Nov 2007, Rogan Dawes wrote:
> Al Boldi wrote: > > > Willy Tarreau wrote: > > > > > It should not turn into an endless thread led by people who want to > > > redefine GIT's roadmap, but experience sharing helps a lot with GIT. > > > > Well, now that you mentioned it, if there is one thing I dislike, it's > > for version control to start mutilating your sources. Version Control > > should be completely transparent. GIT isn't. > > Care to explain? Git is quite happy handling arbitrary binary content, > so I find it difficult to believe that it is changing your source code > in strange ways.
It is nice of you to ask him to explain: Unless this handwaving claim is substantiated, it is quite hard to argue with.
Ciao, Dscho
Johannes Schindelin wrote:
> Hi,
Hi!
git@vger sometimes bounces, so let's leave lkml as backup.
> On Wed, 28 Nov 2007, Rogan Dawes wrote: > > Al Boldi wrote: > > > Willy Tarreau wrote: > > > > It should not turn into an endless thread led by people who want to > > > > redefine GIT's roadmap, but experience sharing helps a lot with GIT. > > > > > > Well, now that you mentioned it, if there is one thing I dislike, it's > > > for version control to start mutilating your sources. Version Control > > > should be completely transparent. GIT isn't. > > > > Care to explain? Git is quite happy handling arbitrary binary content, > > so I find it difficult to believe that it is changing your source code > > in strange ways. > > It is nice of you to ask him to explain: Unless this handwaving claim is > substantiated, it is quite hard to argue with.
Sure, the problem with GIT is that it stores the sources inside a backend container that is only accessible via GIT; iow, you can't retrieve your sources directly / transparently.
One way to achieve transparency could be to allow mounting GIT on a dir-mount point. And just use that dir normally, while GIT manages all the rest in the background.
Thanks!
-- Al
Johannes SchindelinHi,
On Wed, 28 Nov 2007, Al Boldi wrote:
> git@vger sometimes bounces, so let's leave lkml as backup.
Fair enough.
> Johannes Schindelin wrote: > > On Wed, 28 Nov 2007, Rogan Dawes wrote: > > > Al Boldi wrote: > > > > Willy Tarreau wrote: > > > > > It should not turn into an endless thread led by people who want > > > > > to redefine GIT's roadmap, but experience sharing helps a lot > > > > > with GIT. > > > > > > > > Well, now that you mentioned it, if there is one thing I dislike, > > > > it's for version control to start mutilating your sources. > > > > Version Control should be completely transparent. GIT isn't. > > > > > > Care to explain? Git is quite happy handling arbitrary binary > > > content, so I find it difficult to believe that it is changing your > > > source code in strange ways. > > > > It is nice of you to ask him to explain: Unless this handwaving claim > > is substantiated, it is quite hard to argue with. > > Sure, the problem with GIT is that it stores the sources inside a > backend container that is only accessible via GIT; iow, you can't > retrieve your sources directly / transparently.
That is a very funny way to define a "transparent SCM". Are you complaining about SQL servers being "not transparent"?
By that definition, no SCM, not even CVS, is transparent. Nothing short of unpacked directories of all versions (wasting a lot of disk space) would.
IOW the issue you raised is a non-issue.
Ciao, Dscho
Johannes Schindelin wrote:
> By that definition, no SCM, not even CVS, is transparent. Nothing short > of unpacked directories of all versions (wasting a lot of disk space) > would.
Who said anything about unpacking?
I'm talking about GIT transparently serving a Virtual Version Control dir to be mounted on the client.
Thanks!
-- Al
Jakub NarebskiAl Boldi wrote:
> Johannes Schindelin wrote:
>> By that definition, no SCM, not even CVS, is transparent. Nothing short >> of unpacked directories of all versions (wasting a lot of disk space) >> would. > > Who said anything about unpacking? > > I'm talking about GIT transparently serving a Virtual Version Control dir to > be mounted on the client.
Are you talking about something like (in alpha IIRC) gitfs?
http://www.sfgoth.com/~mitch/linux/gitfs/
Besides, you can always use "git show <revision>:<file>". For example gitweb (and I think other web interfaces) can show any version of a file or a directory, accessing only repository.
-- Jakub Narebski Warsaw, Poland ShadeHawk on #git
Jakub Narebski wrote:
> Al Boldi wrote: > > Johannes Schindelin wrote: > >> By that definition, no SCM, not even CVS, is transparent. Nothing > >> short of unpacked directories of all versions (wasting a lot of disk > >> space) would. > > > > Who said anything about unpacking? > > > > I'm talking about GIT transparently serving a Virtual Version Control > > dir to be mounted on the client. > > Are you talking about something like (in alpha IIRC) gitfs? > > http://www.sfgoth.com/~mitch/linux/gitfs/
This looks like a good start.
> Besides, you can always use "git show <revision>:<file>". For example > gitweb (and I think other web interfaces) can show any version of a file > or a directory, accessing only repository.
Sure, browsing is the easy part, but Version Control starts when things become writable.
Thanks for the link!
-- Al
On Nov 29, 2007, at 00:27:04, Al Boldi wrote:
> Jakub Narebski wrote: >> Besides, you can always use "git show <revision>:<file>". For >> example gitweb (and I think other web interfaces) can show any >> version of a file or a directory, accessing only repository. > > Sure, browsing is the easy part, but Version Control starts when > things become writable.
But... git history is very inherently completely immutable once created... that's the only way you can index everything with a simple SHA-1. If you want to write to the "git filesystem" by adding new commits then you need to use the appropriate commands, same as every other VCS on the planet.
Cheers, Kyle Moffett