> Junio C Hamano <junkio@xxxxxxx> writes:
>
> If you wanted to do _ANY_ development on top of it (even if that
> was just to set '#define DEBUG 1'), however, you would need to
> branch off of it, say "git checkout -b my-next next", so the
> above inconvenience is arguably very minor. On the other hand,
> the downside are the pollution of your own heads/ namespace
> (having your forked branch and remote tracking branch means
> heads/ would have next and pu from me and my-next and my-pu you
> work on), and some people are not as careful and disciplined as
> you are and have made mistakes of committing their own changes
> while on such remote tracking branches (you can call the latter
> part "newbie protection"). The next 'git fetch', especially
> when it was forced _and_ was done while on 'next', was rather
> unpleasant. Of course, discipined people like you and me would
> never do that, but we are not the only two people in the
> universe ;-).
LOL, I love your sense of humor here! :-)
> The issue of "checking the tracking branch out to look-and-see"
> is going to be addressed by the upcoming detached HEAD support,
> so personally I do not think it will be a huge problem. You
> would have to say "git checkout origin/next" for it with the new
> layout.
I guess, what I want is still to be able to "see" remotes/
when I do "git branch".
Sometimes I don't care to check out the remote branch, I just
want to rev-list it. Sometimes I do check it out so I can
take a look and when I pull, I do the required reset, but
as you said above :-) this requires discipline.
And of course if I want to do my own development, I branch
off, as I've done with "next", and never forget to "git-pull . next"
after I pull from you. Again this requires discipline.
But what I appreciate in git, is this discipline. The fact that
I'm in control of it and that I have to do it -- keeps my mind sharp.
I really think that the line separating porcelains from git
should be drawn at some point.
I think that this "automatic merge/newbie protection" policy,
should've been well suited to porcelains as opposed to
git.
> Another thing the separate remote gives us is to make it easier
> to interact with more than one remote, by having a new directory
> next to remotes/origin/ directory. If you used the traditional
> layout, your heads/ namespace would explode because you would
> have to have something like:
>
> heads/origin -- from linux-2.6's master
> heads/origin-libata -- from jgarzik libata ALL
> heads/origin-sii-lbt -- from jgarzik libata sii-lbt
> ...
>
> in a flat namespace intermixed with your own development
> branches, instead of:
>
> remotes/origin/master -- from linux-2.6's master
> remotes/libata/ALL
> remotes/libata/sii-lbt
> ...
>
> grouped together by where they come from (and they cannot
> possibly be mucked around directly thanks to being in remotes/
> hierarchy), separated from any of your own development branches
> that are in heads/.
I don't mind this at all, as long as I get to "see" it, when
I do normal git operations, like "git branch".
So maybe we should take it one step at a time and first
implement that, still exposing it to "git branch" and then
if porcelains want to establish a policy on top of this,
that's fine. But low-level git should not hide this from me.
Luben
> Also, this is only about the default layout clone makes, and the
> refs are not packed, so you can easily move remotes/origin/*
> (except 'HEAD') to heads/ immediately after making a clone and
> set up remotes.*.fetch configuration to match the traditional
> layout if that is what you find more convenient. The operation
I do find that more convenient, but wouldn't like to have
to do that, nor to have a script that does it for me to have
to do it after I clone.
It would be most convenient when this per-repo layout is
implemented, yet I get to see this when I do "git-branch".
I guess, most convenent, yet "newbie-protection" would be
to disallow any commits to remotes/* in this way... I'd opt
for that wholeheartedly.
Luben
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html