Tracking an entire Windows sytem inside Git | Hacker News Reader

Tracking an entire Windows sytem inside Git

alumnit.ca

62 pointsswapspace21 comments

Unfortunately, I can't advise you to try to duplicate my setup. I happened to have a valid Windows 98 license and a valid Win4lin license, neither of which you can buy anymore

I don't know about win4lin, but acquiring a Windows98 license can be as easy as picking up an ancient, free PC from Craigslist with a registration sticker on it.

If you have the requisite large-company/educational institute Microsoft licensing, you get to download Microsoft programs from their Technet website - right back to DOS and Windows 3.

Win4Lin licensing might be more of a problem, though.

I always wonder if Linus might integrate his projects more. Note:

* Git - a filesystem based revision control system by Linux

* BtrFS - a filesystem with writable snapshots, integrated into a kernel controled by Linus

Might ever integrate themselves more. Ie, SVN commands actually using the underlying filesystem to store the data.

Git would therefore:

* Be compeletely transparent to applications and users, storing updates and comments in the filesystem as snapshots and extended attributes

* Be able to revision control binary objects without needless storage of duplicated data.

It doesn't sound like it would be that hard to combine the two. Both are open source projects ...

The more I use git the more impressed I am with it. We now use git to control access and distribution of distributed files. Previously we did that via NFS, but git was cleaner and simpler to manage access restrictions.

That's a very unique but good application of version control.

It takes a special kind of person to think, "I'm going to take this thing meant for code and use it for what is basically an OS."

I think it's reasonably common to check your home directory into revision control...

And /etc is pretty standard, too.

Git is one of those cases where something that begins life as an incremental improvement turns out to be such an incremental improvement that a qualitative leap occurs. New things become possible that you just wouldn't have thought of before - there wouldn't have been any point. Applications in completely unrelated areas spring up.

Sometimes I think that Torvalds may end up being remembered more for git than for Linux.

"Sometimes I think that Torvalds may end up being remembered more for git than for Linux."

Seriously??? I think even he would think that slightly laughable.

Git seems like an ok-ish version control system - there are a ton of them about now. Linux was a pretty big revolution and is pretty unique.

Linus has wrought three public miracles:

1) He had the chutzpah to just sit down and write a straightforward kernel for the 386, with no intentions of pedagogy (minix), research (mach), or circlejerkery (hurd).

2) He pioneered the distributed development model in the late 90s that made it possible for Linux to bloom.

3) He sat down and advanced the state of free version control a decade over the course of a weekend.

His initial writing of Linux is the least important of the three, if he hadn't done it someone else would have. The remarkable thing is how he kept it going.

Which has the most alternatives/competitors. Git or Linux?

> 3) He sat down and advanced the state of free version control a decade over the course of a weekend.

I'd say that's a bit of a stretch. Remember DARCS and Mecurial were both out when he wrote git. Though Mercurial wasn't that old:)

Read this: http://www.catb.org/esr/writings/version-control/version-con...

Many people prefer Hg over Git, though I prefer Git, and it was written before Git.

I'd agree that Linus helped "advance the state of free version control", but certainly not by a decade when compared to other pre existing free version control systems.

Seriously???

Well, half-seriously. History makes it very clear that you can't tell in advance what someone will be remembered for... often the thing that everyone thought was the biggest deal is just forgotten. Certainly it doesn't matter what Linus thinks about it.

I'd say git is a lot more than an ok-ish version control system because of two things: its design (hashes and all that) and its efficiency. We were using darcs before, which is fine, but after using them both extensively I can say that they are two systems that aren't in the same league. Even their leagues aren't in the same league. Git is so much more powerful that you begin to have new ideas - that's the point of my original comment.

Wasn't this possible with other version systems before?

There may be truth to that, but I don't think this is a very good example. Joey Hess has kept his ~ and /etc in CVS (and later, SVN) since 2000 or so. You don't need any particular feature of Git or even a DVCS to keep your system completely versioned.

I guess the reason he can't do the same with vmware images is that git is slow with huge files. On the other hand, vmware snapshots should allow what he wants - to keep several closely related versions of the system and the ability to start any of them. Am I missing something?

I've tried this before with a VirtualBox image of XP. Even the base install of XP, without any updates or added software, is too large for Git to handle, or at least too large on my machine with 2GB of RAM.

According to this thread:

http://news.ycombinator.com/item?id=374416

Git is particularly bad for large files, while good old SVN handles them Ok.

And CVS handles them far better than SVN.

Why the hell would you want to version and branch and merge one huge blob? The point of this is that it's versioned just like it was a straightforward filesystem mount.

You can't take forked vmware snapshots and merge them back into one another, or track changes from their shared parent, or anything less primitive than vanilla snapshots.

Reply on news.ycombinator.com