From: Luben Tuikov <ltuikov@yahoo•com>
To: Junio C Hamano <junkio@cox•net>
Cc: git@vger•kernel.org
Subject: Re: New way of tracking remote branches -- question
Date: Mon, 8 Jan 2007 23:45:09 -0800 (PST) [thread overview]
Message-ID: <524590.40333.qm@web31802.mail.mud.yahoo.com> (raw)
In-Reply-To: <7v8xghariv.fsf@assigned-by-dhcp.cox.net>
> Junio C Hamano <junkio@cox•net> 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
next prev parent reply other threads:[~2007-01-09 7:45 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-05 23:02 New way of tracking remote branches -- question Luben Tuikov
2007-01-05 23:17 ` Junio C Hamano
2007-01-05 23:39 ` Junio C Hamano
2007-01-06 0:39 ` Luben Tuikov
2007-01-06 0:16 ` Luben Tuikov
2007-01-05 23:50 ` Junio C Hamano
2007-01-06 1:11 ` Junio C Hamano
2007-01-06 2:11 ` Steven Grimm
2007-01-06 14:10 ` Theodore Tso
2007-01-09 7:45 ` Luben Tuikov [this message]
2007-01-09 8:28 ` Junio C Hamano
2007-01-09 8:41 ` Luben Tuikov
2007-01-09 8:57 ` Martin Langhoff
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=524590.40333.qm@web31802.mail.mud.yahoo.com \
--to=ltuikov@yahoo$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=junkio@cox$(echo .)net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox