Re: [PATCH 1/1] Tell vim the textwidth is 75.

From: Junio C Hamano <junkio@cox.net>
Date: Jul 22, 2005, 23:07 UTC
Message-ID: <7vu0imh23q.fsf@assigned-by-dhcp.cox.net>
In-Reply-To: <1122068634.7042.35.camel@localhost.localdomain>

Catalin Marinas <catalin.marinas@gmail.com> writes:

Show 7 quoted lines

> Would such a template only have 'GIT:' prefixed lines? I usually put
> another line like 'Signed-off-by:', for convenience. The problem with
> StGIT appears when one wants to re-edit the patch description (stg
> refresh -e), in which case the existing description should be merged
> with a part of the template (if you want to get the editor setting for
> example). It doesn't do this since there is no point in getting another
> 'Signed...' line in the existing description.

If signed-off-by is the only thing you are worried about, how about making it not part of the commit template and the message user touches with the editor? You first look at the user configuration somewhere to see if the user wants the signed-off-by line to his commits and with what value, and if the last lines of the edit result does not contain that value (to avoid duplicates), add it before feeding the message to git-commit-tree.

Show 5 quoted lines

>>   - standard "dontdiff/ignore" file.
>
> StGIT currently uses .git/exclude, since I saw it used by cogito. What
> is dontdiff supposed to do? The 'git diff' command only shows the diff
> for the files added to the repository.

I see that what I wrote was vague and badly stated. Please forget about my mentioning "dontdiff". What I meant was your .git/exclude, Pasky's .gitignore file and friends.

Show 5 quoted lines

>>   - environment overrides (COMMITTER_NAME, COMMITTER_EMAIL and
>>     such).
>
> StGIT works the other way around. By default uses the environment, which
> can be overridden by the stgitrc file. I could change this easily.

Again I was vague, and what you say StGIT does is exactly what I meant. I have one value in my environment coming from the login shell, and a per- repository preference item overrides it to something else.

>>   - Per project.  A project may want to enforce pre-commit hook
>>     for all participants;
>
> As Petr said, it's hard to define a project.

By reading the part you talk about your hating tla, I think you know exactly what I mean.

When you merge two projects like Linus did between git.git and gitk, obviously the person who is merging the two is responsible for merging the per-project default configuration and resolving conflicts. This probably should be overridable by individual developers who pull/fetch into their repository by having per- repository configuration.

> For StGIT it makes sense to get some default settings via /etc/stgitrc.
> There are things like a SMTP server and the diff3 command. These are set
> when installing the application and can be overridden in your home
> or .git directories.

Exactly, but that is not specific to StGIT, I presume, and I did not want to hear "``For StGIT'' it makes sense". If StGIT needs to use "diff3" on a system, probably that is because "merge" is not available on that system. In that case, cogito needs to use it too, doesn't it?

If we can make users and sysadmins not having to maintain two sets of configuration files for two Porcelains, if we can,... that is what I have been trying to address.

> Before we get to "where", we should define the common
> settings. I think that git should define the common settings
> for its operations and the other tools should follow them.

Personally, unless it is something very obvious and basic, I do not think the core barebone Porcelain should be inventing arbitrary conventions and imposing them on other Porcelains. For very basic things I would agree.

I think Petr already started the discussion rolling for commit templates, and I like his proposal. For ignore pattern files, I think what Cogito does sounds almost sensible [*1*] and I am sure StGIT have something similar. I do not see Linus and co jumping up and down saying git-status should detect and show new files not registered in the cache, so for now I'd propose to skip adding this one to the barebone Porcelain (meaning, this is an example of not "git defining the common and others following suite").

Show 5 quoted lines

> That's the thing I didn't like in GNU Arch. You modify the file ignoring
> rules for example and the change will be included in the next commit.
> You could only get some defaults when cloning a repository, otherwise
> once you have different preferences from the repository's maintainer,
> you start getting conflicts in the config files.

That's why I suggested to have "_git" (project wide default) separate from $GIT_DIR/info (repository owner's discretion), the latter overriding the former.

Show 6 quoted lines

>>   - Use $HOME/.gitrc (could be a directory or a file in .ini
>>     style like StGIT uses -- again, I do not care about the
>>     details at this moment) to store per-user configuration.
>
> Again, having Porcelain specific options mixed in the same file might
> lead to some confusion among users.

True.  We need to be careful.

Or course, there is an option of not worry about Porcelain compatibilities at all --- which is certainly simpler. All we need is to make sure they do not use the same filename for conflicting purposes. If everybody feels that way then this discussion is moot and I apologize for wasting people's time.

[Footnote]

*1* I said "almost sensible" but it is not meant to blame Pasky. I think the --exclude mechanism in git-ls-files should be extended to allow not just the filename-sans-leading-directory match but a full relative-to-the-project-root path match. That way, cg-status would not have to run around in the tree to find individual .gitignore files.

Personally, I think having to have ignore pattern like .cvsignore per-directory is simply _ugly_.