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:30 UTC
Message-ID
<20050723093035.GB11814@pasky.ji.cz>
In-Reply-To
<1122108098.6863.38.camel@localhost.localdomain>

Dear diary, on Sat, Jul 23, 2005 at 10:41:38AM CEST, I got a letter where Catalin Marinas <catalin.marinas@gmail.com> told me that...

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

So you resolve them...? If the upstream keeps doing changes frequent enough and large-scale enough to this becoming annoying, something is wrong. :-)

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

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.

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

Show 8 quoted lines
> > > 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?)

Show 5 quoted lines
> 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@addy>
	.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,
			I might just have shared repository for those
			two and use the head name.
	.git/commit-template
			Commit template to use in the commit editor
			instead of some short header (most of it is
			still hardcoded).
	.git/exclude	--exclude-from for git-ls-files
			I want to rename this to .git/ignore
	.git/hooks/commit-post
			COMMIT-ID BRANCHNAME
			(could be <headname> if no branchname defined)
	.git/hooks/merge-pre
			BRANCHNAME BASE CURHEAD MERGEDHEAD MERGETYPE
			MERGETYPE is either "forward" or "tree".
			The merge is cancelled if the script returns
			non-zero exit code.
	.git/hooks/merge-post
			BRANCHNAME BASE CURHEAD MERGEDHEAD MERGETYPE STATUS
			MERGETYPE is either "forward" or "tree".
			For "forward", the STATUS is always "ok",
			while for "tree" the STATUS can be
			"localchanges", "conflicts", "nocommit",
			or "ok".
-- 
				Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
If you want the holes in your knowledge showing up try teaching
someone.  -- Alan Cox
Previous: Catalin MarinasNext: Catalin Marinas
Message 33 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.