autocrlf problems with Git-preview20080301.exe
Sebastian Schuberth
I'm having several autocrlf related issues with the new Git-
preview20080301.exe installer.
The first is rather an oddity than a real problem:
$ grep autocrlf ~/.gitconfig
autocrlf = true
$ grep autocrlf .git/config
$ git config --get core.autocrlf
true
$ git config --list | grep autocrlf
core.autocrlf=true
core.autocrlf=true
As you can see, "config --list" lists autocrlf twice. Probably the new
internal default of autocrlf=true is listed here too?
The second problem in fact seems to have already existed in earlier
releases, but now became more apparent due to the warning Git is
issuing:
$ git config --get core.autocrlf
true
$ git branch
vi-stable
* vi-work
$ git merge origin/qt4
warning: LF will be replaced by CRLF in amiramain/bin/start
Auto-merged Amira/HxObject.cpp
Auto-merged hxcolormapeditor/HxAdvancedColormapEditor.cpp
CONFLICT (content): Merge conflict in hxcolormapeditor/
HxAdvancedColormapEditor.cpp
Automatic merge failed; fix conflicts and then commit the result.
# Both the "start" and "HxAdvancedColormapEditor.cpp" have Unix line-
ending at this point,
# despite autocrlf=true
$ git mergetool
Merging the files: hxcolormapeditor/HxAdvancedColormapEditor.cpp
Normal merge conflict for 'hxcolormapeditor/
HxAdvancedColormapEditor.cpp':
{local}: modified
{remote}: modified
Hit return to start merge resolution tool (ecmerge):
warning: LF will be replaced by CRLF in hxcolormapeditor/
HxAdvancedColormapEditor.cpp
# Again, the warning is correct, but HxAdvancedColormapEditor.cpp
should have had CRLF instead
# of LF in the first place
Moreover, if there is a modified file
$ git diff --name-status
M hxvoltex/SxVoltex.h
then "git diff" will checkout the temporary file which reflects
"SxVoltex.h" in the repository also with LF instead of CRLF, i.e. the
autocrlf setting does not seem to be respected. But this problem also
was present in earlier releases already.
Steffen Prohaska already took a quick look at this (but has no time to
fix it) and thinks handle_file() in builtin-rerere.c is missing the
conversion and thus causing the problems.
--
Sebastian Schuberth
Johannes Schindelin
On Mon, 10 Mar 2008, Sebastian Schuberth wrote:
> I'm having several autocrlf related issues with the new Git-
> preview20080301.exe installer.
>
> The first is rather an oddity than a real problem:
>
> $ grep autocrlf ~/.gitconfig
> autocrlf = true
>
> $ grep autocrlf .git/config
>
> $ git config --get core.autocrlf
> true
>
> $ git config --list | grep autocrlf
> core.autocrlf=true
> core.autocrlf=true
>
> As you can see, "config --list" lists autocrlf twice. Probably the new
> internal default of autocrlf=true is listed here too?
It comes from /etc/gitconfig, yes.
I hope to get some time and motivation tonight to have a look at it, could
you bug me again tomorrow if I did not?
Ciao,
Dscho
Sebastian Schuberth
> > core.autocrlf=true
> > core.autocrlf=true
> >
> > As you can see, "config --list" lists autocrlf twice. Probably the new
> > internal default of autocrlf=true is listed here too?
>
> It comes from /etc/gitconfig, yes.
So I guess it is intended to be listed twice here, as "config --list"
is not supposed to list the setting in effect (despite "config
--get"), but all the explicitly set settings, right?
> > Steffen Prohaska already took a quick look at this (but has no time to
> > fix it) and thinks handle_file() in builtin-rerere.c is missing the
> > conversion and thus causing the problems.
>
> I hope to get some time and motivation tonight to have a look at it, could
> you bug me again tomorrow if I did not?
Sure :-)
--
Sebastian Schuberth
Johannes Schindelin
On Mon, 10 Mar 2008, Sebastian Schuberth wrote:
> > > $ git config --list | grep autocrlf
> > > core.autocrlf=true
> > > core.autocrlf=true
> > >
> > > As you can see, "config --list" lists autocrlf twice. Probably the
> > > new internal default of autocrlf=true is listed here too?
> >
> > It comes from /etc/gitconfig, yes.
>
> So I guess it is intended to be listed twice here, as "config --list" is
> not supposed to list the setting in effect (despite "config --get"), but
> all the explicitly set settings, right?
Yes.
Ciao,
Dscho
Stephen Waits
mistake. It's potentially destructive.. I don't want my SCM every
changing my files for me.
Every editor I use on windows deals with non CRLF line endings just
fine, and that's how we usually edit our code anyway.
Just my $0.02.
--Steve
tormod...@gmail.com
mistake. I upgraded to Git-
preview20080301.exe to get the new SSH bits (The "unable to do git
pull" problem suddenly bit me the other day). After upgrading I did a
clone of the main repository. "git status" immideately after clone
listed a massive amounts of files changed, where every line was
changed in the files. I do not want to do have a commit in the history
with all those changes just because the SCM tool changed defaults.
This is a 3 year old cross-plattform repository. Editing and commiting
from Windows has worked great previously, no problems.
I fixed it by setting autocrlf to false in etc/gitconfig. "git status"
after a new clone showed no changed files.
I suppose autocrlf enabled by default could be useful for new
repositories, but not for working with existing repositories.
- Tormod
Steffen Prohaska
> I agree with Steve, I also think enabling autocrlf by default is a
> mistake. I upgraded to Git-
> preview20080301.exe to get the new SSH bits (The "unable to do git
> pull" problem suddenly bit me the other day). After upgrading I did a
> clone of the main repository. "git status" immideately after clone
> listed a massive amounts of files changed, where every line was
> changed in the files. I do not want to do have a commit in the history
> with all those changes just because the SCM tool changed defaults.
> This is a 3 year old cross-plattform repository. Editing and commiting
> from Windows has worked great previously, no problems.
I suppose you use LF lineendings on Windows, right?
This can work greatly if you are aware of it; but might cause trouble if
some developers are not. LF lineendings are not the native lineendings
on Windows. My experience with a large group of Windows-only developers
who never work on Unix is that at some point Windows tools create CRLF
endings and these endings enter the repository. The repository then
contains mixed line endings. Typically, this is not what you want.
> I fixed it by setting autocrlf to false in etc/gitconfig. "git status"
> after a new clone showed no changed files.
>
> I suppose autocrlf enabled by default could be useful for new
> repositories, but not for working with existing repositories.
We changed the global default to a sane setting for cross-platform
projects to avoid such problems in the future. This means that from now
on git will take care that any repository newly created will have sane
line endings (LF in the repository; and CRLF in the work tree if checked
out on Windows respectively LF if checked out on Unix).
Unfortunately, existing repositories that contain the wrong line endings
suffer from the problems you described above. This can be handled
either by switching off autocrlf, as you propose, or by cleaning up the
line endings.
I do not see an easy way to avoid these inconveniences during the
transition period.
Steffen
--
Steffen Prohaska <proh...@zib.de> <http://www.zib.de/prohaska/>
Zuse Institute Berlin, Takustr. 7, D-14195 Berlin-Dahlem, Germany
+49 (30) 841 85-337, fax -107
Johannes Schindelin
On Sat, 22 Mar 2008, Steffen Prohaska wrote:
> I do not see an easy way to avoid these inconveniences during the
> transition period.
Well, two reactions from me:
1) we never said msysgit was stable. By _expecting_ us not to break
things this early, you are _limiting_ our options.
2) this is Open Source. If it is your itch (and in this case, I clearly
see that it is no longer _mine_), you can do something about it.
Do it yourself, pay someone, or complain until somebody (not me,
though, since I ignore whiners) fixes it.
I, for one, are pretty happy with msysGit, and I have to admit that I
forked off of it for other projects, because it makes it so easy to have a
complete and working MSys setup.
Ciao,
Dscho
Junio C Hamano
>> I suppose autocrlf enabled by default could be useful for new
>> repositories, but not for working with existing repositories.
>
> We changed the global default to a sane setting for cross-platform
> projects to avoid such problems in the future. This means that from now
> on git will take care that any repository newly created will have sane
> line endings (LF in the repository; and CRLF in the work tree if checked
> out on Windows respectively LF if checked out on Unix).
I've always wondered why you guys used /etc/gitconfig instead of setting
it in the templates (or a patch to git-init).
I was against the idea of /etc/gitconfig from the very beginning (even
before msysgit existed) in git.git itself, but this is a very good example
why /etc/gitconfig is a bad idea. It affects _existing_ setups.
How about fixing msys port so that it sets the configuration when the user
initializes a _new_ repository, without breaking repositories the user has
been happily using?
Johannes Schindelin
Makes sense.
Steffen, you still submerged in work, or can you make that change?
Ciao,
Dscho
Steffen Prohaska
Hmm. I am not convinced.
Setting autocrlf for every repository limits the user's options to
override the default. Currently we provide a global default and the
user can either override globally for all his repositories or on
a per-repository basis. Hence, users can decide that they want autocrlf
to never happen and can easily set this in ~/.gitconfig. If we stored
autocrlf in every newly created repository, the user would need to
override our default again and again for every new repository.
Maybe what we want is to conserve the setup that exists when a new
repository is created. Changing autocrlf later is tricky because the
work tree's line endings depend on the settings during checkout.
Therefore, it makes sense to preserve the value of autocrlf that exists
during the first checkout. In this regards autocrlf is different from,
for example, author because author can be easily changed later without
requiring any conversion of existing files in the work tree.
Patch follows.
Unfortunately the proposed change won't change the fact that existing
msysgit setups still break. I still do not see an easy way to avoid
this.
Steffen
Steffen Prohaska
even if the global setup changes is a good idea. Changing autocrlf
later is tricky because the work tree's line endings depend on the
settings during checkout. Therefore, it makes sense to preserve the
value of autocrlf that exists during the first checkout. In this
can be easily changed later without requiring any conversion of existing
files in the work tree.
This commit modifies the initialization of a new repository to store the
current value of autocrlf.
Signed-off-by: Steffen Prohaska <proh...@zib.de>
---
builtin-init-db.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 79eaf8d..6c49a82 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -268,6 +268,22 @@ static int create_default_files(const char *git_dir, const char *template_path)
git_config_set("core.symlinks", "false");
}
+ /*
+ * Store current value of auto_crlf to preserve it for
+ * this repository even if the global setup changes.
+ */
+ switch (auto_crlf) {
+ case -1:
+ git_config_set("core.autocrlf", "input");
+ break;
+ case 0:
+ git_config_set("core.autocrlf", "false");
+ break;
+ case 1:
+ git_config_set("core.autocrlf", "true");
+ break;
+ }
+
return reinit;
}
--
1.5.5.rc0.21.g740fd.dirty
Junio C Hamano
Not _so_ quick.
I think it probably would make sense to give per-user preference. It was
conjectured that _most_ Windows folks would happily use CRLF and autocrlf
would be the right thing, but early adopters tend to be people who grew
their git experience on POSIXy systems and rather want to work with LF
without autocrlf mangling.
One solution could be to teach git-init read from $HOME/.gitconfig and
find "[init] fixup = script-name" and run it after it finishes its usual
thing. That way, people without customization would get the default the
packager, platform and/or sitemaster specifies, but with such a hook, they
can fix it up to suit their taste if it is not suitable for them.
Johannes Schindelin
Then maybe a way for the user to override the global templates is what we
need? I can see that this would be useful outside of the crlf issue.
Ciao,
Dscho
Johannes Schindelin
On Sun, 23 Mar 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes....@gmx.de> writes:
>
> > On Sat, 22 Mar 2008, Junio C Hamano wrote:
> >
> >> I've always wondered why you guys used /etc/gitconfig instead of
> >> setting it in the templates (or a patch to git-init).
> >>
> >> I was against the idea of /etc/gitconfig from the very beginning
> >> (even before msysgit existed) in git.git itself, but this is a very
> >> good example why /etc/gitconfig is a bad idea. It affects _existing_
> >> setups.
> >>
> >> How about fixing msys port so that it sets the configuration when the
> >> user initializes a _new_ repository, without breaking repositories
> >> the user has been happily using?
> >
> > Makes sense.
>
> Not _so_ quick.
But we must be quick. Too many users already complained. Unfortunately
without any suggestions (I don't count "revert that!" as a suggestion,
since it obviously lacks the necessary considering-the-consequences step).
> I think it probably would make sense to give per-user preference. It
> was conjectured that _most_ Windows folks would happily use CRLF and
> autocrlf would be the right thing, but early adopters tend to be people
> who grew their git experience on POSIXy systems and rather want to work
> with LF without autocrlf mangling.
>
> One solution could be to teach git-init read from $HOME/.gitconfig and
> find "[init] fixup = script-name" and run it after it finishes its usual
> thing. That way, people without customization would get the default the
> packager, platform and/or sitemaster specifies, but with such a hook,
> they can fix it up to suit their taste if it is not suitable for them.
In the current case, Git on Windows is usually installed for one user. So
we probably can change the templates, and tell the users to change them
again if they do not like our default (if they realize that something
changed at all; CR/LF is not _that_ visible, except if core.autocrlf is
changed _after_ checking out the files).
Alternatively, we could introduce sections "default" which git-init heeds,
such as
[default "core"]
autocrlf = false
Hmm.
Ciao,
Dscho
Steffen Prohaska
> On Sun, 23 Mar 2008, Junio C Hamano wrote:
>
> > Johannes Schindelin <Johannes....@gmx.de> writes:
> >
> > > On Sat, 22 Mar 2008, Junio C Hamano wrote:
> > >
> > >> I've always wondered why you guys used /etc/gitconfig instead of
> > >> setting it in the templates (or a patch to git-init).
> > >>
> > >> I was against the idea of /etc/gitconfig from the very beginning
> > >> (even before msysgit existed) in git.git itself, but this is a very
> > >> good example why /etc/gitconfig is a bad idea. It affects _existing_
> > >> setups.
> > >>
> > >> How about fixing msys port so that it sets the configuration when the
> > >> user initializes a _new_ repository, without breaking repositories
> > >> the user has been happily using?
> > >
> > > Makes sense.
> >
> > Not _so_ quick.
>
> But we must be quick. Too many users already complained. Unfortunately
> without any suggestions (I don't count "revert that!" as a suggestion,
> since it obviously lacks the necessary considering-the-consequences step).
Hmm. The "Featured" 1.5.4 installer does not have autocrlf set. Only
the "cutting-edge" installer brings the new default. Users can easily
avoid the trouble by choosing the "Featured" installer.
> > I think it probably would make sense to give per-user preference. It
> > was conjectured that _most_ Windows folks would happily use CRLF and
> > autocrlf would be the right thing, but early adopters tend to be people
> > who grew their git experience on POSIXy systems and rather want to work
> > with LF without autocrlf mangling.
> >
> > One solution could be to teach git-init read from $HOME/.gitconfig and
> > find "[init] fixup = script-name" and run it after it finishes its usual
> > thing. That way, people without customization would get the default the
> > packager, platform and/or sitemaster specifies, but with such a hook,
> > they can fix it up to suit their taste if it is not suitable for them.
>
> In the current case, Git on Windows is usually installed for one user. So
> we probably can change the templates, and tell the users to change them
> again if they do not like our default (if they realize that something
> changed at all; CR/LF is not _that_ visible, except if core.autocrlf is
> changed _after_ checking out the files).
This is not what I do. I install Git as Administrator to make it
available for all users in our Windows domain. Common users can't
modify the installation, which is a good thing IMHO.
Steffen
Steffen Prohaska
I do not think we need this. autocrlf is a configurable variable and we
already have a mechanism for the user to override configuration
variables. The user can use "git config --global ..." to sets his
preferences. This mechanism is well established. I do not see a reason
not to use it.
Steffen
Johannes Schindelin
The point is: if we use /etc/gitconfig, we also touch _existing_ setups
(as Junio pointed out). Which, in the case of autocrlf, is not desirable.
And if we go the route via templates, $HOME/.gitconfig will do no good, as
the configuration in the repository trumps the --global configuration.
Ciao,
Dscho
tormod...@gmail.com
everyone involved in the project is on Windows now, so I guess we
should clean up the line endings anyway.
Johannes and Steffen: Thank you for your continued hard work and
passion for Git on Windows, I really appreciate it. I'm a happy user
and early adopter of new versions. I tried to contribute by sharing my
experiences with the newest version, my intent was not to come off as
"whiny", sorry for that.
A solution that automatically preserves the old settings for existing
repositories and sets autocrlf = true for new repositories would be a
good solution, in my opinion. I'll leave the implementation details to
the experts. :-)
- Tormod
Steffen Prohaska
> On Sun, 23 Mar 2008, Steffen Prohaska wrote:
>
> > On Sun, 23 Mar 2008, Johannes Schindelin wrote:
> >
> > > On Sun, 23 Mar 2008, Steffen Prohaska wrote:
> > >
> > > > On Sun, 23 Mar 2008, Johannes Schindelin wrote:
> > > >
> > > > Setting autocrlf for every repository limits the user's options to
> > > > override the default.
> > >
> > > Then maybe a way for the user to override the global templates is what we
> > > need? I can see that this would be useful outside of the crlf issue.
> >
> > I do not think we need this. autocrlf is a configurable variable and we
> > already have a mechanism for the user to override configuration
> > variables. The user can use "git config --global ..." to sets his
> > preferences. This mechanism is well established. I do not see a reason
> > not to use it.
>
> The point is: if we use /etc/gitconfig, we also touch _existing_ setups
> (as Junio pointed out). Which, in the case of autocrlf, is not desirable.
I proposed a mechanism that would avoid such problems in the future.
Repositories that would copy the current setting of autocrlf to their
local .git/config would be shielded from future changes to the global
setup.
> And if we go the route via templates, $HOME/.gitconfig will do no good, as
> the configuration in the repository trumps the --global configuration.
We have two conflicting objectives and I do not know how to meet them
the same time:
1) Existing setups should not break.
2) Users should have a way to set a global default for autocrlf that
overrides our defaults.
If we store the new default in newly created repositories, (1) would be
met but (2) is not possible. If we support ~/.gitconfig for overriding
the system-wide default, (2) is trivial but (1) is hard to meet.
I propose to break existing setup and provide a simple mechanism to
avoid such breakages in the future. As you pointed out earlier we are
still only releasing "previews" on Windows and one reason for this
decision was the lacking support for autocrlf. We always knew that some
work would be needed before we have a sane setup on Windows.
Maybe we can improve the installer to warn the users that the default
has changed and existing repositories must either be converted or the
global default must be overridden. The installer could ask the user to
confirm this change. Maybe this is sufficient to avoid further
complains about weird behavior after upgrading.
Steffen
Johannes Schindelin
On Sun, 23 Mar 2008, tormod...@gmail.com wrote:
> Johannes and Steffen:
On this list it is considered rude to address people, but not even Cc:
them.
Ciao,
Dscho
Johannes Schindelin
On Sun, 23 Mar 2008, Steffen Prohaska wrote:
> On Sun, 23 Mar 2008, Johannes Schindelin wrote:
>
> > The point is: if we use /etc/gitconfig, we also touch _existing_
> > setups (as Junio pointed out). Which, in the case of autocrlf, is not
> > desirable.
>
> I proposed a mechanism that would avoid such problems in the future.
Yes, but your solution feels a bit limited and "hot-needled" for just one
purpose.
> Maybe we can improve the installer to warn the users that the default
> has changed and existing repositories must either be converted or the
> global default must be overridden. The installer could ask the user to
> confirm this change. Maybe this is sufficient to avoid further
> complains about weird behavior after upgrading.
Maybe. My experience is that people do not even read the big red warnings
in the installer. Whatever.
Ciao,
Dscho
Steffen Prohaska
> On Sun, 23 Mar 2008, Steffen Prohaska wrote:
>
> > On Sun, 23 Mar 2008, Johannes Schindelin wrote:
> >
> > > The point is: if we use /etc/gitconfig, we also touch _existing_
> > > setups (as Junio pointed out). Which, in the case of autocrlf, is not
> > > desirable.
> >
> > I proposed a mechanism that would avoid such problems in the future.
>
> Yes, but your solution feels a bit limited and "hot-needled" for just one
> purpose.
What limits do you mean (except that it does still break existing
msysgit setups; but would avoid this problem in the future)?
Steffen
Johannes Schindelin
I have the impression that a problem just like this will arise again, just
not with corelf, but with another setting that the admin might want to
set per default in git-init, but the user might want to override.
Ciao,
Dscho
Steffen Prohaska
My patch does not set the default in git-init, but only stores the
current choice of autocrlf in the repository's config. autocrlf is
special because it cannot be easily changed after the initial checkout.
Changing autocrlf might require converting the line endings of all files
in the work tree. This is very different from most other configuration
variables, which can be changed without requiring any modifications to
the work tree.
In some sense you cannot change autocrlf at all after a repository is
initialized. At least you need a deep understanding of the autocrlf
mechanism to avoid unexpected behavior. Once you checked out files,
these files might 'preserve' the setting of autocrlf during the
checkout. For example if you use autocrlf=true during checkout and
later change to autocrlf=false, git will detect all files as changed
because they contain CRLF in the workspace but LF in the repository.
The situation is even worse, because the choice of autocrlf is not
a purely local one, but depends on the project you are cloning. A sane
policy is to have only LF line-endings in the repository and use native
line-endings in the work tree. This can be guaranteed with
autocrlf=input on Unix and autocrlf=true on Windows. Another possible
choice is to tell git to not modify any content at all, which
autocrlf=false would give you. Personally, I do not think the latter is
a reasonable choice, but other might have a different opinion. My point
is that it is the choice of the project: Either *all* repositories that
clone the project should set autocrlf=input|true or *all* repositories
should set autocrlf=false. It is neither the choice of the local admin,
nor the local user, nor the default of git. You need to have
project-specific knowledge to make the right choice.
I suspect that a lot of projects implicitly chose autocrlf=false because
of lacking autocrlf support in the past. The default of git was to not
touch the content at all; and still this is the default on Unix. Only
lately we tried to provide a more sensible default on Windows.
All projects that implicitly assume autocrlf=false might get into
trouble if we change the default, no matter which way we do this. For
example we could use the templates to provide a new default. The
existing repository's settings would not change. But the next time the
user clones such a repository the clone would have the new settings and
this would cause trouble if the project contains files with mixed
line-endings. The same happens if we directly modify git's default.
The only difference is that the trouble surfaces immediately because the
new default affects existing repositories.
A possible solution would be if a project (not a single repository)
could specify autocrlf and the choice was preserved across cloning.
I do not advocate this solution. Such a mechanism is not available and
I personally do not know why it should be added. As I pointed out above
I believe that autocrlf=input|true is the only sane way of handling
cross-platform projects and if git's binary auto-detection fails to
detect a file you should by all means add it to .gitattributes. This is
the only way to guarantee that the file will be properly handled with
any autocrlf settings.
The solution I propose is to change the default now; tell the users
about the change; explain again and again why it is good to enforce LF
line-endings in the repository; and fix all repositories that contain
CRLF line-endings ASAP.
But even if all repositories contained only LF, the original problem
would remain. The work tree depends on the choice of autocrlf during
checkout and cannot be easily modified later. Not only the admin or the
maintainer of git can cause trouble by changing the default. The user
himself can cause trouble by modifying the setup with "git config
--global".
This is where my proposed patch kicks in. I propose to modify init-db
to store the choice of autocrlf in the repository to preserve it for
this repository, no matter who made this choice and no matter who
decides to change the setup later. Only if the user deliberately
chooses to modify the local setting of the repository he might get into
trouble; but git always gives you this kind of freedom, no?
Yet the patch does not protect you from all trouble. It only works well
in all cases if you have a repository that contains only LF. If this is
the case you are free to choose autocrlf=input or autocrlf=true. Both
will give you work trees without unexpected diffs right after checkout;
and both choices will guarantee that CRLFs will never enter the
repository. Still you must not thoughtlessly change autocrlf without
fixing the line endings of the checked out files.
Steffen
Johannes Schindelin
On Sun, 23 Mar 2008, Steffen Prohaska wrote:
> On Sun, 23 Mar 2008, Johannes Schindelin wrote:
>
> > I have the impression that a problem just like this will arise again,
> > just not with corelf, but with another setting that the admin might
> > want to set per default in git-init, but the user might want to
> > override.
>
> My patch does not set the default in git-init, but only stores the
> current choice of autocrlf in the repository's config. autocrlf is
> special because it cannot be easily changed after the initial checkout.
But basically all clean/smudge filters have exactly the same problem! And
core.ignorecase, too!
There must be a way to do it elegantly, without catering just for
autocrlf.
Ciao,
Dscho
Dmitry Potapov
>
> We have two conflicting objectives and I do not know how to meet them
> the same time:
>
> 1) Existing setups should not break.
>
> 2) Users should have a way to set a global default for autocrlf that
> overrides our defaults.
>
> If we store the new default in newly created repositories, (1) would be
> met but (2) is not possible. If we support ~/.gitconfig for overriding
> the system-wide default, (2) is trivial but (1) is hard to meet.
To meet both requirements you have to copy autocrlf setting for each new
repository during git init or clone and should never use the global
value for any other purpose than this.
This means that you do NOT really need the system or global default for
autocrlf in the sense we have it for other configuration variables, but
you need a template value for it.
We already have templates for different hooks, info/exclude, etc. So,
instead of placing autocrlf in /etc/gitconfig, you should place this
variable to /usr/share/git/templates/config and this file should be
copied by git init or git clone as any other file in templates.
Dmitry
Johannes Schindelin
On Mon, 24 Mar 2008, Dmitry Potapov wrote:
> We already have templates for different hooks, info/exclude, etc. So,
> instead of placing autocrlf in /etc/gitconfig, you should place this
> variable to /usr/share/git/templates/config and this file should be
> copied by git init or git clone as any other file in templates.
I thought we discussed that already? And the consensus was that this does
not allow for per-user overriding.
Ciao,
Dscho
Dmitry Potapov
> Storing the current value of autocrlf to preserve it for this repository
> even if the global setup changes is a good idea. Changing autocrlf
> later is tricky because the work tree's line endings depend on the
> settings during checkout. Therefore, it makes sense to preserve the
> value of autocrlf that exists during the first checkout. In this
> regards autocrlf is different from, for example, author, because author
> can be easily changed later without requiring any conversion of existing
> files in the work tree.
>
> This commit modifies the initialization of a new repository to store the
> current value of autocrlf.
NAK
While I agree that preserving autocrlf may be a good idea, I don't like
that the idea of making an exception for autocrlf and treating the global
settings for it differently than for other variables -- as something that
should be copied on init. We have templates for that, so autocrlf should
be placed into templates/config and then it will be automatically copied
when a new repository is created. I have tested that now, and it works.
Dmitry
Dmitry Potapov
I am sorry I missed this discussion. In this case, I believe that the
idea of templates should be extended, so any user may have his/her own
templates in $HOME/.gittemplates. IMHO, it makes much more sense than
making an exception for autocrlf in builtin-init-db.c and breaking
existing repositories...
Dmitry
Johannes Schindelin
I think I actually suggested something like that. But that gets only even
more complicated: if you have a template for .git/config in
$HOME/.gittemplates/, then the global template will be _disregarded_, even
if the administrator puts something vital in there.
Maybe the best idea would be an "init" hook, settable from the config,
after all.
Ciao,
Dscho
Dmitry Potapov
>
> I think I actually suggested something like that. But that gets only even
> more complicated: if you have a template for .git/config in
> $HOME/.gittemplates/, then the global template will be _disregarded_, even
> if the administrator puts something vital in there.
Maybe, because I cannot imagine what so vital the administrator can put
in it, I really do not see that as a problem. I believe that any good
administrator should notify all users about any vital changes anyway,
because if these changes are vital, it may be necessary not only change
templates in $HOME/.gittemplates/ (which very few users will probably
have), but perhaps also in existing repositories...
>
> Maybe the best idea would be an "init" hook, settable from the config,
> after all.
I agree that seems to be the best solution as it is more flexible than
having $HOME/.gittemplates/.
Dmitry
Johannes Schindelin
This variable, if set, specifies the path of a hook which is executed
after every git-init.
It can be used to override settings in the templates per-user. For
example, when the adminstrator set core.autoCRLF=true in the templates,
but you want to avoid that explicitely.
Signed-off-by: Johannes Schindelin <johannes....@gmx.de>
---
On Mon, 24 Mar 2008, Dmitry Potapov wrote:
Documentation/config.txt | 4 ++++
Documentation/git-init.txt | 3 +++
builtin-init-db.c | 26 ++++++++++++++++++++++++++
t/t0001-init.sh | 21 +++++++++++++++++++++
4 files changed, 54 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index efde54d..3323724 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -358,6 +358,10 @@ core.whitespace::
does not trigger if the character before such a carriage-return
is not a whitespace (not enabled by default).
+core.inithook::
+ The path to a program which is run after each call to
+ linkgit:git-init[1].
+
alias.*::
Command aliases for the linkgit:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 03a4f0e..e082218 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -60,6 +60,9 @@ If you are initializing a non-bare repository, the config variable
`receive.guardCurrentBranch` is set to true. This avoids problems with
pushing into the current branch, which does not touch the working tree.
+If you want to run a specific script everytime git-init was issued, you
+can set the variable `core.initHook`.
+
--
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 36c12a2..1975910 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -6,6 +6,7 @@
#include "cache.h"
#include "builtin.h"
#include "exec_cmd.h"
+#include "run-command.h"
#ifndef DEFAULT_GIT_TEMPLATE_DIR
#define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates"
@@ -310,6 +311,28 @@ static void guess_repository_type(const char *git_dir)
return;
}
+static const char *init_hook;
+static int config_init_hook(const char *key, const char *value)
+{
+ if (!strcmp(key, "core.inithook"))
+ init_hook = xstrdup(value);
+ return 0;
+}
+
+static int run_init_hook()
+{
+ const char *argv[2] = { NULL, NULL };
+
+ git_config(config_init_hook);
+ if (!init_hook)
+ return 0;
+ if (access(init_hook, X_OK) < 0)
+ return error("init hook '%s' not found", init_hook);
+
+ argv[0] = init_hook;
+ return run_command_v_opt(argv, 0);
+}
+
static const char init_db_usage[] =
"git-init [-q | --quiet] [--template=<template-directory>] [--shared]";
@@ -407,6 +430,9 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
git_config_set("receive.denyNonFastforwards", "true");
}
+ if (run_init_hook())
+ return 1;
+
if (!quiet)
printf("%s%s Git repository in %s/\n",
reinit ? "Reinitialized existing" : "Initialized empty",
diff --git a/t/t0001-init.sh b/t/t0001-init.sh
index c015405..7c18d24 100755
--- a/t/t0001-init.sh
+++ b/t/t0001-init.sh
@@ -113,4 +113,25 @@ test_expect_success 'GIT_DIR & GIT_WORK_TREE (2)' '
fi
'
+cat > init-hook.sh << EOF
+#!$SHELL_PATH
+
+git config test.message success
+EOF
+chmod a+x init-hook.sh
+
+# using reinit because of lacking system/global config in the tests
+
+test_expect_success 'core.initHook' '
+
+ mkdir hook &&
+ (cd hook &&
+ git init &&
+ test -z "$(git config test.message)" &&
+ git config core.initHook "$(pwd)"/../init-hook.sh &&
+ git init &&
+ test success = "$(git config test.message)")
+
+'
+
test_done
--
1.5.5.rc1.178.gd799d
Junio C Hamano
> diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
> index 03a4f0e..e082218 100644
> --- a/Documentation/git-init.txt
> +++ b/Documentation/git-init.txt
> @@ -60,6 +60,9 @@ If you are initializing a non-bare repository, the config variable
> `receive.guardCurrentBranch` is set to true. This avoids problems with
> pushing into the current branch, which does not touch the working tree.
>
> +If you want to run a specific script everytime git-init was issued, you
> +can set the variable `core.initHook`.
... in your $HOME/.gitconfig, naturally ;-)
I like the general idea, but with a few nits.
The hook might want to differentiate its behaviour based on how git-init
was invoked, don't you think? E.g. was it because the end user wanted to
create a new repo? Re-init? Clone, cvsimport or some other higher level
commands invoked git-init on the user's behalf?). The higher level ones
could communicate it via environment so we do not have to worry about them
too much (except perhaps in the documentation part to help hook writers),
but at least re-init is something init-db alone would be able to tell the
hook, so either a parameter to the hook or an environment exported to it
would be needed. The hook can figure out 'shared' and 'bare' by reading
from $GIT_DIR/config itself, but are there other things we may want to
tell the hook?
> +static int config_init_hook(const char *key, const char *value)
> +{
> + if (!strcmp(key, "core.inithook"))
> + init_hook = xstrdup(value);
> + return 0;
The current way to spell this is with git_config_string() to protect
yourself from segfaulting on:
[core]
inithook
> @@ -407,6 +430,9 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
> git_config_set("receive.denyNonFastforwards", "true");
> }
>
> + if (run_init_hook())
> + return 1;
> +
Hmm. Exit without a message even under !quiet?
Johannes Schindelin
This variable, if set, specifies the path of a hook which is executed
after every git-init. It can be used to override settings in the
templates per-user.
In case of a re-initialization, the hook gets called with the argument
"reinit".
Signed-off-by: Johannes Schindelin <johannes....@gmx.de>
---
On Mon, 24 Mar 2008, Junio C Hamano wrote:
> Johannes Schindelin <Johannes....@gmx.de> writes:
>
> > If you want to run a specific script everytime git-init was
> > issued, you can set the variable `core.initHook`.
>
> ... in your $HOME/.gitconfig, naturally ;-)
Naturally.
> I like the general idea, but with a few nits.
>
> The hook might want to differentiate its behaviour based on how
> git-init was invoked, don't you think?
Okay. It now gets an argument "reinit" when reinitialised. As
you said, the other usages (clone, cvsimport, ...) are a bit
fiddly to implement.
> > +static int config_init_hook(const char *key, const char *value)
> > +{
> > + if (!strcmp(key, "core.inithook"))
> > + init_hook = xstrdup(value);
> > + return 0;
>
> The current way to spell this is with git_config_string() to
> protect yourself from segfaulting on:
Yeah, sorry. Fixed.
> > @@ -407,6 +430,9 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
> > git_config_set("receive.denyNonFastforwards", "true");
> > }
> >
> > + if (run_init_hook())
> > + return 1;
> > +
>
> Hmm. Exit without a message even under !quiet?
Even under quiet, run_init_hook() will complain if the hook is
invalid.
Documentation/config.txt | 5 +++++
Documentation/git-init.txt | 6 ++++++
builtin-init-db.c | 28 ++++++++++++++++++++++++++++
t/t0001-init.sh | 21 +++++++++++++++++++++
4 files changed, 60 insertions(+), 0 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index efde54d..355f049 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -358,6 +358,11 @@ core.whitespace::
does not trigger if the character before such a carriage-return
is not a whitespace (not enabled by default).
+core.inithook::
+ The path to a program which is run after each call to
+ linkgit:git-init[1]. The hook is called with the argument
+ "reinit" if an existing repository is re-initialized.
+
alias.*::
Command aliases for the linkgit:git[1] command wrapper - e.g.
after defining "alias.last = cat-file commit HEAD", the invocation
diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt
index 03a4f0e..26deaaf 100644
--- a/Documentation/git-init.txt
+++ b/Documentation/git-init.txt
@@ -60,6 +60,12 @@ If you are initializing a non-bare repository, the config variable
`receive.guardCurrentBranch` is set to true. This avoids problems with
pushing into the current branch, which does not touch the working tree.
+If you want to run a specific script everytime git-init was issued, you
+can set the variable `core.initHook` in /etc/gitconfig or $HOME/.gitconfig,
+or in the existing repository when re-initializing. In the case that you
+reinitialize a repository, the hook is called with the single argument
+"reinit".
+
--
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 36c12a2..e1a54b5 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -6,6 +6,7 @@
#include "cache.h"
#include "builtin.h"
#include "exec_cmd.h"
+#include "run-command.h"
#ifndef DEFAULT_GIT_TEMPLATE_DIR
#define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates"
@@ -310,6 +311,30 @@ static void guess_repository_type(const char *git_dir)
return;
}
+static const char *init_hook;
+static int config_init_hook(const char *key, const char *value)
+{
+ if (!strcmp(key, "core.inithook"))
+ return git_config_string(&init_hook, key, value);
+ return 0;
+}
+
+static int run_init_hook(int reinit)
+{
+ const char *argv[3] = { NULL, NULL, NULL };
+
+ git_config(config_init_hook);
+ if (!init_hook)
+ return 0;
+ if (access(init_hook, X_OK) < 0)
+ return error("init hook '%s' not found", init_hook);
+
+ argv[0] = init_hook;
+ if (reinit)
+ argv[1] = "reinit";
+ return run_command_v_opt(argv, 0);
+}
+
static const char init_db_usage[] =
"git-init [-q | --quiet] [--template=<template-directory>] [--shared]";
@@ -407,6 +432,9 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
git_config_set("receive.denyNonFastforwards", "true");
}
+ if (run_init_hook(reinit))
+ return 1;
+
if (!quiet)
printf("%s%s Git repository in %s/\n",
reinit ? "Reinitialized existing" : "Initialized empty",
Junio C Hamano
> > > + if (run_init_hook())
> > > + return 1;
> > > +
> >
> > Hmm. Exit without a message even under !quiet?
>
> Even under quiet, run_init_hook() will complain if the hook is
> invalid.
Sorry, I may have been unclear but I was wondering more about the case the
hook script errored out silently.
Johannes Schindelin
This variable, if set, specifies the path of a hook which is executed
after every git-init. It can be used to override settings in the
templates per-user.
In case of a re-initialization, the hook gets called with the argument
"reinit".
Signed-off-by: Johannes Schindelin <johannes....@gmx.de>
---
On Mon, 24 Mar 2008, Junio C Hamano wrote:
Ooops. You're right. This is the interdiff:
diff --git a/builtin-init-db.c b/builtin-init-db.c
index e1a54b5..cdeb1d7 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -332,7 +332,8 @@ static int run_init_hook(int reinit)
argv[0] = init_hook;
if (reinit)
argv[1] = "reinit";
- return run_command_v_opt(argv, 0);
+ return run_command_v_opt(argv, 0) ?
+ error("hook '%s' failed", init_hook) : 0;
}
Documentation/config.txt | 5 +++++
Documentation/git-init.txt | 6 ++++++
builtin-init-db.c | 29 +++++++++++++++++++++++++++++
t/t0001-init.sh | 21 +++++++++++++++++++++
4 files changed, 61 insertions(+), 0 deletions(-)
index 36c12a2..cdeb1d7 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -6,6 +6,7 @@
#include "cache.h"
#include "builtin.h"
#include "exec_cmd.h"
+#include "run-command.h"
#ifndef DEFAULT_GIT_TEMPLATE_DIR
#define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates"
@@ -310,6 +311,31 @@ static void guess_repository_type(const char *git_dir)
return;
}
+static const char *init_hook;
+static int config_init_hook(const char *key, const char *value)
+{
+ if (!strcmp(key, "core.inithook"))
+ return git_config_string(&init_hook, key, value);
+ return 0;
+}
+
+static int run_init_hook(int reinit)
+{
+ const char *argv[3] = { NULL, NULL, NULL };
+
+ git_config(config_init_hook);
+ if (!init_hook)
+ return 0;
+ if (access(init_hook, X_OK) < 0)
+ return error("init hook '%s' not found", init_hook);
+
+ argv[0] = init_hook;
+ if (reinit)
+ argv[1] = "reinit";
+ return run_command_v_opt(argv, 0) ?
+ error("hook '%s' failed", init_hook) : 0;
+}
+
static const char init_db_usage[] =
"git-init [-q | --quiet] [--template=<template-directory>] [--shared]";
@@ -407,6 +433,9 @@ int cmd_init_db(int argc, const char **argv, const char *prefix)
Stephen Waits
go back to the fact that, a default installation should NEVER change
my files (in this case by trying to automatically translate line
endings)!
Please just disable it again, as it was before.
As on every other platform we can run git on, if we want to enable
autocrlf manually, it's easy enough to do.
The assumption that windows developers will all want this on by
default is unsupported, and I suspect, highly false.
Thanks,
Steve