Right, I don’t use bash No, not all the packages are relevant, but most of them are really useful.

@git-config: just depends on what you prefer

Thanks for mentioning ‘git gc’ (I wasn’t aware of that) and ‘git gui’ (forgot to mention that )

regards,
-mika-

Just execute the following command line on your Debian system to install all relevant packages

Are all those packages really relevant? On the other hand git-completion (bash tab completion for git) seems to be missing; although if you use zsh, then you should have completion for git already…

Now let’s start with some general and basic configuration

Wouldn’t it be easier to just edit relevant file (~/.gitconfig) instead of using git-config which is indented for *tool* use?

Repack a git repository to minimize its disk usage

It is now enought to use ‘git gc’ or ‘git gc –prune’ (the latter on quescent repository). By the way, modern git requires repacking less and less.

You didn’t mention git commit tool, ‘git gui’ (and it’s wonderfull graphical blame ‘git gui blame’). qgit gas also some commit tool features.

@ak

Branching is totally overrated, and not only that, it encumbers software quality methods such as continuous integration (unless you immediately merge your branch back to the trunk, HEAD, whatever; or you do CI for every branch, which would be a complete waste of resources).

Private branches allow to create “perfect patch series”: feature introduced in small, self contained steps, and then send those series to public server as a unit. Centralized SCM don’t really allow private branches (where “private” might mean: worked on by some subgroup).

Sidenote: in git repository there is contrib/continuous with example cidaemon and post-receive hook, so when you push to central / publishing repository the code would be checked (and perhaps refused to be integrated).

As to difficulity of git: I’d rather like to think about it as steep learning curve (which usually follows steep power curve

* git is simple
* git is fast

i’ve deployed git across many different people with various vcs kownledge.

The requirements for any serious vcs is
* speed
* offline work (people on planes, country house or wherever)
* repo format not changeable by hostile party

so you svn fanboy, i guess you are doing mickey mouse stuff, as your crap that pretends to be better then cvs fails on any of this important points and don’t get me started with nonlinear development.

also mikas git post is meant for people already working and having fun to explore git corners. The git cheat sheet i give away to costums has no more then 10 lines.
90ties are over mate.

it’s definitely hard and difficult to understand all those commands and options, especially in the very beginning

Why does it need to be hard?

commercial software regarding version control isn’t a good example because developers just too often take the “easiest way to go”-approach instead of really learning their tools

I think that’s just generic blabla. We use Subversion here, and we support tens of customers every month with custom hotfixes, and it needs to be easy and simple, because otherwise with the huge amount of code being checked in we would definitely lose overview. You always presume that it’s so easy, you branch and make your changes, and merge, and so on, but it’s NOT. No matter what tool you use. Managing branches is always hard, unless you only work on Mickey-Mouse projects with less than 5 to 10 developers.

regarding the use cases: well, that’s *exactly* what many projects (no matter whether OS or closed source) need, most of them just don’t know that yet (that’s not a joke). As soon as you have non-linear development (or just base your work on someone else’ source), branching/rebase is something you really want to be able to use that way.

Don’t tell anyone what they want or don’t want. We evaluated a number of version control systems, and Subversion came out to be easy enough to use for everyone (you just can’t deploy a VCS that requires days of productivity-blocking introductions in a shop with e.g. more than 60 people, or in a single project with 10 developers or more), yet able support our complex custom hotfix and patch process, and being a multi-platform VCS (that’s the killer argument against git).

You don’t have any “waste of resources” when keeping up with trunk/head/tip/master/…. – check out the disk usage of git compared to subversion and be sure to never want to use subversion any more at all.

You don’t get it, do you? Hard disk is cheap. Really cheap. Other computing resources, such as CPU time, are not. My point remains valid: a proliferation of branching is a danger to quality assurance measures such as continuous integration (do you even know what that is?). And integration, at least in bigger projects, is one of the most crucial things during development. That’s why git works well for the Linux kernel, because what these people do is basically nothing but integrating a huge pile of patches from outside sources. But those advantages don’t apply to projects who do not have this type of work flow, i.e. virtually all other open source projects and commercial projects.

@ak: you’re a subversion-user, right? Well, you’re right in some aspects, but a few notes from my side:

* the “strange commands” are a good point where git is getting better from version to version (and yes: it’s definitely hard and difficult to understand all those commands and options, especially in the very beginning ). There where just too many git-… commands and AFAIK all of them are sorted out into ‘git command’ instead (which makes it at least a bit better). Many common tasks find their way into something like a new command and hopefully stuff like “delete a remote branch” will be become smoother and maybe more obvious as well. Oh, if you want to use a special option you can simply assign an alias anyway *SCNR*.

* commercial software regarding version control isn’t a good example because developers just too often take the “easiest way to go”-approach instead of really learning their tools (just look at the usual developer using his/her editor ), or just think of MS SourceSafe).

* regarding the use cases: well, that’s *exactly* what many projects (no matter whether OS or closed source) need, most of them just don’t know that yet (that’s not a joke). As soon as you have non-linear development (or just base your work on someone else’ source), branching/rebase is something you really want to be able to use that way. You don’t have any “waste of resources” when keeping up with trunk/head/tip/master/…. – check out the disk usage of git compared to subversion and be sure to never want to use subversion any more at all.

@Ted: thx!

regards,
-mika-

For example because when developing new feature on separate branch, or on ‘devel’/'next’ branch you have noticed a bug (or been send bug report), and you need to correct it on ‘maint’ branch (and then merge or cherry-pick it to ‘master’ and ‘next’).

* Why would I need branches at all to simply update my local changes with the latest revision from the remote repository?

You don’t need remote-tracking branches (you can pull directly into yuour local branch), but they are dead useful. They allow to see what was/is the state of other (fetched from) repository. Besides in new git they are hidden by default from user (one which uses: git clone, git remote add, git branch –track).

* Why would I want to apply all patches of a mailbox at once? Ever heard about thorough patch reviews?

Because you save _series of patches_ into _separate mailbox_? And why do you think you cannot do review of series of patches before applying? Besides, git-am has –interactive option…

All in all, you describe use cases that the average open-source project is never ever going to need, nor any other “big” software project. The use cases that you describe only have a real advantage for projects that mainly do integrational work with contributions from a lot of people, and whose men in charge trust each other – incidently, that exactly describes the work flow of the Linux kernel project, but it definitely doesn’t describe Joe Average’s open source project, nor does it describe the typical workflows of even the bigger open source projects, or software development projects in a commercial environment. Branching is totally overrated, and not only that, it encumbers software quality methods such as continuous integration (unless you immediately merge your branch back to the trunk, HEAD, whatever; or you do CI for every branch, which would be a complete waste of resources).

Btw. if you “git-svn clone” a fairly large project, you can drink a few cups of coffee in the meantime.