From: Junio C Hamano <gitster@pobox•com>
To: Duy Nguyen <pclouds@gmail•com>
Cc: Mark Levedahl <mlevedahl@gmail•com>,
Git Mailing List <git@vger•kernel.org>
Subject: Re: [PATCH 24/34] checkout: reject if the branch is already checked out elsewhere
Date: Wed, 03 Dec 2014 07:54:21 -0800 [thread overview]
Message-ID: <xmqqegsgloeq.fsf@gitster.dls.corp.google.com> (raw)
In-Reply-To: <CACsJy8DLd4biEHo+FWYLqc4HKezHfv1ymWSQ8kLHLTQv=YKc3A@mail.gmail.com> (Duy Nguyen's message of "Wed, 3 Dec 2014 19:50:31 +0700")
Duy Nguyen <pclouds@gmail•com> writes:
> On Wed, Dec 3, 2014 at 12:30 AM, Junio C Hamano <gitster@pobox•com> wrote:
>>> I do like "read-only" ref concept where we can keep ref name
>>> (especially tags) in HEAD until the next commit. But it didn't go
>>> anywhere
>>
>> Remind me. That sounds somewhat interesting.
>
> Couldn't find anything in my mail archive. But the idea is simple:
>
> - we delay detaching HEAD until we need to update the associated ref
> at commit/reset time
> - currently refs/tags/* are read-only. we generalize it to allow this
> 'read-only' attribute on some refs/heads/* as well. Because we can't
> really add attributes to refs, config var could be used.
It could be some annotation in HEAD instead, e.g.
$ cat .git/HEAD
ref: refs/heads/frotz
options: read-only
$ exit
and it may make more sense as this read-only-ness is closely tied to
the state of HEAD, i.e. whatever operation that manipulates the
HEAD, it needs to be very much aware of the read-only-ness, and it
is much less likely to go out of sync, compared to a solution where
you store this bit to anywhere else, e.g. config.
next prev parent reply other threads:[~2014-12-03 15:54 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-30 8:24 [PATCH 00/34] nd/multiple-work-trees reroll Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 01/34] path.c: make get_pathname() return strbuf instead of static buffer Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 02/34] path.c: make get_pathname() call sites return const char * Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 03/34] git_snpath(): retire and replace with strbuf_git_path() Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 04/34] path.c: rename vsnpath() to do_git_path() Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 05/34] path.c: group git_path(), git_pathdup() and strbuf_git_path() together Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 06/34] git_path(): be aware of file relocation in $GIT_DIR Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 07/34] *.sh: respect $GIT_INDEX_FILE Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 08/34] reflog: avoid constructing .lock path with git_path Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 09/34] fast-import: use git_path() for accessing .git dir instead of get_git_dir() Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 10/34] commit: use SEQ_DIR instead of hardcoding "sequencer" Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 11/34] $GIT_COMMON_DIR: a new environment variable Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 12/34] git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objects Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 13/34] *.sh: avoid hardcoding $GIT_DIR/hooks/ Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 14/34] git-stash: avoid hardcoding $GIT_DIR/logs/ Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 15/34] setup.c: convert is_git_directory() to use strbuf Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 16/34] setup.c: detect $GIT_COMMON_DIR in is_git_directory() Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 17/34] setup.c: convert check_repository_format_gently to use strbuf Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 18/34] setup.c: detect $GIT_COMMON_DIR check_repository_format_gently() Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 19/34] setup.c: support multi-checkout repo setup Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 20/34] wrapper.c: wrapper to open a file, fprintf then close Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 21/34] use new wrapper write_file() for simple file writing Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 22/34] checkout: support checking out into a new working directory Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 23/34] prune: strategies for linked checkouts Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 24/34] checkout: reject if the branch is already checked out elsewhere Nguyễn Thái Ngọc Duy
2014-11-30 17:18 ` Mark Levedahl
2014-12-01 10:38 ` Duy Nguyen
2014-12-01 17:39 ` Junio C Hamano
2014-12-02 5:04 ` Mark Levedahl
2014-12-02 12:01 ` Duy Nguyen
2014-12-02 17:30 ` Junio C Hamano
2014-12-03 11:30 ` Mark Levedahl
2014-12-03 12:50 ` Duy Nguyen
2014-12-03 15:54 ` Junio C Hamano [this message]
2014-12-02 11:50 ` Duy Nguyen
2014-11-30 8:24 ` [PATCH 25/34] checkout: clean up half-prepared directories in --to mode Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 26/34] gc: style change -- no SP before closing parenthesis Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 27/34] gc: factor out gc.pruneexpire parsing code Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 28/34] gc: support prune --worktrees Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 29/34] count-objects: report unused files in $GIT_DIR/worktrees/ Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 30/34] git_path(): keep "info/sparse-checkout" per work-tree Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 31/34] checkout: don't require a work tree when checking out into a new one Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 32/34] t2025: add a test to make sure grafts is working from a linked checkout Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 33/34] checkout: do not fail if target is an empty directory Nguyễn Thái Ngọc Duy
2014-11-30 8:24 ` [PATCH 34/34] git-common-dir: make "modules/" per-working-directory directory Nguyễn Thái Ngọc Duy
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=xmqqegsgloeq.fsf@gitster.dls.corp.google.com \
--to=gitster@pobox$(echo .)com \
--cc=git@vger$(echo .)kernel.org \
--cc=mlevedahl@gmail$(echo .)com \
--cc=pclouds@gmail$(echo .)com \
/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