Re: [PATCH 1/1] Tell vim the textwidth is 75.
Dear diary, on Fri, Jul 29, 2005 at 11:55:52AM CEST, I got a letter
where Catalin Marinas [EMAIL PROTECTED] told me that...
Petr Baudis [EMAIL PROTECTED] wrote:
The committer field generally identifies the committer physically, and
isn't usually overriden. You'll find [EMAIL PROTECTED] in my
committer field, e.g.
I thought GIT_COMMITTER_{NAME,EMAIL} were added to be able to override
the defaults like [EMAIL PROTECTED]
Yes, but IIRC only for rather special cases like recommitting older
commits, importing from other VCSes, etc.
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.
Why don't you rather use the GIT_AUTHOR_* variables?
--
Petr Pasky Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone. -- Alan Cox
-
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Petr Baudis [EMAIL PROTECTED] wrote: Dear diary, on Fri, Jul 29, 2005 at 11:55:52AM CEST, I got a letter where Catalin Marinas [EMAIL PROTECTED] told me that... 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. Why don't you rather use the GIT_AUTHOR_* variables? It was simpler since the template variables were based on the patch details. Anyway, it's not hard to modify. -- Catalin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Dear diary, on Sat, Jul 23, 2005 at 12:27:31PM CEST, I got a letter where Catalin Marinas [EMAIL PROTECTED] told me that... Agreed. What Cogito uses: .git/author Default author information in format Person Name [EMAIL PROTECTED] What about .git/committer? This is useful if I do a commit at work and I want the repository to have my gmail address. The committer field generally identifies the committer physically, and isn't usually overriden. You'll find [EMAIL PROTECTED] in my committer field, e.g. .git/branch-name Symbolic name of the branch of this repository. Isn't this the same as $(readlink .git/HEAD), with some trimming? 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 Pasky Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Petr Baudis [EMAIL PROTECTED] writes: The committer field generally identifies the committer physically, and isn't usually overriden. You'll find [EMAIL PROTECTED] in my committer field, e.g. 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. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
On Thu, 28 Jul 2005, Junio C Hamano wrote: 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. 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 [EMAIL PROTECTED] or [EMAIL PROTECTED], while my normal patches tend to say [EMAIL PROTECTED] since that's my main machine. So I tend to not override it, even though none of those are really valid email addresses. Linus - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
On Fri, 2005-07-22 at 16:07 -0700, Junio C Hamano wrote: Catalin Marinas [EMAIL PROTECTED] 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. 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. 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. .gitignore are note currently supported by StGIT but I'll add this. 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. The problem appears when one upstream maintainer changes the configuration, should this be merged again? In this case you can get conflicts. 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? 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. 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. 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 think Petr already started the discussion rolling for commit templates, and I like his proposal. I like it too. 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. 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. Again, having Porcelain specific options mixed in the same file might lead to some confusion among users. True. We need to be careful. 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. 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
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Dear diary, on Sat, Jul 23, 2005 at 10:41:38AM CEST, I got a letter
where Catalin Marinas [EMAIL PROTECTED] told me that...
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.
Great idea.
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.
The problem appears when one upstream maintainer changes the
configuration, should this be merged again? In this case you can get
conflicts.
So you resolve them...? If the upstream keeps doing changes frequent
enough and large-scale enough to this becoming annoying, something is
wrong. :-)
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.
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.
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.
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.
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/.
Again, having Porcelain specific options mixed in the same file might
lead to some confusion among users.
True. We need to be careful.
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.
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?)
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 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.
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.
Agreed. What Cogito uses:
.git/author Default author information in format
Person Name [EMAIL PROTECTED]
.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,
Re: [PATCH 1/1] Tell vim the textwidth is 75.
On Sat, 2005-07-23 at 11:30 +0200, Petr Baudis wrote: Dear diary, on Sat, Jul 23, 2005 at 10:41:38AM CEST, I got a letter where Catalin Marinas [EMAIL PROTECTED] told me that... The problem appears when one upstream maintainer changes the configuration, should this be merged again? In this case you can get conflicts. So you resolve them...? If the upstream keeps doing changes frequent enough and large-scale enough to this becoming annoying, something is wrong. :-) OK, that's fine with me (but see below). 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. 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. 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. 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. 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/. Yes, my idea complicates things quite a lot. 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. 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?) Or we could have ~/.git/git.conf, ~/.git/cogito.conf and ~/.git/stgit.conf, under the same directory. 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 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. 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). Agreed. What Cogito uses: .git/author Default author information in format Person Name [EMAIL PROTECTED] What about .git/committer? This is useful if I do a commit at work and I want the repository to have my gmail address. .git/branch-name Symbolic name of the branch of this repository. Isn't this the same as $(readlink .git/HEAD), with some trimming? .git/commit-template Commit template to use in the commit editor instead of some short header (most of it is still hardcoded). OK .git/exclude--exclude-from for git-ls-files I want to rename this to .git/ignore OK, either name is fine with me. .git/hooks/commit-post .git/hooks/merge-pre .git/hooks/merge-post 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'
Re: [PATCH 1/1] Tell vim the textwidth is 75.
On Fri, 2005-07-22 at 16:24 -0700, Junio C Hamano wrote: Petr Baudis [EMAIL PROTECTED] writes: 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? However, I'd like to see what the extent of damage would be even if everybody agrees this is a good change. 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. -- Catalin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
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. 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 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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
On Sat, 2005-07-23 at 12:33 -0400, Bryan Larsen wrote: how about: .git/refs/heads/master - documented in README, doesn't appear to be used. 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. .git/firstmail.tmpl - template used for sending the preamble email 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. -- Catalin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Petr Baudis [EMAIL PROTECTED] writes: 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. 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. (Quite some things came to git from Cogito anyway. ;-) And well, that's completely natural.) 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 ;-). Personally, I think having to have ignore pattern like .cvsignore per-directory is simply _ugly_. 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. 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. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
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 - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Sam Ravnborg [EMAIL PROTECTED] writes: 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. 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 [EMAIL PROTECTED] while using [EMAIL PROTECTED] for my day-job projects. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Dear diary, on Fri, Jul 22, 2005 at 12:37:05PM CEST, I got a letter where Catalin Marinas [EMAIL PROTECTED] told me that... 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? 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. 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 @[EMAIL PROTECTED] 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:@[EMAIL PROTECTED] @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). -- Petr Pasky Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
On Fri, 2005-07-22 at 19:24 +, Sam Ravnborg wrote: 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. 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. -- Catalin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
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. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Dear diary, on Fri, Jul 22, 2005 at 11:16:51PM CEST, I got a letter where Junio C Hamano [EMAIL PROTECTED] told me that... 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. 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. 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. Cogito shows '[NMD] filename' in place of @[EMAIL PROTECTED] 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 Pasky Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
On Fri, 2005-07-22 at 13:39 -0700, Junio C Hamano wrote: I would like to see Porcelains stay compatible when the do not have to differ. The commit template [*2*] is one example of such. 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. 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) OK - 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. - pre-commit hook (to enforce a certain tests to pass) - post-commit-hook (sending commit-notification perhaps). OK - 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. 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; As Petr said, it's hard to define a project. - 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. StGIT uses /etc/stgitrc, ~/.stgitrc and .git/stgitrc, the latter overriding the former. 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. 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. About the where part, one proposal I have off the top of my head is something like this: 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. - 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. 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. - Use $GIT_DIR/conf/ as a convention to store per repository configuration files. This does not propagate with pulls/pushes/merges across repositories. That's fine. - 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. But normally the per-repository one would take precedence over per-user one which in turn would take precedence over per-project one. With a note if specifying what a project is. *3* .gitignore in the cwd is used in Cogito, if I am not mistaken. I will to add this to StGIT. *4* E.g. I would commit for GIT project with [EMAIL PROTECTED] while using [EMAIL PROTECTED] for my day-job projects. In StGIT this is settable via authorname/authoremail in the stgitrc file and can be per repository or per user. -- Catalin - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Catalin Marinas [EMAIL PROTECTED] writes: 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. - 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. - 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). 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. - 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
Re: [PATCH 1/1] Tell vim the textwidth is 75.
Petr Baudis [EMAIL PROTECTED] writes: Cogito shows '[NMD] filename' in place of @[EMAIL PROTECTED] Sounds sensible. Does it parse it to limit the files to be committed? 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? 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'. - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/1] Tell vim the textwidth is 75.
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? - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
