[haiku-development] Re: Git/Hg: some speed tests
- From: Ryan Leavengood <leavengood@xxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Wed, 4 May 2011 13:21:02 -0400
On Wed, May 4, 2011 at 12:56 PM, Sean Healy <jalopeura@xxxxxxxxxxx> wrote:
>
> Wait, are you saying that the DEFAULT on both git and hg is to overwrite
> local changes when updating from another branch? And that to get around
> that, you have to take several other steps? (That is, either committing your
> changes to your local branch or stashing them; in each case, at least two
> commands, IIRC.)
I don't know about hg, but git just refuses to pull with local
uncommitted changes, it won't just override local changes.
> So a tool that theoretically provides more flexibility in workflow is
> dictating a particular workflow? That seems really wrong-headed to me. The
> workflow that it's dictating (forcing users to commit changes that may not
> be ready to be committed) also seems wrong-headed.
One is never forced to pull changes while working. One would generally
only do that when there is some need to get newer code from remote, or
before pushing new local commits. Both hg and git allows saving local
changes (git stashes, hg shelves) that aren't yet ready to be
committed.
> It is my understanding that local branches are available to anyone who knows
> the address of the machine they're stored on. Is this true, or is there a
> way to mark your branches private so that nobody else can pull them? In that
> case, requiring a commit of a local branch isn't quite as wrong-headed,
> because it doesn't allow the world to get at changes that aren't ready.
I don't think most people will be exposing their local repos and
therefore their local branches to the world. Local branches are only
pushed to remote when the tool is told to do so (at least with git, hg
bookmarks may be different.) I don't think this is a real issue.
> Of course, it also requires you to save everything twice - once in the OS,
> once by committing to the local branch, which still seems like a waste of
> time. If nobody can get at it anyway, why should I commit it before I'm
> ready to let other people have access? If people can get at it, why should I
> commit it before I'm ready to let other people have access?
Local branches are mainly for locally organizing your work. Let's say
you start down a path of a big refactoring of some module. You can
create a local branch for that and work in there, while keeping master
in a working state. If an important bug comes in for master code, you
just check out master, make the change, commit it and push it up. You
can then check out your refactoring branch again and merge in the bug
fix commit from master.
I generally work in master for smaller changes and use a branch for
bigger or more risky changes. I'm doing this right now for some of my
Ruby contracting work actually.
> Or do additional branches not take up as much space as the local master
> branch created by cloning?
Rene pretty much addressed this, but to clarify all your git or hg
branches can be checked out in the same directory. Subversion branches
are stone age compared to those for most DVCS systems.
--
Regards,
Ryan
Other related posts:
