patchTell vim the textwidth is 75.

When invoking EDITOR, add some metadata to tell vim the textwidth is 75.

Signed-off-by: Bryan Larsen <bryan.larsen@gmail.com>
---

 stgit/stack.py |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

I do not do Porcelain, but wouldn't it be nicer if we had a Porcelain neutral "commit log template file" under $GIT_DIR somewhere? 'vim: textwidth=75' is completely useless for somebody like me (I almost always work inside Emacs).

Cogito seems to use $GIT_DIR/commit-template for that purpose. Can't users put that "vim:" hint there, and if StGIT does not use a commit template, patch it to use the same file as Cogito does?

Junio C Hamano <junkio@cox.net> wrote:

StGIT uses .git/patchdescr.tmpl as the template, where people can put the a line like "STG: vim: textwidth=75" which will be automatically removed. I won't include this patch since it is up to the user to define whatever setting he/she wants for his editor (I use emacs myself and add something like "STG: -*- mode: text; -*-" on the first line)

I would use a neutral commit template, only that it should have a neutral prefix as well for the lines to be removed (neither STG nor CG but GIT maybe). The $GIT_DIR/commit-template is fine as a file name.

How about $GIT_DIR/commit-template-`basename $EDITOR` Then we could have different templates for vim, emacs, kade etc.

	Sam

Sam Ravnborg <sam@ravnborg.org> writes:

This brings up a point I have been wanting to see discussed, involving the core people and the Porcelain people [*1*].

I would like to see Porcelains stay compatible when the do not have to differ. The commit template [*2*] is one example of such. Another example is the "dontdiff/ignore" file Pasky talked about in a recent commit log in his Cogito tree [*3*].

Porcelains need to agree on what is placed where and used in what way.

First, I will talk about the "what" part. I can see there are various "preference" items we may want to use:

  - commit template (to enforce a certain style)
  - standard "dontdiff/ignore" file.
  - pre-commit hook (to enforce a certain tests to pass)
  - post-commit-hook (sending commit-notification perhaps).
  - environment overrides (COMMITTER_NAME, COMMITTER_EMAIL and
    such).

There may be others.  Many of them would have different origin:

  - Per project.  A project may want to enforce pre-commit hook
    for all participants;

  - Per user.  A user may want to use different environment
    settings for different projects [*4*].

  - Per repository (or work tree).  A user may have more than
    one work tree for the same project, and want to use
    different "preference" items per tree.

Personally, given the nature of GIT being a distributed system, I do not think something like /etc/git.conf (which suggests "per system" configuration) makes much sense; except working around a mailhost name configuration, perhaps.

About the "where" part, one proposal I have off the top of my head is something like this:

  - Have a directory at the root of the tree, "_git" (I do not
    care about the name at this moment.  The point being it can
    be revision controlled as part of the project and propagate
    to other repositories), to store per-project configuration.

  - Use $GIT_DIR/conf/ as a convention to store per repository
    configuration files.  This does not propagate with
    pulls/pushes/merges across repositories.

  - 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.

Which configuration is read first, what can be overridden, and if the configuration is cumulative would be specific to each preference item, I suspect. Some project may not want a user to override the pre-commit hooks, for a bad example. But normally the per-repository one would take precedence over per-user one which in turn would take precedence over per-project one.

[Footnotes]

*1* Technically this does not involve the core at all, but the core people can act as objective, Porcelain-neutral referees. They'll need to know the outcome of the discussion anyway, since they are the ones that end up maintaining the Porcelain-neutral tutorial document.

*2* Unless we are talking about the kind that shows and lets you edit the diff to be committed, which somebody else's Porcelain may support, that is.

*3* .gitignore in the cwd is used in Cogito, if I am not mistaken.

*4* E.g. I would commit for GIT project with junkio@cox.net while using junio@twinsun.com for my day-job projects.

Dear diary, on Fri, Jul 22, 2005 at 10:39:06PM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

Yes, I always try to make things as Cogito-unspecific as possible.

I wouldn't distinct between those two. You as a user can copy things around when you clone the repositories (if you ever do so), or the Porcelain can do it, but having global per-user _combined with per-project settings sounds nightmarish. After all, how do you identify a project? What if projects merge? I wouldn't open this can of worms.

Obviously, there have to be just per-user settings (independent of "project").

Fine, but I would probably prefer having it hidden. .gitinfo?

That's fine by me. I'd prefer the hooks staying in $GIT_DIR/hooks/.

As long as I can sanely parse it in shell... ;-)

What about just running all the hooks in the order you specified?

FWIW, I'm planning something like this in cg-commit (when called explicitly with -d) in short-term future.

Yes. There were several discussions about this in the past, with no clear outcome, IIRC. I would prefer:

  ~/.git/ignore per-user
  /.git/ignore per-repository
  .gitignore per-directory (cummulative with parent directories)

Note that I also want to make use of some special characters in this file. In particular /^# and /^!, to make it at least as powerful as CVS' ignore.

.git/author in current Cogito (.git/conf/author or something in the Brave New World ;-).

Petr Baudis <pasky@suse.cz> writes:

I'd like to extend "--exclude" and friends git-ls-files takes the following way (strawman). I'd appreciate your input from the perspective of Porcelain writers, and somebody who ends up having to use the bare Plumbing.

I'll be sending patches for actual implementation in separate messages.

------------ 'git-ls-files' can use a list of "exclude patterns" when traversing the directory tree and finding files to show when the flags --others or --ignored are specified.

These exclude patterns come from these places:

 (1) command line flag --exclude=<pattern> specifies a single
     pattern.

 (2) command line flag --exclude-from=<file> specifies a list of
     patterns stored in a file.

 (3) command line flag --exclude-per-directory=<name> specifies
     a name of the file in each directory 'git-ls-files'
     examines, and if exists, its contents are used as an
     additional list of patterns.

An exclude pattern file used by (2) and (3) contains one pattern per line. A line that starts with a '#' can be used as comment for readability.

The list of patterns that is in effect at a given time is built and ordered in the following way:

 * --exclude=<pattern> and lines read from --exclude-from=<file>
   come at the beginning of the list of patterns, in the order
   given on the command line.  Patterns that come from the file
   specified with --exclude-from are ordered in the same order
   as they appear in the file.

 * When --exclude-per-directory=<name> is specified, upon
   entering a directory that has such a file, its contents are
   appended at the end of the current "list of patterns".  They
   are popped off when leaving the directory.

Each pattern in the pattern list specifies "a match pattern" and optionally the fate --- either a file that matches the pattern is considered excluded or included. By default, this being "exclude" mechanism, the fate is "excluded". A filename is examined against the patterns in the list, and the first match determines its fate.

A pattern specified on the command line with --exclude or read from the file specified with --exclude-from is relative to the top of the directory tree. A pattern read from a file specified by --exclude-per-directory is relative to the directory that the pattern file appears in.

An exclude pattern is of the following format:

 - an optional prefix '!' which means that the fate this pattern
   specifies is "include", not the usual "exclude"; the
   remainder of the pattern string is interpreted according to
   the following rules.

 - if it does not contain a slash '/', it is a shell glob
   pattern and used to match against the filename without
   leading directories (i.e. the same way as the current
   implementation).

 - otherwise, it is a shell glob pattern, suitable for
   consumption by fnmatch(3) with FNM_PATHNAME flag.  I.e. a
   slash in the pattern must match a slash in the pathname.
   "Documentation/*.html" matches "Documentation/git.html" but
   not "ppc/ppc.html".  As a natural exception, "/*.c" matches
   "cat-file.c" but not "mozilla-sha1/sha1.c".

An example: 

    $ cat .git/ignore
    # ignore objects and archives, anywhere in the tree.
    *.[oa]
    $ cat Documentation/.gitignore
    # ignore generated html files,
    # except foo.html which is maintained by hand
    !foo.html
    *.html
    $ git-ls-files --ignored \
        --exclude='Documentation/*.[0-9]' \
        --exclude-from=.git/ignore \
        --exclude-per-directory=.gitignore

Add --exclude-per-directory=<name> option that specifies a file to contain exclude patterns local to that directory and its subdirectories. Update the exclusion logic to be able to say "include files that match this more specific pattern, even though later exclude patterns may match them". Also enhances that a pattern can contain '/' in which case fnmatch is called with FNM_PATHNAME flag to match the entire path.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 ls-files.c                         |  123 ++++++++++++++++++++++++++++++------
 t/t3001-ls-files-others-exclude.sh |   55 ++++++++++++++++
 2 files changed, 157 insertions(+), 21 deletions(-)
 create mode 100755 t/t3001-ls-files-others-exclude.sh

d1466fd8701ca79a91b41c6225c115a0a9866d6e

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 Documentation/git-ls-files.txt |   96 ++++++++++++++++++++++++++++++++++++++--
 1 files changed, 92 insertions(+), 4 deletions(-)

d9296497b70d9007da94cec453ecb5c6c7173140

Junio C Hamano <junkio@cox.net> wrote:

[...]

I think it would make more sense for the exclude-per-directory patterns to be local to that directory only, without recursively preserving them for subdirectories. One would, in general, put the common exclude patterns like *.o *~ etc. in the global file (.git/exclude). The patterns local to a directory only (take the vmlinux file for example), one would write it in the .gitignore file but this should be used for subdirectories.

[...]

That's fine. Actually, the Porcelain would care much about it since it gets the information already filtered by git.

Wouldn't it be clearer to have the general rules first (*.html), overridden by the more specific ones (!foo.html)? Just my opinion, I don't know what others think.

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

I personally do not have preference either way, but am slightly biased towards the "cumulative" behaviour the patch attempts to implement, which was what Pasky said he wanted to have.

    Date: Fri, 22 Jul 2005 22:59:48 +0200
    From: Petr Baudis <pasky@suse.cz>
    Subject: Re: [PATCH 1/1] Tell vim the textwidth is 75.
    Message-ID: <20050722205948.GE11916@pasky.ji.cz>

    > *3* .gitignore in the cwd is used in Cogito, if I am not
    > mistaken.

    Yes. There were several discussions about this in the past, with no
    clear outcome, IIRC. I would prefer:

      ~/.git/ignore per-user
      /.git/ignore per-repository
      .gitignore per-directory (cummulative with parent directories)

Your saying "fine" is a relief. This change aims at helping Porcelain people by making it less likely for Porcelain to need its own filtering. As you say, if ls-files filters more than the Porcelain wants, that's a bigger problem.

I do not know, either, but I do know it is consistent with the "first match determines fate" rule and cleaner to implement.

On Mon, 25 Jul 2005, Junio C Hamano wrote:

I think that makes sense.

Imagine, for example, that you have separate subdirectory structures for Documentation and for source - maybe you'd put the "*.o" rule in the source directory, and a "*.1" rule in the Docs subdirectory.

			Linus

Linus Torvalds <torvalds@osdl.org> writes:

I imagined it, but it appears to me that this is a bad example. My understanding of what Catalin and the proposed patch disagrees is whether the patterns in .gitignore at the top level should govern files under ppc/ and mozilla-sha1/ subdirectories; Catalin thinks they should not.

What I meant by "cumulative" (now I realize I might have misunderstood what Pasky wanted to mean by that word, though) was not just .gitignore in subdirectory being added, but the effect of patterns being added so far, either from the command line or by parent directories, last while in the deeper directories.

On Mon, 2005-07-25 at 13:27 -0700, Junio C Hamano wrote:

I really don't have a strong preference for this. Linus' example makes sense as well. It's up to you how you implement its behaviour, Porcelains shouldn't be affected by this.

Since I'm the only one with this idea, you can forget about it (I don't mind :-) ). If others express a preference for this, you could implement a 'cut' label (similar to Prolog's cut operator) which clears the pattern stack before diving into subdirectories. Anyway, I don't think it's worse the hassle since it might never be used.

Dear diary, on Mon, Jul 25, 2005 at 10:27:36PM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

They should. If you don't want them take effect in most of the directories, you would add them as ./pattern in the parent directory, while if you want them to take effect in most of the directories, you would exclude them in the ones you don't want the pattern to take effect in (if you accept my proposal for ! semantics change).

Yes, that's what I meant.

On Mon, 2005-07-25 at 12:58 -0700, Junio C Hamano wrote:

I don't plan to add any additional filtering in StGIT. What I meant above was that Porcelain would not care much about the patterns. The user should cope with what git provides, nothing more. With these git patches, I think there are enough features for filtering.

I also don't have a strong preference for this and the "first match" rule clarifies it (otherwise, you could have pushed them on a list in reverse order).

  Hello,

  after skimming through it, I think I completely like what you have
shown here. I'm only concerned about this:

Dear diary, on Mon, Jul 25, 2005 at 12:49:33AM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

  I think this is wrong, and my brief experiments confirm that. I think
that the actually useful semantics of exclusion would be for
_subsequent_ exclusions, not preliminary ones. You generally don't say
"I never want this ignored, but I want the rest of that ignored", but
"I want that ignored, except this". This also gives you more
flexibility:

	*.html
	!f*.html
	fo*.html

would ignore *.html and fo*.html, but not any other f*.html filenames. But more importantly,

	.gitignore: *.txt
	Documentation/.gitignore: !*.txt

will not work, which was the whole _point_ of the exclusion.

Could we please have this semantics changed for those reasons?

Thanks,

Petr Baudis wrote:

So you're arguing for "last match wins" versus "first match wins". I, personally, find the former more natural and easier to debug by hand.

Hi, A Large Angry SCM wrote:

You know, up until five minutes ago, I thought so too.

However ... as a human being, I liik for meaning, not for processing instructions. Thus, reading the list top-down, this

makes perfect sense to me. ("Throw away the HTML files. Well, except for those that start with 'f'. Well, *except* for foobar.html or whatever.")

The other way round, however, the sequence

is not immediately understandable in one pass, as the second line makes no sense whatsoever without the third one. ("Throw away foobar.html. Umm, we're keeping everything anyway, so why ... oh, HTML files are junked, OK, so ... now ... umm, what did I want to find out in the first place?")

It gets even more confusing when you're lazy and omit the .html suffix in the second line.

YMMV, and all that.

Dear diary, on Thu, Jul 28, 2005 at 09:25:45PM CEST, I got a letter where Matthias Urlichs <smurf@smurf.noris.de> told me that...

So is the Large Angry SCM agreeing with me or not? I wrote long reply to his mail, then reread what he wrote again, and decided that he is _agreeing_ with me and you that "last match wins" is better. :-)

Hi,

Petr Baudis:

Bah, I misparsed his sentence (I read "former" as "first wins"), otherwise my reply would have been worded slightly differently.

Petr Baudis wrote:

*Oops!*

Yes, it looks that way doesn't it. But I had accidentally [*1*] typed "former" where I wanted "later". Either way works as long as it's well documented/understood.

[*1*] Either too much or too little caffeine at the time I suspect.

Petr Baudis <pasky@suse.cz> writes:

OK.

I agree that this is a bigger issue.

My updated proposal is as follows:

 * We collect --exclude patterns in "command line patterns"
   list, in the same order as given on the command line.

 * We collect patterns read from the files specified with
   --exclude-from in "exclude-from patterns" list, in the same
   order as given on the command line and the same order
   patterns appear in the file.

 * While we descend the directories, files named by EPD flag, if
   found, are read from top to bottom and concatenated into the
   "per directory patterns" list.  When leaving the directory,
   the patterns read from that directory's EPD file are popped
   off.

 * When checking a file to see if it is excluded, we first look
   at "exclude-from patterns" list, then "per directory
   patterns" list, and then "command line patterns list", in
   that order.  The last match wins [*1*].

An example:

You have three files in your git source tree and your $HOME:

    git/.gitignore                      lists patterns A and B
    git/Documentation/.gitignore        lists patterns C and D
    git/.git/info/ignore                lists patterns E and F
    $HOME/.gitrc/ignore                 lists patterns G and H

You say:

    git-ls-files --others \
        --exclude=I --exclude=J \
        --exclude-from=.git/info/ignore \
        --exclude-from=~/.gitrc/ignore \
        --exclude-per-directory=.gitignore \

While in git/ directory itself, the following patterns are checked and the last match wins:

    E F G H   A B       I J

When we descend into git/Documentation, the list of patterns used becomes the following, still the last match wins:

    E F G H   A B C D   I J

The reason --exclude-from comes first (i.e. having the least say in the outcome) and --exclude comes last (i.e. having the most say) is because the former is to give the overall fallback default, and the latter is the ultimate end user preference.

Does this sound reasonable?

[Footnote]

*1* In real implementation, I would probably scan in reverse from the end and stop at the first match, but that is an implementation detail.

Dear diary, on Fri, Jul 29, 2005 at 07:04:36AM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

Hmm. What about just excluding the files according to the order of parameters on the command line?

Here, the question is whether the GIT Core tools should provide full flexibility and friendness to custom use, or rather serve as tighter unifying layer for the porcelains, enforcing certain conventions. That's up to you to decide, obviously, but perhaps someone will want to use the exclude mechanisms for something else than the "classic" other files ignoring stuff, and generally more flexibility might be better. So I'd argue for codifying those conventions at the level of the porcelain users and not enforcing them in git-ls-files itself.

Petr Baudis <pasky@suse.cz> writes:

While I would in principle prefer to offer more freedom to shoot yourselves in the foot ;-), the pragmatic side of me says too much flexibility is just asking for trouble with not much additional gain. For example, your "generic first, and then list exceptions" argument convinced me to shelve the "first match wins" rule, but I _could_ have added an extra option to allow other Porcelain writers who want to have "most number of match wins" rule while at it. I didn't. Let's wait and see if somebody else comes up with a different use scenario that would be useful in real life.

In the meantime, the current one is clearly broken as you pointed out, so let's replace it with the updated "generic rule with the following exceptions" one.

Dear diary, on Fri, Jul 29, 2005 at 10:24:54AM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

That's fine by me. I would only like to ask the Porcelain authors to keep their git-ls-files exclude parameters order matching the internal ordering so that when we indeed change it in the future to follow the commandline order, the Porcelains won't break.

On 7/29/05, Junio C Hamano <junkio@cox.net> wrote:

For an example of just how far you can go down the road to mind numbing complexity try reading the rsync manpage about how to exclude files.

-Wayne

Pasky and others raised many valid points on the problems initial exclude pattern enhancement work had. Based on the list discussion, rework the exclude logic to use "last match determines its fate" rule, and order the list by exclude-from (the fallback default pattern file), exclude-per-directory (shallower to deeper, so deeper ones can override), and then command line exclude patterns.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 ls-files.c |  100 +++++++++++++++++++++++++++++++++++++++++++-----------------
 1 files changed, 72 insertions(+), 28 deletions(-)

a908ed1b0fed52bfdcfc8b3ada366ce05e44c887

Update the tests and documentation to match the new "last one determines its fate" semantics.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 Documentation/git-ls-files.txt     |   27 ++++++++++++++-------------
 t/t3001-ls-files-others-exclude.sh |   23 ++++++++++++++++++-----
 2 files changed, 32 insertions(+), 18 deletions(-)

4ae2315518ee4017c6646a4421cf448297fc6dcc

On Fri, 2005-07-22 at 13:39 -0700, Junio C Hamano wrote:

For StGIT it is not a problem to use any commit template with any prefix. It doesn't generate extra 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.

OK

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.

OK

StGIT works the other way around. By default uses the environment, which can be overridden by the stgitrc file. I could change this easily.

As Petr said, it's hard to define a project.

StGIT uses /etc/stgitrc, ~/.stgitrc and .git/stgitrc, the latter overriding the former.

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.

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.

Once you get unique settings for an application (like mail templates or three-way merge commands), it's pretty hard to put them in the same file. It would even be confusing for users.

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 fine.

Again, having Porcelain specific options mixed in the same file might lead to some confusion among users.

With a note if specifying what a project is.

I will to add this to StGIT.

In StGIT this is settable via authorname/authoremail in the stgitrc file and can be per repository or per user.

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

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.

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.

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.

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.

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.

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").

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.

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_.

On Fri, 2005-07-22 at 16:07 -0700, Junio C Hamano wrote:

That's an idea.

Another problem with the template is when one wants a header as well as footer (for things like '-*- mode: text; -*-'). Maybe something like below would work:

GIT: your header
@DESCRIPTION@
GIT: your footer
GIT: @FILELIST@

where @DESCRIPTION@ is either a blank line for cogito or the existing patch description for StGIT. One could also add a 'Signed-...' line when the patch is first created (instead of a blank line).

For StGIT, one could add something like @PATCHNAME@ as well.

.gitignore are note currently supported by StGIT but I'll add this.

The problem appears when one upstream maintainer changes the configuration, should this be merged again? In this case you can get conflicts.

This is not always the case. With StGIT you can define your own options and tools for a three-way merge. This was implemented because Bryan Larsen, I think, asked whether a different (smarter) tool could be used. One might also want that when diff3 fails, a xxdiff or emacs should be automatically started for the conflict files.

This could be simplified if we enforce the presence of a gitmerge.sh file which only calls merge or diff3 by default. Users can create a new file and put it in the $PATH.

That's probably a good reason. Also people might use 2 Porcelains and the plain git, they could have a common configuration, especially where settings overlap.

I like it too.

That's OK with one issue - git should be able to exclude _git when generating a diff between 2 trees, unless one can enforce the _git/* files to be read-only.

Another option would be to have .git/info/<branch> and, with cogito for example, .git/info/origin should always be pulled, even if the local files were modified. You would override these settings in .git/info/master. The problem is to define the branches order in which the settings are read.

This could be avoided by using ini-like files (well, easy to read in Python) and have [git] (for the common things like author name), [cogito], [stgit] etc. sections.

I don't think this is a waste of time. It's useful to have at least some basic conventions. StGIT places files all over the place but without any convention, not even a .stgit extension.

The problem is how much similar we want the Porcelains to be regarding the settings and the templates. For StGIT, it is much simpler to have something like '%(FILELIST)s' rather than '@FILELIST@' in a template but I have not problem with switching to a common syntax. But we should see what can easily be changed.

I will write a list with what files StGIT uses and where they are placed and we can agree on a structure. I think the .git/ directory usage is more important to be clarified than having a common {git,cogito,stgit}rc file.

Dear diary, on Sat, Jul 23, 2005 at 10:41:38AM CEST, I got a letter where Catalin Marinas <catalin.marinas@gmail.com> told me that...

Great idea.

So you resolve them...? If the upstream keeps doing changes frequent enough and large-scale enough to this becoming annoying, something is wrong. :-)

Why? I think those meta-information is important too, and if it differs, I want to see it in the diff. Oh, now I see what you mean - to optionally exclude it. That would be nice, having --exclude in common diff options.

Yes, and you may be pulling from multiple branches. I would keep .git/info simple and single-instanced. If you want your stuff to propagate to others, put it to .gitinfo/.

Now if it is going to look like this, I think separate files would be much more practical, more effective and likely simpler for the user as well. For Cogito-specific stuff, the user can well dive into Cogito-specific configuration files, I think. (Well, there's none now; there is .cgrc but that only contains default options for Cogito commands and will stay so; I plan ~/.cg/cogito.conf or something. Actually, perhaps the Git configuration file should be ~/.git/git.conf - it looks cool, doesn't it?)

I chose @FILELIST@ only since it is a common convention to have this as rewrite placeholders, and I think it's more visually clear than %(FILELIST). Were you insisting on the second syntax, I wouldn't have %any problem switching, though. Cogito does no @@ rewriting yet.

Agreed. What Cogito uses:

	.git/author	Default author information in format
				Person Name <email@addy>

	.git/branch-name
			Symbolic name of the branch of this repository.
			This is purely descriptive, does not need to be
			unique and is used only in commit-post. I need
			to distinguish commits done in git-pb and Cogito
			so that's the contents of this file in those two
			repositories. Quite ad-hoc and deserves a better
			solution, but I have none so far; in the future,
			I might just have shared repository for those
			two and use the head name.

	.git/commit-template
			Commit template to use in the commit editor
			instead of some short header (most of it is
			still hardcoded).

	.git/exclude	--exclude-from for git-ls-files
			I want to rename this to .git/ignore

	.git/hooks/commit-post
			COMMIT-ID BRANCHNAME
			(could be <headname> if no branchname defined)

	.git/hooks/merge-pre
			BRANCHNAME BASE CURHEAD MERGEDHEAD MERGETYPE
			MERGETYPE is either "forward" or "tree".
			The merge is cancelled if the script returns
			non-zero exit code.

	.git/hooks/merge-post
			BRANCHNAME BASE CURHEAD MERGEDHEAD MERGETYPE STATUS
			MERGETYPE is either "forward" or "tree".
			For "forward", the STATUS is always "ok",
			while for "tree" the STATUS can be
			"localchanges", "conflicts", "nocommit",
			or "ok".

On Sat, 2005-07-23 at 11:30 +0200, Petr Baudis wrote:

OK, that's fine with me (but see below).

That's useful when generating patches.

The other problem is that the upstream maintainer might not be interested in my own settings but they would be pulled together with the normal data.

Yes, my idea complicates things quite a lot.

Or we could have ~/.git/git.conf, ~/.git/cogito.conf and ~/.git/stgit.conf, under the same directory.

It's true that @...@ is a common convention and is much clearer. I chose my syntax since it was easier to format the strings in Python. If we go for a common template, I would prefer the @...@ one (and do a regexp replace in Python instead of the string formatting).

What about .git/committer? This is useful if I do a commit at work and I want the repository to have my gmail address.

Isn't this the same as $(readlink .git/HEAD), with some trimming?

OK

OK, either name is fine with me.

OK, though StGIT doesn't use any at the moment.

Now, the StGIT files (.git means $GIT_DIR):

      * /etc/stgitrc, ~/.stgitrc, .git/stgitrc - configuration files
        (the latter overrides the former). The syntax is similar to the
        ini files
      * .git/patches/ - directory containing the patch information. I
        won't go into details here since this is only used by StGIT
      * .git/exclude - for the files to be ignored by the 'status'
        command
      * .git/conflicts - includes the list of files conflicting after a
        merge operation. The user should run 'stg resolved --all' to
        mark the conflicts as resolved and remove this file
      * .git/branches/ - the same meaning as in cogito, only that
        'master' is considered a branch and 'stg pull' doesn't use
        'origin'
      * .git/patchdescr.tmpl - the same idea as commit-template, used
        when creating the first description for a patch
      * .git/patchexport.tmpl - template used when exporting the patches
        in a series
      * .git/patchmail.tmpl - template used for sending patches by
        e-mail

Catalin Marinas wrote:

It seems I inadvertantly kicked off the discussion I wanted to kick off, but I didn't excpect this patch to do so!

I prepared a patch adding the following information into git/Documentation to kick off discussion. Obviously Catalin is more likely to be accurate.

how about:
  .git/refs/heads/master - documented in README, doesn't appear to be used.
.git/firstmail.tmpl - template used for sending the preamble email

On Sat, 2005-07-23 at 12:33 -0400, Bryan Larsen wrote:

That's true, README is quite outdated. I created the http://wiki.procode.org/cgi-bin/wiki.cgi/StGIT page (empty now) where I will add StGIT information and a tutorial. I will probably keep the README to a minimum and just point people to the wiki page.

This file is not used by StGIT. I put it there as an example and you can use it with the --first option of 'mail'. The reason for this is that you need to modify this file every time you send a patch series, unlike the patchmail.tmpl file.

Dear diary, on Sat, Jul 23, 2005 at 12:27:31PM CEST, I got a letter where Catalin Marinas <catalin.marinas@gmail.com> told me that...

The committer field generally identifies the committer "physically", and isn't usually overriden. You'll find <xpasky@machine.sinus.cz> in my committer field, e.g.

No, that is something totally separate from the usual concepts of branches and repositories, designed to make it possible to distinguish between repositories etc. from the outside of the system.

Petr Baudis <pasky@suse.cz> writes:

I do not want to get involved in policy decisions, but for the record I always hated your commit log for that "identifies the committer physically" approach.

On Thu, 28 Jul 2005, Junio C Hamano wrote:

Well, I have to say that I find it quite useful myself. I try to commit x86 patches to the kernel on an x86 machine (I had better had tested them there), so they usually say "torvalds@evo.osdl.org" or "torvalds@yonah..", while my normal patches tend to say "torvalds@g5.." since that's my main machine.

So I tend to not override it, even though none of those are really valid email addresses.

		Linus

Petr Baudis <pasky@suse.cz> wrote:

I thought GIT_COMMITTER_{NAME,EMAIL} were added to be able to override the defaults like username@localmachine.

The latest StGIT snapshot uses, by default, the committer's details for the From: line when sending patches by e-mail, assuming that this is a valid e-mail address. One can define his own e-mail template and use a different From: line but I thought it would be simpler to provide some defaults based on this.

If StGIT users don't like this default template, I can change it.

Dear diary, on Fri, Jul 29, 2005 at 11:55:52AM CEST, I got a letter where Catalin Marinas <catalin.marinas@gmail.com> told me that...

Yes, but IIRC only for rather special cases like recommitting older commits, importing from other VCSes, etc.

Why don't you rather use the GIT_AUTHOR_* variables?

Petr Baudis <pasky@suse.cz> wrote:

It was simpler since the template variables were based on the patch details. Anyway, it's not hard to modify.

Petr Baudis <pasky@suse.cz> writes:

My recollection coincides with Catalin. Special case is when you set it to somebody else, "logically" different from you, as you say. Fixing GECOS fields and mailhost settings as Catalin says is another.

Setting it to something "physically" different but still the same you, for example using your work e-mail address when you are on your home machine, is not special case at all, but is also a valid use. However when you start to do that, it may become unusable as a valid e-mail address you can use for From: and/or Sender: fields.

I tend to agree. When forwarding somebody else's commit as a patch, you would want to name that author on From: line and make yourself Sender:. Of course, in that case Sender: should be a valid e-mail address for the originating machine; otherwise bogus-mail-relay prevention would block your e-mail. In that sense, using COMMITTER to identify you "physically" (meaning: tied to your identity with that particular machine) would work better.

Dear diary, on Sat, Jul 23, 2005 at 01:07:05AM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

I would rather have something universal. Just avoid inserting duplicate lines at the bottom.

Cogito supports .git/exclude too, but I'd rather rename it to .git/ignore (or .git/conf/ignore) as well (gradually).

I have it the other way around, with the rationale that your default settings should be in your ~/.gitrc, not environment, which is always the highest priority. The simple reason is that how would I apply the patches of other people otherwise? Now I do

	GIT_AUTHOR_NAME="Junio C Hamano" \
		GIT_AUTHOR_EMAIL="junkio@cox.net" \
		GIT_AUTHOR_DATE="2008-04-01 05:12:33" \
		cg-commit

and it makes complete sense to me.

diff3 throws its output on stdout, AFAIK.

Yes, but it is a bit secondary to me. The most important for me is that meta-files inside the project itself (e.g. .gitignore) should be as portable as possible, as that'd be the biggest hurdle. The second priority for me is to make ~/.git/ as universal as possible. Having common per-user/per-system configuration file as well is nice too, but not so crucial.

(Quite some things came to git from Cogito anyway. ;-) And well, that's completely natural.)

No, I think it's great. That increases the locality of things, which is good. Think about it as of variables - it's nicer to have them local. Also, with a central .gitignore file, how do you specify "Ignore all *.html files under Documentation/" or so? (Without having ** - or you need to support that one too to make the central .gitignore feasible. But I think that in that case, it would depend on the user whether he defines things in the central .gitignore or in subdirectories.)

I don't think it is moot at all. (But see above - if we can't agree on everything, I would much rather have common stuff in the project tree than in ~ - there's not so much trouble of having multiple sets in ~, but it's annoying to have e.g. .stgitignore, .cgignore and .jitignore in each directory of the project, and if one project developer moves to another Porcelain, having to add another set of files, and then keeping them all up to date...)

Petr Baudis <pasky@suse.cz> writes:

That's true. I just never hand commit other people's patches (I use applymbox for that) and never needed to give one-shot set of environment variables to commit-tree by hand from the command line.

I am not the one who did the barebone, so I'd let Linus to tell "coming from" and "done independently while retaining compatibility" apart if he wants to ;-).

Seeing Catalin also expressed the intention to add .gitignore in directory tree everywhere, I would keep my personal opinion to myself.

How about we do something like this:

    git-ls-files --others
        --exclude-from=.git/ignore \
    	--exclude-per-directory=.gitignore

When the new flag --exclude-per-directory is specified, git-ls-files uses the file with that name in each directory it looks at to match against the files in that directory (and its subdirectories, perhaps?) just like it uses --exclude-from for the entire tree today.

If I added that, would both of you be able to lose a lot of lines from cg-status and git.__tree_status()? If so, then that is worth the core-side support.

What should the pattern matching rules be? I think the current git-ls-files one may be a bit too weak.

On Fri, 2005-07-22 at 19:24 +0000, Sam Ravnborg wrote:

I'm not sure this is worth the hassle since a person usually sticks with one editor, I don't see why one would use different $EDITOR variables with the same project.

Dear diary, on Fri, Jul 22, 2005 at 12:37:05PM CEST, I got a letter where Catalin Marinas <catalin.marinas@gmail.com> told me that...

This unfortunately isn't that simple, since this file substitutes only the

	CG: -----------------------------------------------------------------------
	CG: Lines beginning with the CG: prefix are removed automatically.

snippet of the file. The trouble is, Cogito autogenerates most of the rest of it. Would the acceptable solution be that I would have @CG_FILELIST@-style placeholders there, and any tool processing the file would simply drop lines containing @ directives it does not understand? (@@ is escaped @)

I have nothing against changing the prefix to GIT:.

Then, Cogito's default commit-template would look like

	GIT: -----------------------------------------------------------------------
	GIT: Lines beginning with the GIT: prefix are removed automatically.
	GIT:
	GIT: Author: @AUTHOR_NAME@
	GIT: Email: @AUTHOR_EMAIL@
	GIT: Date: @AUTHOR_DATE@
	GIT:@CG_SHOWFILES@@CG_NOMERGE@
	GIT:@CG_SHOWFILES@@CG_NOMERGE@ By deleting lines beginning with GIT:F, the associated file
	GIT:@CG_SHOWFILES@@CG_NOMERGE@ will be removed from the commit list.
	GIT:@CG_SHOWFILES@
	GIT:@CG_SHOWFILES@ Modified files:
	GIT:@CG_SHOWFILES@F   @FILELIST@
	GIT: -----------------------------------------------------------------------
	GIT: vim: textwidth=75

(where CG_SHOWFILES is defined only when the list of the files is to be shown and CG_NOMERGE only when there is no merge going on).

Wonderful start.

Later on, Porcelains could agree on what @TOKEN@ are generally available, and even start using a common script to pre-fill the templates, like:

  $ git-fill-template-script <template> <output-file> var=val var=val...

In your example, I see AUTHOR_NAME, AUTHOR_EMAIL, and AUTHOR_DATE (I'd use GIT_AUTHOR_NAME etc to match existing environment variables, though) would be something that are probably common across Porcelains, and the Porcelain would not even have to bother passing them as the command argument to fill-template. About FILELIST, the default would be to do "git-diff-cache --name-only HEAD", but if a Porcelain keeps track of "modified" files differently it can be overridden by passing FILELIST as an explicit parameter.

Dear diary, on Fri, Jul 22, 2005 at 11:16:51PM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

Good idea. More interesting exercise would be to make a script which extracts the values back after the user had a chance to touch it.

Cogito shows '[NMD] filename' in place of @FILELIST@.

This brings me to another subject, M and N are pretty hard to distinguish visually without close inspection of the output. What about switching to use A instead of N everywhere?

Petr Baudis <pasky@suse.cz> writes:

Sounds sensible. Does it parse it to limit the files to be committed?

Although I admit that is minor, I've had the same problem, and this sounds like a good idea.

However, I'd like to see what the extent of damage would be even if everybody agrees this is a good change. Any one of core barebone Porcelain, Linus git-tools, gitk, gitweb, Cogito, and StGIT would have a veto over this kind of change, or at least we should wait until everybody catches up.

If we all decide to go ahead, the transition would not be so painful, since we do not currently say 'A', the Porcelains can start accepting 'A' as synonym for 'N' today, and then later we can change the tools to produce 'A' instead of 'N'.

Dear diary, on Sat, Jul 23, 2005 at 01:24:35AM CEST, I got a letter where Junio C Hamano <junkio@cox.net> told me that...

Yes.

I don't think the situation is so bad. At least in Cogito, there is only one use of 'N' (and cg-status, but that goes directly to the user), and it's likely useless and things would work even with that changing to 'A' (nevertheless, I just updated Cogito to accept 'A' at that place as well).

On Fri, 2005-07-22 at 16:24 -0700, Junio C Hamano wrote:

Using A instead of N is not a problem for StGIT (and I would prefer A since it's easier to read). I could also only change the StGIT output even if git uses N.

Since both of you seem to be in favor of using 'A' instead of 'N' for added files in the diff-raw output, here are two patches requesting for test.

  [PATCH] Use symbolic constants for diff-raw status indicators.
  [PATCH] diff-raw: Use 'A' instead of 'N' for added files.

Both Cogito and StGIT prefer to see 'A' for new files. The current 'N' is visually harder to distinguish from 'M', which is used for modified files. Prepare the internals to use symbolic constants to make the change easier.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 diff-helper.c |    3 ++-
 diff.c        |   58 ++++++++++++++++++++++++++++++++-------------------------
 diff.h        |   16 ++++++++++++++++
 3 files changed, 51 insertions(+), 26 deletions(-)

e7baa4f45f4420a6d2da6a13e8959f8405c3ea19

This actually changes the diff-raw status letter from N to A for added files.

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

 diff.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

ca8c9156f8f980455f64e2cedcf0347328e46029