git/list[1] front-page[2] threads[3] people[4] search[5] about
 

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

From
CMCatalin Marinas <catalin.marinas@gmail.com>
Date
Jul 23, 2005, 08:41 UTC
Message-ID
<1122108098.6863.38.camel@localhost.localdomain>
In-Reply-To
<7vu0imh23q.fsf@assigned-by-dhcp.cox.net>
On Fri, 2005-07-22 at 16:07 -0700, Junio C Hamano wrote:
Show 10 quoted lines
> 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.
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.
Show 7 quoted lines
> > 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.
Show 6 quoted lines
> 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.

Show 10 quoted lines
> > 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.
Show 9 quoted lines
> > That's the thing I didn't like in GNU Arch. You modify the file ignoring
> > rules for example and the change will be included in the next commit.
> > You could only get some defaults when cloning a repository, otherwise
> > once you have different preferences from the repository's maintainer,
> > you start getting conflicts in the config files.
> 
> That's why I suggested to have "_git" (project wide default)
> separate from $GIT_DIR/info (repository owner's discretion), the
> latter overriding the former.

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.

Show 5 quoted lines
> 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
Previous: Junio C HamanoNext: Petr Baudis
Message 32 of 55 in “Tell vim the textwidth is 75.”
  1. 1/1 Tell vim the textwidth is 75.Bryan larsen, Jul 21, 2005
  2. Junio C HamanoJul 22, 2005
  3. Catalin MarinasJul 22, 2005
  4. Sam RavnborgJul 22, 2005
  5. Junio C HamanoJul 22, 2005
  6. Petr BaudisJul 22, 2005
  7. [RFC] extending git-ls-files --exclude.Junio C Hamano, Jul 24, 2005
  8. git-ls-files: --exclude mechanism updates.Junio C Hamano, Jul 24, 2005
  9. Documentation: describe git-ls-files --exclude patterns.Junio C Hamano, Jul 24, 2005
  10. Catalin MarinasJul 25, 2005
  11. Junio C HamanoJul 25, 2005
  12. Linus TorvaldsJul 25, 2005
  13. Junio C HamanoJul 25, 2005
  14. Catalin MarinasJul 25, 2005
  15. Petr BaudisJul 28, 2005
  16. Catalin MarinasJul 25, 2005
  17. Petr BaudisJul 28, 2005
  18. A Large Angry SCMJul 28, 2005
  19. Matthias UrlichsJul 28, 2005
  20. Petr BaudisJul 29, 2005
  21. Matthias UrlichsJul 29, 2005
  22. A Large Angry SCMJul 29, 2005
  23. Junio C HamanoJul 29, 2005
  24. Petr BaudisJul 29, 2005
  25. Junio C HamanoJul 29, 2005
  26. Petr BaudisJul 29, 2005
  27. Wayne ScottAug 1, 2005
  28. ls-files: rework exclude patterns.Junio C Hamano, Jul 29, 2005
  29. Documentation and tests: ls-files exclude pattern.Junio C Hamano, Jul 29, 2005
  30. Catalin MarinasJul 22, 2005
  31. Junio C HamanoJul 22, 2005
  32. Catalin MarinasJul 23, 2005
  33. Petr BaudisJul 23, 2005
  34. Catalin MarinasJul 23, 2005
  35. Bryan LarsenJul 23, 2005
  36. Catalin MarinasJul 23, 2005
  37. Petr BaudisJul 28, 2005
  38. Junio C HamanoJul 29, 2005
  39. Linus TorvaldsJul 29, 2005
  40. Catalin MarinasJul 29, 2005
  41. Petr BaudisJul 29, 2005
  42. Catalin MarinasJul 29, 2005
  43. Junio C HamanoJul 30, 2005
  44. Petr BaudisJul 23, 2005
  45. Junio C HamanoJul 24, 2005
  46. Catalin MarinasJul 22, 2005
  47. Petr BaudisJul 22, 2005
  48. Junio C HamanoJul 22, 2005
  49. Petr BaudisJul 22, 2005
  50. Junio C HamanoJul 22, 2005
  51. Petr BaudisJul 22, 2005
  52. Catalin MarinasJul 23, 2005
  53. Updating diff-raw status letter to 'A' for added files.Junio C Hamano, Jul 26, 2005
  54. 1/2 Use symbolic constants for diff-raw status indicators.Junio C Hamano, Jul 26, 2005
  55. 2/2 diff-raw: Use 'A' instead of 'N' for added files.Junio C Hamano, Jul 26, 2005

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.