Re: Newbie grief

From: Ted Ts'o <tytso@mit.edu>
Date: May 3, 2012, 19:33 UTC
Message-ID: <20120503193353.GI18002@thunk.org>
In-Reply-To: <4FA2CDCC.6020303@palm.com>

On Thu, May 03, 2012 at 11:26:20AM -0700, Rich Pixley wrote:

Show 10 quoted lines

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