From: "Josh England" <jjengla@sandia.gov>
To: "Junio C Hamano" <gitster@pobox.com>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] post-checkout hook, and related docs and tests
Date: Tue, 25 Sep 2007 10:41:13 -0600 [thread overview]
Message-ID: <1190738473.6078.102.camel@beauty> (raw)
In-Reply-To: <7vfy138vql.fsf@gitster.siamese.dyndns.org>
On Mon, 2007-09-24 at 16:54 -0700, Junio C Hamano wrote:
> "Josh England" <jjengla@sandia.gov> writes:
>
> > On Mon, 2007-09-24 at 14:07 -0700, Junio C Hamano wrote:
> > ...
> >> If you want to spacial case
> >>
> >> $ git checkout otherbranch path.c
> >>
> >> it raises another issue. Which commit should supply the
> >> "extended attribute description" for path.c? Should it be taken
> >> from the current commit (aka HEAD), otherbranch, or the index?
> >
> > This already is a special case and your question is valid but not one
> > that git should necessary care about. Since extended attributes are not
> > built into git the only way to handle them is through hooks. A such, it
> > is up to the hook to worry about these kinds of issues.
>
> The fear I have is that that kind of thinking would necessitate
> your hook to be called after the user edits paths.c in any other
> way not to confuse users.
>
> What I am questioning is where we should stop, in order to keep
> things simpler to explain, and I happen to think that it is far
> easier if we can teach that "git checkout other path.c" is
> equivalent to "git cat-file blob other:path.c >path.c" followed
> by "git add path.c", than saying "checkout is magical and if you
> have external hook it can do far more than editing the file
> yourself to arrive at the same contents".
>
> But I am obviously not the one who is interested in tracking
> extended attributes attached to git contents, and I do not feel
> too strongly about one way or the other. I am Ok with it if you
> think "checkout is magical" is easier to teach [*1*].
>
> I just wanted to make sure we know what semantics this is
> bringing in, and get it clearly documented. That's all.
OK. I'll try to come up with some good wording for the documentation.
So this leads to my next question: Should the post-merge patch be
brought in under this same umbrella to form a single post-checkout hook,
or should it stay a separate hook?
-JE
next prev parent reply other threads:[~2007-09-25 16:39 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-09-21 20:27 [PATCH] post-checkout hook, and related docs and tests root
2007-09-21 20:35 ` Josh England
2007-09-22 0:15 ` Junio C Hamano
2007-09-24 17:14 ` Josh England
2007-09-24 18:34 ` Junio C Hamano
2007-09-24 19:33 ` Josh England
2007-09-24 21:07 ` Junio C Hamano
2007-09-24 22:05 ` Josh England
2007-09-24 23:54 ` Junio C Hamano
2007-09-25 4:42 ` Andreas Ericsson
2007-09-25 16:41 ` Josh England [this message]
2007-09-25 21:29 ` Junio C Hamano
2007-09-25 21:47 ` Josh England
2007-09-26 14:52 ` Dmitry Potapov
2007-09-26 19:23 ` Josh England
2007-09-24 17:58 ` Josh England
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=1190738473.6078.102.camel@beauty \
--to=jjengla@sandia.gov \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.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