These slides are worthless without the talk. Instead go download his excellent book (or buy it) from http://progit.org
here is me giving more or less this same talk: http://chacon.blip.tv/file/4213359/
Advanced Git tips (slides)
41–50 of 53 posts
Re: Advanced Git tips (slides)
#42Earlier quoted context omitted.
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/ciupic…
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"
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).
Re: Advanced Git tips (slides)
#43Earlier quoted context omitted.
? 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 la…
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 .
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.
Re: Advanced Git tips (slides)
#44Earlier quoted context omitted.
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/ciupic…
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 " to do an in place switching between branches (just like git checkout). I wouldn't use 2 separate…
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.
Re: Advanced Git tips (slides)
#45Earlier quoted context omitted.
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 " to do an in place switching between branches (just like git checkout). I wouldn't use 2 separate…
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.
Re: Advanced Git tips (slides)
#46Earlier quoted context omitted.
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 la…
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 b…
"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.
Re: Advanced Git tips (slides)
#47I'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.
Re: Advanced Git tips (slides)
#48We 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…
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...
Re: Advanced Git tips (slides)
#49We 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…
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 see…
You can config Git so that it always uses rebase when pulling:
git config branch.autosetuprebase always
To override this simply use --no-rebase.
Re: Advanced Git tips (slides)
#50Earlier quoted context omitted.
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…
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.