From: Pavel Roskin <proski@gnu.org>
To: Josef Weidendorfer <Josef.Weidendorfer@gmx.de>
Cc: Petr Baudis <pasky@suse.cz>, git@vger.kernel.org
Subject: Re: [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD
Date: Thu, 10 Nov 2005 23:53:04 -0500 [thread overview]
Message-ID: <1131684784.31172.16.camel@dv> (raw)
In-Reply-To: <200511110213.54846.Josef.Weidendorfer@gmx.de>
On Fri, 2005-11-11 at 02:13 +0100, Josef Weidendorfer wrote:
> > Correct. But if it's a concern, I think we could make some
> > improvements. Following approaches could be tried (starting from top,
> > using following steps as a fallback):
> >
> > 1) Use recorded branch, i.e. the branch name that was used in cg-clone.
>
> This is the "#..." part in .git/branches/origin, and it is already used.
I'm not sure if we understand each other, but "recorded" refers to
automatically determined branch name. If cg-clone can determine the
branch name, that name should be saved and used for updates.
Whether the branch name is saved in .git/branches/ using hash notation
(old style) or in .git/remotes/ (new style) is irrelevant.
If cg-clone cannot determine the branch name, we may either support it,
or revert to "master". I'm ambivalent about that. Probably reverting
to "master" is better to simplify the code. On the other hand, I can
imagine public repositories without the "master" branch.
> I have nothing against using HEAD for cloning, but the branch name should
> be recorded, such that cg-pull always fetches from the same branch.
To use HEAD, we'll need to port git from Cygwin, since readlink doesn't
work over http.
> I think 1) is enough if we add the detected branch name in the #... part
> in .git/branches/origin at cg-clone time.
I agree that the branch name should be saved explicitly using already
supported notation (if that's what you mean).
> And "detectable" covers the local case, which was my concern here [*1*]
>
> Josef
>
> [*1*] after being told about the "stable HEAD" property of public repositories,
> which is correct. I am not even sure that a HEAD makes sense
> in public repositories: in my opinion HEAD has something to do with checked out
> files, and a public repository usually does not have these. But perhaps
> that's only me...
That's why I mentioned the idea of having a separate file to indicate
the default branch for export.
--
Regards,
Pavel Roskin
next prev parent reply other threads:[~2005-11-11 4:53 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-23 21:33 [PATCH] cg-pull to stop treating "master" specially, fix fetch_local for .git/HEAD Pavel Roskin
2005-11-10 19:24 ` Petr Baudis
2005-11-10 20:11 ` Pavel Roskin
2005-11-10 23:26 ` Josef Weidendorfer
2005-11-10 23:40 ` Petr Baudis
2005-11-10 23:56 ` Josef Weidendorfer
2005-11-11 0:09 ` Petr Baudis
2005-11-11 0:14 ` Pavel Roskin
2005-11-11 1:13 ` Josef Weidendorfer
2005-11-11 4:53 ` Pavel Roskin [this message]
2005-11-11 14:22 ` Josef Weidendorfer
2005-11-11 15:26 ` Pavel Roskin
2005-11-11 16:10 ` Josef Weidendorfer
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=1131684784.31172.16.camel@dv \
--to=proski@gnu.org \
--cc=Josef.Weidendorfer@gmx.de \
--cc=git@vger.kernel.org \
--cc=pasky@suse.cz \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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;
as well as URLs for NNTP newsgroup(s).