Re: Newbie grief
- From
- Stephen Bash <bash@genarts.com>
- Date
- May 4, 2012, 14:59 UTC
- Message-ID
- <6211a2de-a545-41c3-9fb5-e7e3033b45f4@mail>
- In-Reply-To
- <4FA3E31A.6060606@op5.se>
----- Original Message -----
Show 22 quoted lines
> From: "Andreas Ericsson" <ae@op5.se> > Sent: Friday, May 4, 2012 10:09:30 AM > Subject: Re: Newbie grief > > On 05/03/2012 08:58 PM, Rich Pixley wrote: > > On 5/1/12 16:30 , Felipe Contreras wrote: > > > Show all the hg commands of what you are trying to do, and we can > > > show you how you can achieve the same in git, but much more > > > easily. > > > > hg init foo > > for i in `yes | head -4000`; do (set -x ; d=`date +%s.%N` ; hg > > clone foo foo-$d; (cd foo-$d && date > bar && hg add bar && hg ci > > -m $d)); done > > for i in foo-*; do (set -x ; (cd $i && hg push -f)); done > > ... snip ... > > The hg recipe creates 4000 branches which I for some reason can't > find the names of so I have no idea how to interact with them. The > git recipe names them explicitly to foo-$i/master in the foo/ repo, > since git doesn't allow pushing of commits without a ref.
If my hg-foo isn't too out of date... The hg recipe creates 4000 "heads" on a single branch, rather than 4000 branches (see the 'hg heads' command). This is basically the point Rich is arguing I believe. hg allows for multiple tip commits all with the same branch name (IMO this is important because hg branch names are permanently recorded in their version of the commit object).
This is a *fundamental* difference in the implementation of the two tools (and causes confusion because now "branch" has two slightly different meanings). However, IMHO, philosophically it all boils down to the same thing: development has forked and has to be merged. Whether that fork has a name or not is up to the tool. In hg it doesn't *have* to have a name (multiple heads per branch), in git it does (single head per branch).
I personally find Git's enforcement of naming a good thing: either the change I just made should be incorporated into the original branch, or there is a reason for it to stay separate. In the latter case I should name it in a meaningful way so I (and other team members) remember why it is being kept separate (similar to why we use meaningful variable names). In the former, I fetch and then merge or rebase as appropriate before pushing back upstream.
HTH, Stephen