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

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

From
Junio C Hamano <junkio@cox.net>
Date
Jul 22, 2005, 20:39 UTC
Message-ID
<7vy87yr2xh.fsf@assigned-by-dhcp.cox.net>
In-Reply-To
<20050722192424.GB8556@mars.ravnborg.org>
Sam Ravnborg <sam@ravnborg.org> writes:
Show 6 quoted lines
>> 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 junkio@cox.net while using junio@twinsun.com for my day-job projects.

Previous: Sam RavnborgNext: Petr Baudis
Message 5 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.