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

RE: Hey - A Conceptual Simplication....

From
GDGeorge Dennie <gdennie@pospeople.com>
Date
Nov 19, 2009, 20:12 UTC
Message-ID
<00d401ca6954$a29fa020$e7dee060$@com>
In-Reply-To
<20091119074226.GA23304@atjola.homenet>
Thanks Jakub Narebski and Björn Steinbrink...Nice description Björn.

I think an important piece of conceptual information missing from the docs is a concise list of the conceptual properties defining the context of the working tree, index, and repository during normal use. This itemization would go far in explaining the synergies between the various commands.

Functionally, all the commands merely manipulate these properties. If these properties were summarize in context one would expect that would represent a very complete functional model of Git. A user could review the description figure what they wanted to do and then find the command(s) to accomplish it.

Presently this knowledge is accreted over time as oppose to merely being read and in the space of a few minutes "groked" (of course it could be that I am particularly limited :).

For example, towards a functional model, is this close? (note: all properties can be blank/empty)...

REPOSITORIES
	Collection of Commits
	Collection of Branches
		-- collection of commits without children
		-- as a result each commits either augments
		-- and existing branch or creates a new one
	Master Branch
		-- typically the publishable development history
INDEX
	Collections of Parent/Merge Commits
		-- the commit will use all these as its parent
	Staged Commit 
		-- these changes are shown relative to the working tree
	Default Branch
		-- the history the staged commit is suppose to augment
	Collection of Stashes
		-- these are not copies of the working tree since they
		-- only contain "versioned" files/folders and so is not
		-- a backup
WORKING_TREE
	Collection of Files and Folders
	

As far as I can tell, the working tree is not suppose to be stateful, but it seems the commands treat it as such.

What is interesting is that branches serve to encourage a serialized view of commits. More than structure, they are like books in a library narrating a development story. Consequently, and interestingly, they are as much the purpose of the repository as the commits they organize...which is interesting.

Again, thanks for your patients.
George.
Previous: Björn SteinbrinkNext: Junio C Hamano
Message 9 of 25 in “Hey - A Conceptual Simplication....”
  1. George DennieNov 18, 2009
  2. Jonathan del StrotherNov 18, 2009
  3. Jan KrügerNov 18, 2009
  4. George DennieNov 18, 2009
  5. Jakub NarebskiNov 18, 2009
  6. Jason SewallNov 18, 2009
  7. George DennieNov 19, 2009
  8. Björn SteinbrinkNov 19, 2009
  9. George DennieNov 19, 2009
  10. Junio C HamanoNov 19, 2009
  11. Jakub NarebskiNov 20, 2009
  12. Junio C HamanoNov 20, 2009
  13. Dmitry PotapovNov 20, 2009
  14. Jakub NarebskiNov 19, 2009
  15. Dmitry PotapovNov 20, 2009
  16. david@lang.hmNov 20, 2009
  17. Dmitry PotapovNov 20, 2009
  18. Björn SteinbrinkNov 20, 2009
  19. Dmitry PotapovNov 20, 2009
  20. Dmitry PotapovNov 20, 2009
  21. Junio C HamanoNov 20, 2009
  22. Dmitry PotapovNov 20, 2009
  23. Thomas RastNov 18, 2009
  24. Jason SewallNov 18, 2009
  25. Linus TorvaldsNov 18, 2009

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.