>   git fetch origin 
>   git merge origin/master 

OK, maybe safer. 

For instance, you take for granted that everyone would use 
> `git commit -a` for a start and then may be try using "advanced" stuff. 
> But as one example, here at my $dayjob a bunch of webdevs hired about 
> 2-3 month ago used those partial staged commits all the time even before 
> they did their first `git merge` (actually, they used `git add --patch` 
> which provides for even more fine-grained staging).  Why?  Because we 
> here value clean history and atomic commits and so we focussed on that 
> first. 

How does using snapshots make for clean commits?  I would think it would 
make for broken builds when files are forgotten.  You should not be working 
on three different things at the same time.  Commit often, one step at a 
time.  Push most commits to minimize merge issues and allow restructures 
with minimal pain.

You do need to structure things properly.  For example, you might have a 
config file that has a standard version checked in but each developer 
tailors it.  In that case do not use the source control to manage the 
differences. Instead, each dev should have both the standard and tailored 
version in their working directory and then have some mechanism to chose 
which to use (e.g. and environment variable).  

> You seem to assume that the approach Subversion takes is a de-facto 
> standard and hence every other tool out there must strive to make 
> Subversion users feel at home. 

I use "Subversion" as a metaphore for basic source control.  Even MS team 
studio and perforce do the basic shared repository work.  I am not talking 
about Subversion's quirks.

> Also I think you might check out Fossil [1].  I'd say it's a DVCS with 
Thanks for the pointer.  But Git seems to have market share, which counts 
for a lot.  I think Git will be fine as long as one keeps it simple.


You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to