On Mon, 3 Nov 2014 13:53:51 -0800 (PST)
Anthony Berglas <aberg...@gmail.com> wrote:

> > 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'm not sure about the terminology here.  Any commit (no matter if it's
done locally as in a DVCS or synthesized on the server as in a CVCS)
is a snapshot of the continuous stream of changes.  A developer picks
a state to make such a snapshot using certain logic which lies in such
moot and non-technical terms like the project's policy and common sense.
I mean, no matter what's the difference between, say, your logic and
mine, we both use snapshots when we make 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.

OK, I think we're thinking about different levels of granularity here.
You *appear* as advocating the approach of working on a single feature
at a time.  That's fine and I'm all-pro about this (though in reality
this is not always--and even often--possible).  What I'm talking about
is that very rarely, when working on that single thing, you're able to
structure your changes in such a way that by the time you're ready to
commit, the changes done in the work tree represent exactly one commit.
Often, to make clean and understandable history, these changes *should
have been* done in several consequtive rounds--with each one resulting
in a commit.  But people simply do not work this way, and that's why
Git has fine-grained staging and rebasing: you are able to craft a
series of clean commits from an intertwingled set of changes
implemented in the work tree.

A good indicator of non-atomic commits are commit messages mentioning
the word "and" at least once, like "Implement Foo and also rename Bar to
Quux" (even worse is when a developer picks the major--as they
think--feature the commit implements and describes it solely).
What are separate changes, have to be separate commits.

Sure, that "have to be" is a policy.  A popular one, but surely not a
dogma.  Of course, you're free to use another policy.  The thing is,
with Subversion you can't have that policy (or you're condemned to do
lots of dances with `svn diff` and `patch` and `patch -R` with no
safety belts) and with Git you can have it at the cost of some training
as the tool allows you to do that.

> 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). 

Sure, absolutely agreed.

> > 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.

IMO, here exactly lies the problem with your interpretation which I'm
trying to address.  You have just thrown in more weight in the form of
two CVCSes popular in the enterprise world and again cast it as "basic
source control".  Like in "but these two tools work that way as well so
they have to do the right thing".  What I'm trying to tell you is that
there exist different "right things" which work best in different
scenarios.  Distributed VCS implement *an approach* to source control
management which might or might not work well for your requirements.
It's not necessary that what has been written to maintain the source
code of Linux will work equally OK for your project.  You might be
interested in reading [2] which, for me, was quite an eye-opener with
regards of certain "whys" of Git.  I mean, you could see whether that
maps onto your set of requirements or not.

> > 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.

Sure, but one might be as well carried too far away with this
philosophy.  Too often on this list we see people who for some reason
decide to adopt (or switch to) Git and then ask how to control who
checked out what, how to do file locking, how to implement per-file
access control and so on--things Git is weak at because they go against
the grain of DVCS.

> I think Git will be fine as long as one keeps it simple.

Contrary to what you might be thinking, Git is constantly receiving
usability improvements (1.6 was an especially noticeable improvement in
this regard) catered to mere mortals (as opposed to hard-core folks)
but I'm not sure your idea of bringing it closer to CVCS is really
doable as that would require Git to sacrifice some of its flexibility,
and those who need CVCS have a good choice of well-supported products.
Please consider reading [3] for more info on this as that guy (actually
one of those behind Subversion) put it very well.

May be one could create a wrapper around Git (akin to what Google did
to support Android development) which would bring Git closer to, say,
Fossil's model but I have not heard of any such attempts yet.

2. http://lwn.net/Articles/246381/
3. http://blog.red-bean.com/sussman/?p=79

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