Git development
 help / color / mirror / Atom feed
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

  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