From: Junio C Hamano <junkio@cox.net>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: git@vger.kernel.org
Subject: Re: [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config
Date: Mon, 21 Nov 2005 14:26:38 -0800 [thread overview]
Message-ID: <7vpsotmych.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.63.0511211653420.2569@wbgn013.biozentrum.uni-wuerzburg.de> (Johannes Schindelin's message of "Mon, 21 Nov 2005 16:57:07 +0100 (CET)")
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 21 Nov 2005, Josef Weidendorfer wrote:
>
>> On Monday 21 November 2005 14:56, Johannes Schindelin wrote:
>> > With this patch, git automatically extracts the information from
>> > .git/branches and .git/remotes, puts it into .git/config, and renames the
>> > directories to .git/branches.old and .git/remotes.old, respectively.
>>
>> Please... don't trash .git/branches.
>> This is about Cogito, not about Git. You will render every repository cloned
>> with Cogito useless, as it expects a per-branch configuration with the same
>> name as heads.
>>
> I was aware that .git/branches was introduced by Pasky, but as it is
> handled in git-parse-remote.sh, I thought that it may be a bit more
> general than just cogito.
What Josef said is correct in that I was not aware of the fact
that Cogito branches/ are *per-branch* configuration when I did
parse-remote. remotes/ are deliberately *per-remote*
configuration, because it is more efficient when you are
downloading more than one refs from the same remote over a
git-aware protocol. Arguably, it is optimizing for the wrong
case, because it may well be a minority case to keep track of
more than one remote head. I dunno.
I am not sure if it is a good idea to automatically convert what
is stored in .git/branches to .git/remotes (or the equivalent of
the latter in .git/config), but if somebody wanted to do it, the
right thing would be:
- grab the URL without optional fragment '#rembranch' part from
all branches/* file;
- group the ones that fetch from the same URL into one
remotes/$file (what to call that file is very debatable
because the original branches/* is in different namespace and
we cannot tell what the user wants to call the remote),
giving appropriate head mapping. branches/$branch file with
the fragment part '#$rembranch' translates to "Pull:
$rembranch:$branch".
next prev parent reply other threads:[~2005-11-21 22:26 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-11-21 13:56 [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config Johannes Schindelin
2005-11-21 15:44 ` Josef Weidendorfer
2005-11-21 15:57 ` Johannes Schindelin
2005-11-21 16:25 ` Josef Weidendorfer
2005-11-21 16:34 ` Andreas Ericsson
2005-11-21 22:26 ` Junio C Hamano [this message]
2005-11-27 12:59 ` Petr Baudis
2005-11-28 1:52 ` Johannes Schindelin
2005-11-28 6:22 ` Junio C Hamano
2005-11-28 8:43 ` Andreas Ericsson
2005-11-28 9:14 ` Junio C Hamano
2005-11-28 12:59 ` Josef Weidendorfer
2005-11-28 13:11 ` Andreas Ericsson
2005-11-28 14:32 ` Generic configuration plumbing (Was: Re: [RFC 2/2] Automatically transform...) Josef Weidendorfer
2005-11-28 15:26 ` Johannes Schindelin
2005-11-28 13:48 ` [RFC 2/2] Automatically transform .git/{branches,remotes} into .git/config Petr Baudis
2005-11-28 15:03 ` Josef Weidendorfer
2005-11-29 6:04 ` Junio C Hamano
2005-11-28 16:29 ` Johannes Schindelin
2005-11-28 13:59 ` Petr Baudis
2005-11-28 16:33 ` Johannes Schindelin
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=7vpsotmych.fsf@assigned-by-dhcp.cox.net \
--to=junkio@cox.net \
--cc=Johannes.Schindelin@gmx.de \
--cc=git@vger.kernel.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.