git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Martin Waitz <tali@admingilde.org>
Cc: Junio C Hamano <junkio@cox.net>, Alex Riesen <raa.lkml@gmail.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: [PATCH 6/6] Teach core object handling functions about gitlinks
Date: Wed, 11 Apr 2007 15:36:31 -0700 (PDT)	[thread overview]
Message-ID: <Pine.LNX.4.64.0704111532540.6730@woody.linux-foundation.org> (raw)
In-Reply-To: <20070411221930.GN21701@admingilde.org>



On Thu, 12 Apr 2007, Martin Waitz wrote:
> 
> But why does everybody want to detach the submodule HEAD, instead
> of creating one 'special' branch which holds the commit which is
> used by the supermodule?

I don't think "everybody" wants it.

But the point is, *regardless* of whether you want a "detached HEAD" or 
you want a "'special' branch", you should always use HEAD to look up the 
commit, and using HEAD *allows* both (ie just make HEAD a symref to the 
'special' branch if you want that behaviour).

And if you *do* use a special branch, HEAD *must* match that special 
branch anyway, since when you commit in the supermodule, the only 
behaviour that makes sense is to commit the currently checked out state!

> I want to create the extra branch exactly _because_ there is
> independent work going on in the submodule (or the project it is
> based on).

And that is entirely appropriate.

But that still means that HEAD must point to that branch (when in the 
submodule), since that branch must be the one that is checked out. If it 
isn't the branch that is checked out, normal operations like "git diff" 
etc wouldn't make sense from the supermodule.

And that is why *regardless* of whether you use a special branch or not, 
HEAD is the right thing to look up.

		Linus

  reply	other threads:[~2007-04-11 22:36 UTC|newest]

Thread overview: 101+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-04-10  4:12 [PATCH 0/6] Initial subproject support (RFC?) Linus Torvalds
     [not found] ` <Pi ne.LNX.4.64.0704092115020.6730@woody.linux-foundation.org>
2007-04-10  4:13 ` [PATCH 1/6] diff-lib: use ce_mode_from_stat() rather than messing with modes manually Linus Torvalds
2007-04-10  4:13 ` [PATCH 2/6] Avoid overflowing name buffer in deep directory structures Linus Torvalds
2007-04-10  4:14 ` [PATCH 3/6] Add 'resolve_gitlink_ref()' helper function Linus Torvalds
2007-04-10  9:38   ` Alex Riesen
2007-04-10 14:58     ` Linus Torvalds
2007-04-10 15:35       ` Alex Riesen
2007-04-10 15:52         ` Linus Torvalds
2007-04-10 15:57           ` Alex Riesen
2007-04-10 16:16             ` Linus Torvalds
2007-04-10 15:54       ` Josef Weidendorfer
2007-04-10  4:14 ` [PATCH 4/6] Add "S_IFDIRLNK" file mode infrastructure for git links Linus Torvalds
2007-04-10  4:15 ` [PATCH 5/6] Teach "fsck" not to follow subproject links Linus Torvalds
2007-04-11 22:41   ` Sam Vilain
2007-04-11 22:48     ` Linus Torvalds
2007-04-11 22:59       ` Sam Vilain
2007-04-11 23:16         ` Linus Torvalds
2007-04-11 23:05           ` David Lang
2007-04-11 23:53             ` Linus Torvalds
2007-04-11 23:30               ` David Lang
2007-04-12  2:14                 ` Linus Torvalds
2007-04-12  2:30                   ` Junio C Hamano
2007-04-12 17:18                   ` David Lang
2007-04-12 18:32                   ` Dana How
2007-04-12 19:17                     ` Linus Torvalds
2007-04-13  9:00                       ` Rogan Dawes
2007-04-13 15:23                         ` Linus Torvalds
2007-04-15  6:50                       ` Dana How
2007-04-12  0:00               ` Dana How
2007-04-12  0:03               ` Sam Vilain
2007-04-12  0:34           ` Junio C Hamano
2007-04-12  1:52             ` Linus Torvalds
2007-04-12  2:00               ` Junio C Hamano
2007-04-12  2:06                 ` Junio C Hamano
2007-04-12  2:28                   ` Linus Torvalds
2007-04-11 23:30         ` Dana How
2007-04-10  4:20 ` [PATCH 6/6] Teach core object handling functions about gitlinks Linus Torvalds
2007-04-10  8:40   ` Frank Lichtenheld
2007-04-10 11:31     ` Alex Riesen
2007-04-10 14:55     ` Linus Torvalds
2007-04-10 16:28   ` Josef Weidendorfer
2007-04-10 16:50     ` Alex Riesen
2007-04-10 17:23       ` Josef Weidendorfer
2007-04-10 18:45     ` Linus Torvalds
2007-04-10 19:04       ` Andy Parkins
2007-04-10 19:20         ` Linus Torvalds
2007-04-10 20:19           ` Junio C Hamano
2007-04-10 20:33             ` Linus Torvalds
2007-04-12  0:12               ` Sam Vilain
2007-04-12  0:35                 ` Martin Waitz
2007-04-12  2:01                 ` Linus Torvalds
2007-04-12  3:56                   ` Sam Vilain
2007-04-10 19:41         ` David Lang
2007-04-10 20:06         ` Junio C Hamano
2007-04-10 19:29       ` Josef Weidendorfer
2007-04-10 19:45         ` Linus Torvalds
2007-04-11 23:47           ` Sam Vilain
2007-04-12  0:13             ` Linus Torvalds
2007-04-12  0:42       ` Torgil Svensson
2007-04-12  0:56         ` Martin Waitz
2007-04-12 21:23           ` Torgil Svensson
2007-04-11 23:36     ` Sam Vilain
2007-04-11  8:06   ` Martin Waitz
2007-04-11  8:29     ` Alex Riesen
2007-04-11  8:36       ` Martin Waitz
2007-04-11  8:49         ` Alex Riesen
2007-04-11  9:20           ` Martin Waitz
2007-04-11  9:15         ` Junio C Hamano
2007-04-11 10:03           ` Martin Waitz
2007-04-11 20:01             ` Junio C Hamano
2007-04-11 22:19               ` Martin Waitz
2007-04-11 22:36                 ` Linus Torvalds [this message]
2007-04-11  9:47     ` Andy Parkins
2007-04-11 11:31       ` Martin Waitz
2007-04-11 15:16     ` Linus Torvalds
2007-04-11 22:49       ` Sam Vilain
2007-04-11 23:54       ` Martin Waitz
2007-04-12  1:57         ` Brian Gernhardt
2007-04-12 15:12         ` Josef Weidendorfer
2007-04-10  4:46 ` [PATCH 0/6] Initial subproject support (RFC?) Linus Torvalds
2007-04-10 13:04   ` Alex Riesen
2007-04-10 15:13     ` Linus Torvalds
2007-04-10 15:48       ` Alex Riesen
2007-04-10 16:07         ` Linus Torvalds
2007-04-10 16:43           ` Alex Riesen
2007-04-10 19:32           ` Junio C Hamano
2007-04-10 20:11             ` Linus Torvalds
2007-04-10 20:52               ` Junio C Hamano
2007-04-10 21:02                 ` Sam Ravnborg
2007-04-10 21:27                   ` Junio C Hamano
2007-04-10 21:03                 ` Nicolas Pitre
2007-04-15 23:21                   ` J. Bruce Fields
2007-04-11  8:08                 ` David Kågedal
2007-04-11  9:32                   ` Junio C Hamano
2007-04-15 23:25                     ` J. Bruce Fields
2007-04-11  8:32     ` Martin Waitz
2007-04-11  8:42       ` Alex Riesen
2007-04-11  8:57         ` Martin Waitz
2007-04-10 13:39   ` [PATCH] allow git-update-index work on subprojects Alex Riesen
2007-04-10 23:19     ` [PATCH] Allow " Alex Riesen
2007-04-11  2:55       ` 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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=Pine.LNX.4.64.0704111532540.6730@woody.linux-foundation.org \
    --to=torvalds@linux-foundation.org \
    --cc=git@vger.kernel.org \
    --cc=junkio@cox.net \
    --cc=raa.lkml@gmail.com \
    --cc=tali@admingilde.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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).