From: Petr Baudis <pasky@suse.cz>
To: Linus Torvalds <torvalds@osdl.org>
Cc: Junio C Hamano <junkio@cox.net>,
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: Sat, 23 Jul 2005 01:59:44 +0200 [thread overview]
Message-ID: <20050722235944.GS11916@pasky.ji.cz> (raw)
In-Reply-To: <Pine.LNX.4.58.0507221640050.6074@g5.osdl.org>
Dear diary, on Sat, Jul 23, 2005 at 01:50:09AM CEST, I got a letter
where Linus Torvalds <torvalds@osdl.org> told me that...
>
>
> On Sat, 23 Jul 2005, Petr Baudis wrote:
> >
> > Yes, but this stuff is not for personal preferences. It is for
> > project-wide preferences and policies, which can be still normally
> > overridden or altered locally in each repository.
>
> What you are describing is a nightmare.
>
> Let's assume that a user alters the settings locally.
>
> EVERY SINGLE TIME he does a "cg-commit", those local alterations would get
> committed, since that config file is part of the same project, and cogito
> by default commits all changes.
No, no, no. A user does not alter the settings locally in .gitinfo/ -
.gitinfo/ is for per-_project_ stuff, not per-user. If user wants an
override, he does it per-repository in his .git/conf directory, which is
not version-tracked (actually, core GIT does not even let me to).
> That's just insane. It means that in practive it's simply not reasonable
> to have your own local copies of that file. So what would you do? You'd
> add more and more hacks to cover this up, and have a "commit-ignore" file
> that ignores the .gitinfo files etc etc. UGLY. All because of a design
> mistake.
Actually, commit-ignore might be useful in other cases, e.g. when
someone (me, a thousand times in the past) needs to keep temporary hacks
in the Makefile so that he can actually build the thing on his weird
system etc. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
prev parent reply other threads:[~2005-07-22 23:59 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
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 [this message]
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=20050722235944.GS11916@pasky.ji.cz \
--to=pasky@suse.cz \
--cc=git@vger.kernel.org \
--cc=gitzilla@gmail.com \
--cc=junkio@cox.net \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.