Re: Newbie grief

[Ted Ts'o <tytso@mit.edu>]

On Thu, May 03, 2012 at 11:26:20AM -0700, Rich Pixley wrote:
> 
> In other systems, the branches are tracked identically.  You see
> master, I see master.  The only differences we see are any changes
> I've created that haven't yet been pushed to you or vice verse.  But
> since git can't handle collisions in the repository the way other
> systems do, it's forced to use the geographic branch scheme for
> non-bare repositories.  Bare repositories don't have the collision
> between repository branch and working directory copy in git, so with
> bare repositories, git can use the identical branch scheme,
> (although it still refuses colliding pushes).

I'm still not sure I understand your development workflow.  It seems
like you are trying to publish multiple branches across to multiple
repositories on different machines, so they are visible to different
developers?  What are all of these branches used for, and why are you
doing things this way?  (I'm not implying that the reason you have for
doing this way is silly or stupid, just that I don't understand it and
I don't understand why you feel you need to do things this way.)

> What I don't understand is why git chose this less functional
> architecture over the previously existing practice that doesn't have
> these limitations, although "because that's what BitKeeper did"
> might be the sad answer.

It's mainly because many git users, including many kernel developers
have a set of development workflows which is well suited for how git
is set up to work.  So git was very much shaped by the development
workflows of the early git users --- and it goes the other way, too
--- new git features will sometimes cause our development practices
and workflow to evolve.

So I may have a number of different branches that I'm working on, but
in general they stay local to my repository until they are ready to be
merged to mainline.  If patches need to be reviewed, they either get
sent via e-mail to the appropriate mailing list, and the review
happens via e-mail, or internally at $WORK, we use Gerrit and we push
the change to gerrit where the patches are kept and trackked inside
Gerrit, alongside the comments as the patch goes through the review
process.  (I suspect you are pushing patches out to the repository for
review as the patches are getting developed and refined, but I don't
know that for sure, since you haven't talked about why you want the
particular SCM features that you've been asking for.)

Once a patch is fully baked, it goes into a maintainer's repository
where it gets pulled into a higher-level maintainer's repository.  So
in practice a developer's repository has very few branches that he or
she needs to export to the outside world, at least as I and other
Linux kernel developers typically tend to use git.

It's obvious you want to use your DSCM in a different way, and it's
not that any particular workflow is right or wrong.  But obviously,
some tools are a better match for certain workflows as compared to
other workflows.

Regards,

					- Ted