git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: Linus Torvalds <torvalds@osdl.org>
Cc: A Large Angry SCM <gitzilla@gmail.com>,
	Ryan Anderson <ryan@michonline.com>,
	git@vger.kernel.org
Subject: Re: [PATCH 0/2] apply.c: a fix and an enhancement
Date: Fri, 22 Jul 2005 15:55:41 -0700	[thread overview]
Message-ID: <7vfyu6jvrm.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <Pine.LNX.4.58.0507221447420.6074@g5.osdl.org> (Linus Torvalds's message of "Fri, 22 Jul 2005 14:53:41 -0700 (PDT)")

Linus Torvalds <torvalds@osdl.org> writes:

> I'd _really_ prefer to not have any preferences or other metadata files
> under version control within that same project.

Don't you think that would be a per-project decision?  Is it
acceptable if I make sure that .gitinfo/* is _optional_ and
things do not break for projects that do not use it?

I hope you are not vetoing the ongoing discussion in another
thread from including the per-project configuration.

Some people want to run their project differently, and one thing
I see often done is to have pre-commit hooks that always run
test suites [*1*].  I do not think it is an unreasonable thing for
Porcelains to support, and what I am trying to get at is if two
Porcelains decide to support it, they do it in a compatible way.

> And personal preferences are just that - personal. I do _not_ want to have 
> the kernel project history have things like "editor preferences" etc in 
> the revision history - you might want to revision them, but that would be 
> totally independent of the history of the project itself.

I agree.  The .gitinfo/fake-parents may be a good thing in that
sense to have project-wide, and as long as the kernel person
(that is you) do not add .gitinfo/commit-template you would be
happy, wouldn't you?


[Footnote]

*1* Personally sometimes I feel myself that is silly, but that
is _other_ people's project, not my own.  I think letting them
follow their own workflow to slow themselves is better than
outright forbidding it and telling them not to do it.

  parent reply	other threads:[~2005-07-22 22:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-07-22 16:56 [PATCH 0/2] apply.c: a fix and an enhancement Junio C Hamano
2005-07-22 18:18 ` Ryan Anderson
2005-07-22 19:46   ` Junio C Hamano
2005-07-22 20:16     ` Ryan Anderson
2005-07-22 20:29     ` A Large Angry SCM
2005-07-22 20:43       ` Linus Torvalds
2005-07-22 21:20         ` Junio C Hamano
2005-07-22 21:53           ` Linus Torvalds
2005-07-22 22:42             ` Santi Béjar
2005-07-22 22:55             ` Junio C Hamano [this message]
2005-07-22 23:26               ` Linus Torvalds
2005-07-22 23:39                 ` Petr Baudis
2005-07-23  0:20                 ` Junio C Hamano
2005-07-22 23:33             ` Petr Baudis
2005-07-22 23:50               ` Linus Torvalds
2005-07-22 23:59                 ` Petr Baudis

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=7vfyu6jvrm.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=gitzilla@gmail.com \
    --cc=ryan@michonline.com \
    --cc=torvalds@osdl.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.
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).