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 apologize for wasting people's time.
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.
--
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
