Why using git would be awesome for nexuiz

[[-z-]]

Final warning, make a new thread if you want to talk about other subjects. I'd love to discuss the other topics, just NOT IN THIS THREAD.


Also, please respond to my point about scripts that need updating.

[some-guy]

Final warning, make a new thread if you want to talk about other subjects. I'd love to discuss the other topics, just NOT IN THIS THREAD.


Also, please respond to my point about scripts that need updating.

The only things I see are Nexuiz/data/Makefile (look for pk3) and Nexuiz/misc/tools/makebuild.sh

[divVerent]

It is makebuild.sh, and it relies on properly working "svn export", "svn revert" IIRC too, and "svn info", the latter of which git does not provide in any useful way.

Because, one thing git really lacks is revisions that humans can read. Simple revision numbers as with svn were really a step forward compared to cvs's per-file revisioning...

and git is destroying the transparent numbering scheme of svn (increasing numbers, anyone can understand THAT) in favor of long cryptic hashes.

With git, the file nexuiz-data-base-revision.txt basically becomes useless, as its contents would be too cryptic for any human to understand (exercise: given two git revision hashes, how do you find out which one is the newer one - and how do you find out, given two svn revision numbers?)

Basically, svn's increasing revision number scheme is REALLY good for master source control trees, like Nexuiz's trunk, while git's weird hashes are sure good for people who work in their own local repository. And thus, there is nothing wrong with us using svn for the master repository, and you people using git-svn.

[[-z-]]

The first fair argument against git I've heard in this thread. I can't give you details on that because I too thought the SHA1 hashes were a bit O.o

Perhaps psychf can provide some insight on this.

[Alien]

Heh, mercurial can identify a revision in 3 ways: as a number (as in svn), as a hash (as in git) and as a string name.

For svn info:
http://hgbook.red-bean.com/read/migrati ... l#id442397

[parasti]

It is makebuild.sh, and it relies on properly working "svn export", "svn revert" IIRC too, and "svn info", the latter of which git does not provide in any useful way.

Because, one thing git really lacks is revisions that humans can read. Simple revision numbers as with svn were really a step forward compared to cvs's per-file revisioning...

and git is destroying the transparent numbering scheme of svn (increasing numbers, anyone can understand THAT) in favor of long cryptic hashes.

With git, the file nexuiz-data-base-revision.txt basically becomes useless, as its contents would be too cryptic for any human to understand (exercise: given two git revision hashes, how do you find out which one is the newer one - and how do you find out, given two svn revision numbers?)

At its core, Git is a content-addressable file system; SHA1 hashes is how any objects stored in this system are referred to. Commits are one type of objects that are stored in this system, so it's basically just a side effect that commits can be referred to using hashes. Putting aside the fact that monotonically increasing revision numbers would be useless for most purposes in a decentralized VCS, sure, they could have been implemented as an SVN-friendly way of referring to commits. But it still hasn't happened, and you know why? Because it doesn't matter. Hashes are sufficient in most cases, and tools like "git describe" provide more useful info than "svn info" and SVN revision numbers ever did.

Edit: BTW, just a reminder, I'm not "demanding you to switch to Git NOW". Do WTF you want, stick with SVN, but don't give up on Git for the wrong reasons.

[some-guy]

well, to get revision numbers, you could do:

Code: Select all

n=0
for commit in `git log | grep commit`
do let n=n+1
done
echo $n

[parasti]

well, to get revision numbers, you could do:

Code: Select all

n=0
for commit in `git log | grep commit`
do let n=n+1
done
echo $n

That's giving me ideas.

Code: Select all

$ git log --color | awk -v rev="$(git rev-list HEAD | wc -l)" '$1 ~ /commit/ { printf "r%d | %s\n", rev--, $0; next; } { print }' | less -R

[Alien]

Yet, no one can tell, how git is better than mercurial. Maybe because it isn't. So why the talk is still going on about git?

But, I can't see any reason to switch from centralized model as svn to any type of distributed. The aren't many coders, that said there are only several and strictly speaking there is only one, who can do major changes.

[C167]

@some-guy: well, grepping for "commit" is not enough, cause it counts "commit <commit id>" as well as "reverting commit 1234" i get over 13k commits with that

@parasti:
nice

well, for me, it is easier to try things when using git, i sometimes play around with some code in dp and nexuiz, and it would be a pain to do that using svn. I'm developing a C++ IRC bot, as the original devs stopped developing, and back when they used svn, i needed 4 or 5 different working copies just to not loose work, and keeping them up to date was a pain. When i started using git-svn, i could simply work in different branches, create nicely formatted patches and send them to the devs (as i had no commit rights). If i needed to check something, i just "stashed" my work, which works like a lifo buffer: you put changes on the git stash stack, and apply it if you are finished. Well, now i moved it to git, and still have 5 or 6 local branches, and some public ones. i now need some more commands than when using svn, but thats due to the decentralized nature of the project. I need some seconds to find out information about commits, blame is done in some seconds, i have nicely formated information about everything, with or without gui, and i never need to access any slow (svn) or fast (git) server except for some push from time to time.

if you really want revision numbers, then you can use a script like parastis, but in general, i see (personally) see no need to have revision numbers.