divVerent wrote:Only you guys always come with stupid demands.

nice one

divVerent wrote:And nobody wants to use SUCH a system then.

Damn straight.

divVerent wrote:And I am not talking about a full emulation. There's like six seven commands that actually are used frequently:

update
commit
diff
annotate
revert
status
log

yup...
git pull
git commit -m "message" && git push
git diff
git annotate
git reset --hard
git status
git log

I don't see what the big deal is. You can even add the aliases yourself if you really want to.

Also, I don't seem to understand why everyone is getting so worked up about this, we're just making some suggestions, and trying to clear up any misconceptions. Try to calm down.

divVerent wrote:And that includes that I refuse to relearn a whole command set because of stupid demands from some guys on the forum who never contributed anything and never will.

Okay, some commands are different, but git is a bit different from svn.

divVerent wrote:And I am not talking about a full emulation. There's like six seven commands that actually are used frequently:

Svn on the left, git on the right. Sometimes, one svn command gets replaced by multiple git commands, mostly due to the fact that changes are locally first before getting pushed to the server:

Code: Select all

update      pull
commit      (add;) commit; push
diff      diff
annotate   blame
revert      checkout; push
status      status
log      log


divVerent wrote:Anything else can have obscure names, as they're so seldomly used that one would look them up before use anyway (apart from checkout, but checkout is only used once per repository and thus does not matter).
If git is worth ANYTHING, there are direct equivalents to these seven commands.

Especially you should see the fact that a system that is meant to support local changes without direct publishing to the server needs some more commands.

divVerent wrote:All I ask for is if git could get these as alias (the remaining syntax can sure be SCM dependent, e.g. revisions are specified differently in cvs and svn) to the existing commands doing that, to make git less obscure. This is simply about user friendliness.

If the git guys refuse to add such aliases, one can follow that they don't care about their users. And nobody wants to use SUCH a system then.

Well, git can sure handle aliases, but I can't imagine that you don't see the need for one or two more commands compared to svn/cvs when supporting server-independance.

The reason for update beeing split up is simple: you first tell the system what of your changes should be commited (add). Then you commit, using your $EDITOR (vim or any other editor) to your local checkout. After that, you publish using the push command.

Also, revert (checkout for git) first does the stuff locally, after that you publish it. If you want commit to do the stuff you want, just add a simple alias to your .git/config file.

@Psychcf
git annotate:

Code: Select all

git-annotate - Annotate file lines with commit information

svn annotate:

Code: Select all

blame (praise, annotate, ann): Output the content of specified files or
URLs with revision and author information in-line.                     
usage: blame TARGET[@REV]...

you mean git blame

Heh, I used this thread simply to enlighten myself further in pros and cons of various source control systems without any demands for developers.

divVerent wrote:And I want svn.

And I do not want to switch the system because _I_ see no point in doing so. Only you guys always come with stupid demands. I'd only change for your demands if it does not cost MY time. And that includes that I refuse to relearn a whole command set because of stupid demands from some guys on the forum who never contributed anything and never will.

Well, your attitude will surely be a part of the reason why they never will! Besides, that's not true; Psychf, the guy who started this thread, apparently added a player classes mutator to Nexuiz, and my first toy patch to DP is still rotting away at dev.alientrap.org.

Realise that this is just a suggestion not a demand (at least from my side), and the only way switching to Git makes any sense whatsoever is if you personally want to switch. Flaming somebody is always fun, but you could have avoided all that if you just said "SVN is fine, no thanks".

Anyway...

What I want is simple semantics of well-known command names.

And I am not talking about a full emulation. There's like six seven commands that actually are used frequently:

update
commit
diff
annotate
revert
status
log

Anything else can have obscure names, as they're so seldomly used that one would look them up before use anyway (apart from checkout, but checkout is only used once per repository and thus does not matter).

If git is worth ANYTHING, there are direct equivalents to these seven commands.

Roughly:

"svn update" -> "git pull"
"svn commit" -> "git add" + "git commit" + "git push"
"svn diff" -> "git diff"
"svn annotate" -> "git blame"
"svn revert" -> "git checkout" (BTW, "git revert" takes a commit and commits an inverse patch of it)
"svn status" -> "git status"
"svn log" -> "git log"

I also don't use these two much, but check out "gitk" and "git gui", which are both included with Git. They're graphical, but I hear rumours they're as powerful as the command line interface.

By the way, Git has mostly excellent documentation, including a tutorial. Read the first few paragraphs and you'll know enough Git to use it for your personal hacks.

Psychcf wrote:I don't see what the big deal is. You can even add the aliases yourself if you really want to.

Also, I don't seem to understand why everyone is getting so worked up about this, we're just making some suggestions, and trying to clear up any misconceptions. Try to calm down.

The reason is simple: it fscks up everyone's workflow. It gets in the way, to have to relearn things, change release scripts. It takes months to get back in to the swing where one is comfortable with a tool.

And for what benefit?
Vi vs emacs?

Why git?

Easier for you? You allready can use git-svn gateway commands, you're allready good-to-go! No need for change .

Or a self-appointed management-type deciding this-is-how-it-must-be-done? That this is more "effecient" (ofcourse ignoring re-tooling and re-starting and re-learning time...).

No, that's not how OSS works: it's not a company, the developer(s) rule, not some "manager", not some "boss"... and if someone thinks they can just fill the role of boss and they push the devs... and try to force or coerce... well then you don't have an OSS project anymore (as you don't have developer(s) anymore).

Svn works well, there's no reason to laden those trying to coble code together with the overhead of learning a new system and redoing scripts etc.

Everyone knows svn.

Only those who have to deal with contributing patches to oh-so-exploitable linux 2.6 deal with git.

parasti wrote:Realise that this is just a suggestion not a demand (at least from my side), and the only way switching to Git makes any sense whatsoever is if you personally want to switch. Flaming somebody is always fun, but you could have avoided all that if you just said "SVN is fine, no thanks".

Anyway...

Saying "svn is fine, no thanks" is never enough. It was allready said and still people pushed for useless bueracratic change... it's almost like they are "pointy haired bosses": 'if we randomly change things and waste more and more overhead things might be better for whatever we are aiming for!'. Thusly a more .... explained opinion is needed (and then you react to it anyway).

Also git won't get your patch in faster: the patches still have to be tested, looked over, so worshiping git hoping for change is to put faith in a false god. Looking over patches will always take time, such is required because in the past bad patches have broken svn features for months.

tundramagi wrote:

parasti wrote:Realise that this is just a suggestion not a demand (at least from my side), and the only way switching to Git makes any sense whatsoever is if you personally want to switch. Flaming somebody is always fun, but you could have avoided all that if you just said "SVN is fine, no thanks".

Anyway...

Saying "svn is fine, no thanks" is never enough. It was allready said and still people pushed for useless bueracratic change... it's almost like they are "pointy haired bosses": 'if we randomly change things and waste more and more overhead things might be better for whatever we are aiming for!'. Thusly a more .... explained opinion is needed (and then you react to it anyway).

Also git won't get your patch in faster: the patches still have to be tested, looked over, so worshiping git hoping for change is to put faith in a false god. Looking over patches will always take time, such is required because in the past bad patches have broken svn features for months.

Did you even read the thread? It's not a useless change and it was merely a suggestion with support about the benefits. divVerent took it as "omg people are trying to ruin the project again" when in reality, pyschf was just trying to make life easier for everyone with this suggestion.

If you read www.whygitisbetterthanx.com you'd be more informed about some of the benefits. SVN is a decent versioning system but it is by no means perfect. You can't honestly tell me you've never wasted time fixing things you borked with SVN. I've found git to be much more forgiving than SVN ever was.

Pulling this "bueracratic change" propaganda bullshit, I'm getting the feeling you're more in support of getting a kick out of watching people argue than you are interested in the benefits changing the versioning system can have on the project.

As far as I'm concerned, this is an open discussion about the benefits and downfalls of git vs. svn. Yes, some scripts would need some minor changes to get things on the right track but it's a small price to pay if it means we can fork, merge and have less conflicts overall in the versioning.

You can't deny that mods like nexball or nexuiz team fortress couldn't benefit from local branching

oh, by the way, if you just want really clean up your repo from everything:

Code: Select all

cd repo
rm -rf *
git reset --hard HEAD

and your repo looks like a fresh clone again. Not needed often, but compared to svn where you could run into serious trouble if one of the .svn folders makes problems, it is save

"rm -rf" is a bit brute force. If you want to get rid of untracked files, use "git clean".

yea, i also get rid of tracked files and i'm used to that, as git is very fast in restoring the files

[-z-] wrote:

tundramagi wrote:

parasti wrote:Realise that this is just a suggestion not a demand (at least from my side), and the only way switching to Git makes any sense whatsoever is if you personally want to switch. Flaming somebody is always fun, but you could have avoided all that if you just said "SVN is fine, no thanks".

Anyway...

Saying "svn is fine, no thanks" is never enough. It was allready said and still people pushed for useless bueracratic change... it's almost like they are "pointy haired bosses": 'if we randomly change things and waste more and more overhead things might be better for whatever we are aiming for!'. Thusly a more .... explained opinion is needed (and then you react to it anyway).

Also git won't get your patch in faster: the patches still have to be tested, looked over, so worshiping git hoping for change is to put faith in a false god. Looking over patches will always take time, such is required because in the past bad patches have broken svn features for months.

Did you even read the thread? It's not a useless change and it was merely a suggestion with support about the benefits. divVerent took it as "omg people are trying to ruin the project again" when in reality, pyschf was just trying to make life easier for everyone with this suggestion.

If you read www.whygitisbetterthanx.com you'd be more informed about some of the benefits. SVN is a decent versioning system but it is by no means perfect. You can't honestly tell me you've never wasted time fixing things you borked with SVN. I've found git to be much more forgiving than SVN ever was.

Pulling this "bueracratic change" propaganda bullshit, I'm getting the feeling you're more in support of getting a kick out of watching people argue than you are interested in the benefits changing the versioning system can have on the project.

As far as I'm concerned, this is an open discussion about the benefits and downfalls of git vs. svn. Yes, some scripts would need some minor changes to get things on the right track but it's a small price to pay if it means we can fork, merge and have less conflicts overall in the versioning.

You can't deny that mods like nexball or nexuiz team fortress couldn't benefit from local branching

Just because I disagree with you does not mean I didn't read the discussion. I read every word, some multiple times.

Pyschf uses git and would like, for his own benifit, that others use it aswell: that way his additions would be easier to add.

I read the thread. The benefits were "It's faster, takes up less space" and something magical about forking and re-merging without any conflict problems, magically, regardless of how long and how much the 2 branches have diverged (seems... impossible).

The detractions were: it will mess up everyone's work flow, you'll be forcing the rewriting of scripts (are you going to rewrite them?), it will take a long time for people to readjust... and just when they've done that another buerecratic idea will be ramed through everyone's skulls and hearts... and they'll have to relearn some new thing rather than doing work on the project itself.

Nexball and nexuiz team fortress should be in svn (nexball is iirc) once the code is fairly stable.
Get someone with commit access who has time to do such to commit them. So should the new gib code. Or, have pyschf ask for commit access himself.

tundramagi wrote:The detractions were: it will mess up everyone's work flow, you'll be forcing the rewriting of scripts (are you going to rewrite them?), it will take a long time for people to readjust... and just when they've done that another buerecratic idea will be ramed through everyone's skulls and hearts... and they'll have to relearn some new thing rather than doing work on the project itself.[/qoute]
What scripts exactly? The auto build from SVN for windows and Linux? The code is basically the same in these except the checkout process would differ slightly.

Is there something I'm missing here?

tundramagi wrote:Nexball and nexuiz team fortress should be in svn (nexball is iirc) once the code is fairly stable.

Point is, it's easier to maintain a local branch with git.

Get someone with commit access who has time to do such to commit them. So should the new gib code. Or, have pyschf ask for commit access himself.

He code isn't even written for 2.5.svn -- bad idea to merge into the main branch that everyone and their mother blindly checks out.

With git, developers can add locally and push when it's stable... this would alleviate the problem of checking out incomplete ideas.

With git, developers can add locally and push when it's stable... this would alleviate the problem of checking out incomplete ideas.

well, even with non-local branches, one possibly looses the single commits when merging in svn, whilst in git, you always have the single commits when merging. I saw some projects already loosing the ability to revert single changes cause they lost single commits on merges.

Well it's useless arguing with you Z, whatever you want you get: you're the emporor of nexuiz.

(even though you don't code stuff or make media for the game, somehow whatever you want you get)

I just wonder what the next buerocratic change demanded by you will be.

You keep trying to tweak useless things rather than editing the game itself.

Oh, so we're giving up on weighing the pros and cons of versioning systems and making personal attacks on me now?

Projects aren't just about code, and just because I haven't done QuakeC, doesn't mean I don't write code otherwise. Theory, organization, branding and marketing are all very important in order for a project to be successful.


But this thread isn't about bureaucracy, enough though you keep trying to bring it to that point. Can we get back to the point at hand now? Discussing the benefits and downfalls between the versioning systems? Thanks.

[-z-] wrote:Oh, so we're giving up on weighing the pros and cons of versioning systems and making personal attacks on me now?

Projects aren't just about code, and just because I haven't done QuakeC, doesn't mean I don't write code otherwise. Theory, organization, branding and marketing are all very important in order for a project to be successful.


But this thread isn't about bureaucracy, enough though you keep trying to bring it to that point. Can we get back to the point at hand now? Discussing the benefits and downfalls between the versioning systems? Thanks.

Hmm so we're "Discussing the benefits and downfalls between the versioning systems? Thanks."

Yet when I disagreed with your proposed change, you accused me of the following:

"Did you even read the thread? It's not a useless change and it was merely a suggestion with support about the benefits. divVerent took it as "omg people are trying to ruin the project again" when in reality, pyschf was just trying to make life easier for everyone with this suggestion. "

This is BULLSHIT!

You say that we are discussing "the downfalls and benefits between the versioning systems" and then when someone talks about some of the downfalls of changing to git (which you back) YOU MOTHER FUCKING ACCUSE THEM OF NOT READING THE DISCUSSION OR BEING "EMOTIONAL/NON LOGICAL" ("divVerent took it as "omg people are trying to ruin the project again"").

This is fucking BULLSHIT manipulative shenanagans that only retards that have no familiarity with power-play games fall for. (You keep changing the focus of discussion depending on if whoever you are responding to agrees/disagrees with you: nexuiz users keep falling for it because they're dumb... and they're not familiar with the way of the champions).

Since your claims of "discussing the benifits and downfalls of particular versioning systems" is clearly just a ploy to get YOUR championed versioning system adopted you should be ignored: you are pretending that this is an impartial and reasoned debate when anyone who disagrees with you gets snowballed as a "OMG" psyco, or someone who didn't even read the discussion, and anyone who agrees with you gets uplifted.

Oh and you deleted my request that the alt-gibs patch get into svn: since your the emporor you should beable to get this done.

Now on a related matter:

divVerent took it as "omg people are trying to ruin the project again" when in reality, pyschf was just trying to make life easier for everyone with this suggestion.

Given that div has been with this project since time immemorial, and knows the ins and outs of this project, and the development process, and the code, and how it's implemented, etc... and you do not... who are you to accuse him of being irrational?

You haven't committed or attempted to commit a drop of code or media to the project, so you don't know the overhead involved in doing so, nor the overhead involved in _changing_ the development process. You've only showed us screenshots of the autopackager even... no release.

Also who are you to accuse div0 of being an "omg" irrational person? Seriously, who are you? Just because he, who uses the damn thing you're trying to replace, disagrees forcefully with your pusch?

edit: Oh, you did release autopackager... but not a button to be added to netradiant so it can be auto-used!!

You haven't committed or attempted to commit a drop of code or media to the project,

I'm not sure where you think the new menu theme or logo came from. I'm pretty sure the websites count as media as well.

You've only showed us screenshots of the autopackager even... no release.

Actually there's a screencast on youtube and an updated version here. You would have known this if you spent less time trolling and more time reading.


Now please stop derailing this thread, you can pm me or talk to me on IRC.

[-z-] wrote:

You haven't committed or attempted to commit a drop of code or media to the project,

I'm not sure where you think the new menu theme or logo came from. I'm pretty sure the websites count as media as well.

I like your nexuiz theme. My friends like it too (they were like "woah, this is new"). It's like a mix between spacetech and rust/diesel/steampunk

You've only showed us screenshots of the autopackager even... no release.

Actually there's a screencast on youtube and an updated version here. You would have known this if you spent less time trolling and more time reading.


No please stop derailing this thread, you can bitch to me in pm or on IRC.

I've been working on a forwarding firewall for the last week... this is something that should take someone 13 min to set up, however ... not for me! It took me, with alot of help, one full week. That is seven days.

Could you get autopackager intergrated with netradiant (that is, a little button under the compile buttons that says "package"). This way newbies will be able to easily make the map, compile it, even use non-standard textures, and package it. (Note: packaging is the part of mapping I most hate aswell). This lowers the barrier to entry even more and gets us more mappers.

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.

[-z-] wrote: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

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.

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.

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

divVerent wrote: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.

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

some-guy wrote: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

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.

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