Why using git would be awesome for nexuiz

[[-z-]]

Only you guys always come with stupid demands.

nice one

[alpha]

And nobody wants to use SUCH a system then.

Damn straight.

[Psychcf]

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.

[C167]

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.

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


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.

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

[Alien]

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

[parasti]

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.

[tundramagi]

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.

[tundramagi]

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.

[[-z-]]

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

[C167]

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