Advanced Git tips (slides) | Hacker News Reader

Advanced Git tips (slides)

git-tips.heroku.com

It is / can be surprising who on your team will have the most problems on a Git from SVN migration. Sometimes ol' CVS/SVN warhorses have too much to unlearn, sometimes simple devs who never bothered to progress beyond the minimal clicks with SVN/IDE to get code up and down discover the true Qi of source control management as they discover git's capabilities.

One nice thing about git vs. svn is when you reach enough mastery you can make that repo dance to your tune. At some point you and git are one and working together. SVN was always some kind of imposing, opposing force; one that I had to fool into doing my desire.

One clueless contractor could put your SVN repo into hell-and-gone. With git I told the team, "don't worry, go for it; unless you do something really strange, there's nothing you can do that I can't recover from."

These slides are worthless without the talk. Instead go download his excellent book (or buy it) from http://progit.org

I agree that most of the slides would require further explanation but I still found a bunch of commands I've never heard of and actually could make use of, eg git bundle and git rerere.

So it's not totally worthless.

Although not totally worthless, it is nearly so. It is ~350 slides, most with a single word. To find those commands you've never heard of, you have to wade through a deluge of meaningless, when out-of-context, crap. Most readers, like me, probably said "not worth the time" after about 20 slides.

Without the talk, you still get the progit.org at slide 8 or 9, so I guess even by your standards, there is some value here!

here is me giving more or less this same talk: http://chacon.blip.tv/file/4213359/

I'd love to learn a bit more about git, but this is pretty worthless as just the slides.

These ones are advanced tips. I'll send you more beginner resources later on.

Advanced tips is what I was looking for. I can see it being some standalone material, perhaps I shouldn't just be browsing over it.

am i being an idiot? I can't see a way to change slides :s

Click inside the content, then use the keyboard arrow keys to move around.

For someone looking only at the tips, this is sadly very unfriendly. Basically, you need to click or press more than 300 times on your keyboard to go through. This cannot be used as a reference even so some stuff were interesting (I gave up at slide 84). I welcome a reformatting as a cheat sheet by a courageous reader :)

You can find some of the tips here: http://mislav.uniqpath.com/2010/07/git-tips

This is a presentation, made using the showoff gem. Seen through that light, it's pretty solid.

There should be at least a noscript version with manual navigation if one does not want to include it in the regular.

We recently switched from SVN to Git and the transition has been painful - last week there has been at least one issue pr. day that has stopped work and that needed to be addressed. Personally, I have used Git before via github and it has worked well (tho' my usage was mostly doing small updates, no branches, no merges etc.)

My current impression of Git is that it's very powerful, but too low level and not that user friendly. I am currently evaluating Mercurial, since it seems to be easier to use and more user friendly.

Anybody have experiences working with both Git and Mercurial with a team of 5-10 people?

I've had similar experiences. Git has great potential, but the tools seem very immature, and basic things I took for granted with Subversion are huge pita's with Git. And it seems like all that needs to happen is a really solid toolkit to simplify those tasks.

Could you please elaborate on that? What basic things did you have problems with?

I've had the opposite experience. I've generally found git a joy to use and I don't miss SVN in the slightest. I highly recommend reading Chacon's Pro Git book. As really understanding how Git works internally helps in using it a lot.

Which issues did you have exactly? I'm asking because my team members want to switch to Git after having to suffer through my praising git for long enough and I'd like to know which traps to avoid.

My personal switch from SVN to Git was rather painless but that's probably because I "only" used git-svn and at first used Git pretty much like I used SVN and then step by step explored the possibilities offered by Git like local branches etc. pp.

That's what I'd recommend to anyone making the switch, first try it out with git-svn, don't use every new feature at once.

DVCS is a completely different paradigm, it requires some time to wrap your head around. :)

For me the biggest problem was ending up with a lot of heads. I guess this happens when you go back to a previous commit and in-advertently starting checking in stuff - In SVN, this is prevented.

I dont exactly remember how I handled this the last time around, but I think some rebase-fu was needed

Git and Mercurial are pretty similar, but I must say that I don't like the Mercurial branching model. It forces me to have a repository for every topic branch when I'm contributing to an open source project. You can read more about this here:

[1] http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...

[2] http://hgbook.red-bean.com/read/managing-releases-and-branch...

> It forces me to have a repository for every topic branch when I'm contributing to an open source project.

You might want to read the first link you gave, I think.

What do you mean? I read that guide almost an year ago and decided that branching with clones is the best option for me.

Yet you're complaining about that option and saying that it doesn't support the branching model as git. It does support it, but you rejected it.

Here's my current setup: I have 2 clones/repositories of Satchmo. [1] is for bug fixing and [2] for translations. I've asked for a better solution on the #mercurial channel and no one has offered it to me.

If you have a better idea that's similar to git[3] (1 repo), I'm waiting for it. Until then I'll complain about what Mercurial is offering me, just like Groxx and cdavid (see above).

[1] http://bitbucket.org/ciupicri/satchmo

[2] http://bitbucket.org/ciupicri/satchmo-l10n-ro

[3] http://github.com/ciupicri/cobbler/tree/master-pagination-bu...

Maybe I'm missing some nuance in what you're asking for, but in mercurial, you should be able to just create a named branch to get the same effect:

  hg branch bug-fixes
  hg commit -m "creating bug fix branch"
  hg update default
  hg branch translations
  hg commit -m "creating translations branch"

then you can just "hg update <branchname>" to do an in place switching between branches (just like git checkout).

I wouldn't use 2 separate repositories for that, just one.

We've got multiple named branches at work (I also use bookmarks with development branches fairly heavily, but that's a slightly different topic).

Wouldn't these branches be permanent? They might be fine for translations, but I doubt upstream would accept one for a bug fix.

As for bookmarks, if I understand this correctly, I have to convince upstream to use them.

With git I can create a branch in my repository and upstream can pull my changes in whatever branch it wishes too. I don't need to convince anyone to do anything else, besides accepting my patches.

Sorry, I misunderstood your use case for the bug-fix branch. Yes, you likely wouldn't want a named branch for that.

I use local bookmarks for this. It lets you think of it as a branch locally (it's really a floating tag), but doesn't (automatically) get pushed out.

I can't stand Mercurial branches. They make no sense once you've tasted Git's.

Heck, Mercurial users / developers / websites as much as admit it sucks. The most-recommended way to branch that I've seen is to clone the remote, never develop on that copy (a "pristine" clone), and clone that repo to make your branches, pushing back into your pristine when you're ready to upload.

Git? Just branch and code.

I concur to that. I find Hg branching model messy: there are clones, named branches, bookmarks and anonymous branches. They all have different features in term of how you can share them, etc... Also, I find comparing branches (through log, diff, etc...) a bit painful, especially because of inconsistencies between naming in hg - git naming is less user friendly, but much more consistent.

IOW, Git complexity comes from a f*cked-up UI, but hg simplicity is only superficial. Any semi-advanced usage in hg requires queues, a lot of plugins, etc... whereas git supports all that out of the box. Some simplicity in hg is also seriously broken - the "simple" version naming is a very bad idea in DVCS. Inevitably, different people will refer to the same revision (r1234) which is in fact a different revision because they are relative to different repositories.

Merging is also not that great in hg: I really miss git index when I need to resolve conflict. But I have a strong dislike for kdiff3 and that sort of tools.

I sort of like that revision naming, actually. As long as nobody does that, it does simplify things at times. Though no more than bookmarks do, and they can be descriptive instead of iterative.

The issue is exactly that people like it - everyone prefers a simple number to an hash, even if your name is Linus Torvald. But in DVCS, it is impossible to keep this naming consistent, and the cases where they work and don't may become quite subtle.

? you can "just branch and code" in mercurial too. I do it all the time.

I'm not sure where you're getting your info. Sounds like you might be still thinking that the FUD from 2008 that the only way to branch in mercurial is to clone a repo is actually true.

Check out the links in the post you replied to for more info.

With clones: article seems confused as to whether these are local clones or multiple remote repos[1]. If multiple remote repos: != branching, and horrendously wasteful. If local: almost exactly what I described, though they're making a repo for every existing branch; many other suggestions online suggest maintaining a "pristine", and it then becomes what I mentioned. And read the disadvantages section, it's pretty large. And this is one of the most-described means of branching; duplicating the repository because named branches are such a PITA.

Bookmarks: local only, no info ever reaches the server - ie, no label on a separate branch, it's just yet another anonymous branch.

Named branches: new head even when merged and closed, default push pushes all branches, so very difficult to use locally only if you have more than one remote branch (say, prod, qa, testing, dev. You now have to "hg push -b prod qa testing dev" just to prevent pushing your local branches. Or is it a separate push for each branch? I forget. And what if there were 20? 2000?). If you allow new remote heads, suddenly everyone will get tons of branches as you add more developers, name collisions / too many useful ones used up long ago (mybranch12a7c9?) - this is desirable how?

Anonymous: an artifact of any concurrent version control software, not a feature.

[1]: 2nd paragraph of: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...

edit: summary: Git = friendly to multiple developers. Such as effectively every business environment. Mercurial = friendly to a single developer (in that case, yes, it's admittedly much easier), as long as you always push all branches.

Clones: I have seen a number of places talk about using separate repositories for branches in mercurial, but that's not how many people work these days. Just as with git, there are less efficient ways to do things.

In the article you linked to, the author is recommending against using separate cloned repositories, I agree with him.

Bookmarks: As of mercurial 1.6, bookmarks aren't local only and can be pushed.

Named branches: you don't have to push everything, just do

  hg push -r .

and it will only push the current revision, and any unpushed parent revisions. The linked article mentions this and talks about aliasing it to "hg nudge". If you do that, you have the same behavior as git.

I think git is a solid tool and that it can work well for many teams. I also know from personal experience at 3 different jobs that mercurial can work effectively for teams.

"hg push -r ." is new to me, though it makes some sense. How did you find that one out? "." is hardly a revision; it's a repository in every other command, from what I can remember (haven't used it since I initially learned mercurial).

And I'll have to see how well bookmarks function - not sure what my work repo runs.

"-r" is the revision flag for the revision to push out. "." is a shortcut that just means "the revision that the working directory is at" (same as hg identify would show).

My team of 5 switched to git this year. Hust yesterday (I'm not making this up) one of my team members thanked me for pushing the change. Develoment for us has gone much more quickly now than before and we have had very few issues.

One thing that is essential to a good transition is to have a strong evangelist who is willing to address problems, educate people and investigate when something happens that you don't understand.

ProTip: #git on freenode is a great resource if you find yourself out of your depth.

We use git to manage the codebase of two apps that have about 15 people working on each. Every team or project branches from master at the start of an iteration and works off that branch until the end of the iteration then merges/rebases back onto the master branch.

Then we we tag and branch at the end of an iteration to push code live.

Works very well for us and seems a lot less painful than the frontend guys using SVN.

  > We recently switched from SVN to Git

Part of the problem is that git is not similar to SVN in the way that SVN was similar to CVS. People have to give up their old paradigm of thinking, and it certainly helps if at least one person in your group is a git guru (or at least someone that is willing to investigate/fix problems without feeling like it is a chore) otherwise you will end up in the situation where everyone feels like the whole conversion process/idea was just a chore. If there is someone that makes themselves the 'go to guy/girl' for git issues it alleviates the rest of the group from thinking about git issues all of the time.

I have been using bzr with a team of 4 for some time now. Moved from ClearCase UCM and haven't looked back. :-) As most people had experience with cvs and svn the command set was easy to pick up. We just needed to put together a policy with integration branch and user specific product branches. It was a unix only install so standard unix groups/perms were used for these directory hierarchies.

There is little technical reason to choose Git over Mercurial or vice versa. Their usage is extremely similar. Git exposes a few more internals, and lets you fix mistakes more easily. For sharing branches which are incomplete, git's `rebase -i` is also somewhat superior to mercurial queues.

Overall, I've found git to be marginally better than hg.

The real killer feature that git has is that git talks to github and svn. Mercurial only talks to bitbucket (sorry guys, network effects are important and github won).

Mercurial also talks with git (http://hg-git.github.com/) so you can use it with github if you want. This was actually created by Scott Chacon, the guy who wrote the subject of the OP.

I think it's worth giving both git and hg a try to see which fits your head better. Mercurial feels better to me and there are quite a few people in many communities (including most of the python community).

The genius thing about git-svn is not that it only "talks" to svn: using git-svn (you could say subversively) converts your repo to git. One day, when somebody suggests dumping svn for git, you can skip the "but how do we preserve all that history if we switch" conversation, because it's already done.

Mercurial's hgsubversion works just like this as well: http://mercurial.aragost.com/kick-start/hgsubversion.html

What issues are you having? I converted my company over a year ago to Git from CVS. The main problem we still have are people that either refuse to spend the time to learn Git properly or quasi-technical people who just aren't capable of it. For the former group, some people are just lazy and try and take the easy way out. Or, they're stubborn and think they can get by with a little knowledge.

I've found, to a person, that once they put in the work and know how to use it, it's a rewarding and fun experience to use Git. It's not easy, though.

I managed to talk my company into git as well - although our route is different: We literally had no (official, my projects always ended up using a private repository of some sorts) source control. At all.

So, after fighting the battle for far too long I'm now rolling out git/gitorious right now, with lots of early adopters using that already, on my (properly backed up..) test machine.

The biggest issue that I've seen so far are mostly general "I just don't get scm" things (no commit message or a useless one. Working around rules by just entering space if I try to prohibit this).

The only git specific issue that come up is that the people don't understand that each user's clone/working copy is a separate branch of the origin already. If 2 guys clone from the "server", you now have 2 branches of origin/master. pull by default merges remote and local branch, which leads to a huuuuuge number of completely useless merge commands in the histories of some projects. That makes the history far less useful in my book and all visualizers now show you a large numbers of branches that you don't care about.

You can work around that by educating users to, for example, using git pull --rebase - but that is a concept that needs quite some understanding first.

Apart from the thing above the introduction seems to work fine so far and people with different background (VSS.., cvs/svn mostly) are using it without (real, major) problems.

And I'm glad that we finally will have an official scm server sometime this month, after only ~5 years of nagging. Ah, it's the small things that make me happy these days...

You can config Git so that it always uses rebase when pulling: git config branch.autosetuprebase always

To override this simply use --no-rebase.

I'd just like to add that Scott was by far the best speaker I saw at RailsConf '09.

A lot of great hackers/founders are dry and boring presenters. They could learn a lot from watching him.

These types of presentations do not work on an iPhone :(

Reply on news.ycombinator.com