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

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

From
Petr Baudis <pasky@suse.cz>
Date
Jul 23, 2005, 09:04 UTC
Message-ID
<20050723090433.GA11814@pasky.ji.cz>
In-Reply-To
<7vu0imh23q.fsf@assigned-by-dhcp.cox.net>

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

Show 18 quoted lines
> Catalin Marinas <catalin.marinas@gmail.com> 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.

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

Show 9 quoted lines
> >>   - 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.

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

Show 10 quoted lines
> >>   - 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.

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.
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?
diff3 throws its output on stdout, AFAIK.
> 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.

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.

Show 18 quoted lines
> > 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").

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

Show 9 quoted lines
> *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_.

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

Show 14 quoted lines
> >>   - 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 then this
> discussion is moot and I apologize for wasting people's time.

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 "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox
Previous: Junio C HamanoNext: Junio C Hamano
Message 44 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.