git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Petr Baudis <pasky@suse.cz>
To: Jeff King <peff@peff.net>
Cc: Alex Riesen <raa.lkml@gmail.com>, Junio C Hamano <junkio@cox.net>,
	Andy Parkins <andyparkins@gmail.com>,
	git@vger.kernel.org
Subject: Re: [3/4] What's not in 1.5.2 (new topics)
Date: Thu, 17 May 2007 19:30:05 +0200	[thread overview]
Message-ID: <20070517173005.GS4489@pasky.or.cz> (raw)
In-Reply-To: <20070517162542.GA28501@coredump.intra.peff.net>

On Thu, May 17, 2007 at 06:25:42PM CEST, Jeff King wrote:
> However, I think we _must_ have an override mechanism, since I don't
> necessarily use the same URLs that you do. I propose that such overrides
> should go into the local repo config. The only difference between what I
> have proposed and what Junio mentioned is that I would base the config
> override key on the directory name, not the URL. This means that if
> upstream changes their pointer to the URL, yours will change with it
> _unless you have an override_. With Junio's, their change of URL will
> override your change (since the key will no longer match your config).
> 
> How do you propose to handle overrides?

I think Junio's URL keying works fine. Their change of URL will override
your change, but that is bad thing only when the old upstream's URL
changed, but the upstream stays the same. Then either the problem is
clearly visible or it will result only in somewhat suboptimal behaviour.

OTOH, if the _upstream_ changed and your override scheme is at work, you
won't notice at all and simply will continue to use the same old
upstream.

> > "kernel/" has _no_ meaning. Only a (treeid,"kernel/") pair has meaning,
> > nothing less - a particular tree contains a submodule in given subtree.
> > Different trees can have different submodules in different subtrees.
> 
> Right. In my proposal (unlike Alex's), it _is_ tied to the tree, since
> that tree has a particular .gitmodules. But I also think you should be
> able to override the submodule URL for kernel/ _for all time_ if you
> want.

But again - "kernel/" means nothing, only "kernel/ in tree X". kernel/
might point to linux-2.4 in older trees, linux-2.6 in newer trees, -mm
in the experimental branch and freebsd tree in the weirdo branch. Such
an override is _never_ going to work in the general situation, only when
"kernel/" always in all commits on all branches points to the same
single project. (You can work that around by at least making the setting
branch-specific, but that still doens't take into account the history,
and then newly created branches won't have the override you want, etc.)

-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Ever try. Ever fail. No matter. // Try again. Fail again. Fail better.
		-- Samuel Beckett

  reply	other threads:[~2007-05-17 17:30 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-05-16 22:47 [0/4] What's not in 1.5.2 (overview) Junio C Hamano
2007-05-16 22:47 ` [1/4] What's not in 1.5.2 (have been cooking in next) Junio C Hamano
2007-05-16 22:47 ` [2/4] What's not in 1.5.2 (will cook " Junio C Hamano
2007-05-16 22:47 ` [3/4] What's not in 1.5.2 (new topics) Junio C Hamano
2007-05-17  4:39   ` Andy Parkins
2007-05-17  5:21     ` Junio C Hamano
2007-05-17  7:51       ` Andy Parkins
2007-05-17 11:02       ` Alex Riesen
2007-05-17 12:46         ` Petr Baudis
2007-05-17 13:46           ` Jeff King
2007-05-17 16:10             ` Petr Baudis
2007-05-17 16:25               ` Jeff King
2007-05-17 17:30                 ` Petr Baudis [this message]
2007-05-17 17:35                   ` Jeff King
2007-05-17 18:49             ` Junio C Hamano
2007-05-18 12:58               ` Jeff King
2007-05-17 18:47         ` Junio C Hamano
2007-05-17 13:45       ` Nicolas Pitre
2007-05-17 21:58       ` Michael S. Tsirkin
2007-05-17 23:41         ` Josef Weidendorfer
2007-05-18  0:32           ` Steven Grimm
2007-05-18  4:50             ` Petr Baudis
2007-05-18  9:18               ` Josef Weidendorfer
2007-05-19  0:56                 ` Torgil Svensson
2007-05-18 12:00               ` Jakub Narebski
2007-05-18 12:41                 ` Petr Baudis
2007-05-19 16:38                   ` Jakub Narebski
2007-05-18 18:37                 ` Junio C Hamano
2007-05-18 18:40                   ` Julian Phillips
2007-05-18 18:45                     ` Junio C Hamano
2007-05-20  0:16                       ` Petr Baudis
2007-05-25  9:55                         ` News reader woes (was: Re: [3/4] What's not in 1.5.2 (new topics)) Jakub Narebski
2007-05-18  7:57           ` [3/4] What's not in 1.5.2 (new topics) Andy Parkins
2007-05-18  8:43             ` Josef Weidendorfer
2007-05-18  9:21               ` Andy Parkins
2007-05-18 11:08                 ` Michael S. Tsirkin
2007-05-18 12:27                   ` Josef Weidendorfer
2007-05-18 12:46                     ` Michael S. Tsirkin
2007-05-18 15:06                   ` Aidan Van Dyk
2007-05-18 15:31                     ` Michael S. Tsirkin
2007-05-19 12:50                   ` Sven Verdoolaege
2007-05-21  1:10                     ` Jakub Narebski
2007-05-18 17:00               ` Junio C Hamano
2007-05-19 18:12                 ` Michael S. Tsirkin
2007-05-19 19:56                   ` Junio C Hamano
2007-05-18  8:57             ` Michael S. Tsirkin
2007-05-18  9:40               ` Andy Parkins
2007-05-18 10:16                 ` Johannes Sixt
2007-05-18 11:22                 ` Michael S. Tsirkin
2007-05-18 12:36                   ` Andy Parkins
2007-05-19  1:02             ` Steven Grimm
2007-05-19 16:55               ` Josef Weidendorfer
     [not found]     ` <200705181524.40705.Josef.Weidendorfer@gmx.de>
     [not found]       ` <20070518133922.GK4708@mellanox.co.il>
     [not found]         ` <200705181751.15435.Josef.Weidendorfer@gmx.de>
2007-05-18 16:08           ` Petr Baudis
2007-05-18 16:21             ` Michael S. Tsirkin
2007-05-16 22:47 ` [4/4] What's not in 1.5.2 (other bits and pieces) Junio C Hamano

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=20070517173005.GS4489@pasky.or.cz \
    --to=pasky@suse.cz \
    --cc=andyparkins@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=peff@peff.net \
    --cc=raa.lkml@gmail.com \
    /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).