From: "Shawn O. Pearce" <spearce@spearce.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Andy Parkins <andyparkins@gmail.com>, git@vger.kernel.org
Subject: Re: Bug-ish: CRLF endings and conflict markers
Date: Thu, 11 Jan 2007 05:41:11 -0500 [thread overview]
Message-ID: <20070111104111.GF28309@spearce.org> (raw)
In-Reply-To: <Pine.LNX.4.63.0701111123280.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Thu, 11 Jan 2007, Shawn O. Pearce wrote:
> > That's a lot of work and goes very much against the Git mindset that
> > we never alter content, just store it as-is.
>
> While that is correct, we also _use_ the content, and very much alter it
> all the time. A diff, for example, is nothing but altered content.
Yes, of course. But we don't take A and store A' in the ODB during
a commit. We always assert that if you give us A, you'll get back A.
You can always ask us to compute some sort of A' later on, but that
is always based on the originally stored A.
You can also ask us to combine an A and B and get some new thing C.
But again, we don't then go off and store C' instead of C.
> > All I want is to make the user realize what they have done. "Hey dummy,
> > you just changed the entire file and the only difference I see for most
> > lines is simply the addition/removal of a CR. You shouldn't do that!".
> > The pre-commit hook is the perfect place for that.
>
> This sounds sensible. I mistook your task to be integrator for people you
> can't smack.
To some extent I am. But I have patched the local Cygwin package
I use to distribute Git to everyone to have a 1 line pre-commit
update hook (and no other hooks) which just invokes a Perl script
in /usr/local/bin, and that Perl script is also in the same Cygwin
package.
So Cygwin's "feature" of making all Git hooks executable by default
in a new repository plays in my favor here. The pre-commit hook is
active in every repository by default, and it just execs a standard
script which can be modified at any time. So I can easily update
everyone's pre-commit hook at once.
Currently the hook script is just the stock one that comes with Git,
except it ignores CRLF line endings. I'll likely tweak it as I'm
suggesting, make the CRLF->LF/LF->CRLF check an optional feature
that can be toggled on/off in the top of the script, and submit the
patch to update the stock hook. Others may find the check useful.
--
Shawn.
prev parent reply other threads:[~2007-01-11 10:41 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-11 9:41 Bug-ish: CRLF endings and conflict markers Andy Parkins
2007-01-11 9:46 ` Johannes Schindelin
2007-01-11 11:36 ` Andy Parkins
2007-01-11 9:50 ` Shawn O. Pearce
2007-01-11 9:59 ` Johannes Schindelin
2007-01-11 10:16 ` Shawn O. Pearce
2007-01-11 10:26 ` Johannes Schindelin
2007-01-11 10:41 ` Shawn O. Pearce [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=20070111104111.GF28309@spearce.org \
--to=spearce@spearce.org \
--cc=Johannes.Schindelin@gmx.de \
--cc=andyparkins@gmail.com \
--cc=git@vger.kernel.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