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

[PATCH 4/7] Softrefs: Add manual page documenting git-softref and softrefs subsystem in general

From
Johan Herland <johan@herland.net>
Date
Jun 9, 2007, 18:23 UTC
Message-ID
<200706092023.13537.johan@herland.net>
In-Reply-To
<200706092019.13185.johan@herland.net>
Signed-off-by: Johan Herland <johan@herland.net>
---
 Documentation/git-softref.txt |  119 +++++++++++++++++++++++++++++++++++++++++
 1 files changed, 119 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/git-softref.txt
diff --git a/Documentation/git-softref.txt b/Documentation/git-softref.txt
new file mode 100644
index 0000000..6a3e13b
--- /dev/null
+++ b/Documentation/git-softref.txt
@@ -0,0 +1,119 @@
+git-softref(1)
+==============
+
+NAME
+----
+git-softref - Create, list and administer soft references
+
+
+SYNOPSIS
+--------
+[verse]
+'git-softref' --list [<from-object>]
+'git-softref' --has <from-object> <to-object>
+'git-softref' --add <from-object> <to-object>
+'git-softref' --rebuild-tags
+'git-softref' --merge-unsorted [<softrefs-file>]
+'git-softref' --merge-sorted <softrefs-file>
+
+
+DESCRIPTION
+-----------
+Query and administer soft references in a git repository.
+
+Soft references are used to declare reachability between already existing
+objects. An object (called the 'to-object') may be declared reachable from
+another object (the 'from-object') without affecting the immutability of either
+object.
+
+The `--list` option will list existing softrefs in the database. If given the
+optional <from-object>, the list is limited to softrefs from the given object.
+The `--has` option is used to check for the existence of a softref between two
+given objects, similarly the `--add` option is used to add such a softref.
+
+The `--rebuild-tags` option is used to generate softrefs for all tag objects in
+the repository reachable from tag refs. Tag objects use softrefs to declare
+reachability 'from' the tagged object, 'to' the tag object. This allows for tag
+objects to the cloned/fetched/pushed along with their associated objects.
+
+Finally, the `--merge-unsorted` and `--merge-sorted` options are used to merge
+softrefs files into the sorted softrefs db. The filename argument must point
+to an existing file in unsorted/sorted softrefs format. The softrefs entries
+in this file will be merged into the sorted softrefs db. The `--merge-unsorted`
+option may be used 'without' a filename, in which case the currently unsorted
+portion of the softrefs db will be merged into the sorted db. Note that this
+last operation is also done regularly by default when adding softrefs, so
+there is no need to invoke this option during regular use.
+
+
+OPTIONS
+-------
+--list [<from-object>]::
+	List all softrefs that have the given '<from-object>'.
+	If '<from-object>' is not given, list 'all' softrefs in the repository.
+
+--has <from-object> <to-object>::
+	Return with exit code 1 if the given softref exists in the repository.
+	Return with exit code 0 otherwise.
+
+--add <from-object> <to-object>::
+	Add a softref from the given '<from-object>' to the given '<to-object>'.
+	The '<to-object>' will from now on be considered reachable from the
+	'<from-object>'.
+
+--rebuild-tags::
+	Automatically generate softrefs for all tag objects reachable from
+	tag refs in the repository.
+
+--merge-unsorted [<softrefs-file>]::
+	Merge the softrefs in the given unsorted '<softrefs-file>' into the
+	sorted softrefs db. If a filename is not given, force a merge of the
+	internal unsorted softrefs store into the sorted softrefs db.
+
+--merge-sorted <softrefs-file>::
+	Merge the softrefs in the given sorted '<softrefs-file>' into the
+	sorted softrefs db.
+
+
+DISCUSSION
+----------
+Soft references (softrefs) is a general mechanism for declaring a relationship
+between two existing arbitrary objects in the repo. Softrefs differ from the
+existing reachability relationship in that a softref may be created after
+'both' of the involved objects have been added to the repo. In contrast,
+regular reachability depends on the reachable object's name being stored
+'inside' the other object. A reachability relationship can therefore not be
+created at a later time without violating the immutability of git objects.
+
+Softrefs are defined as going 'from' one object 'to' another object. Once
+a softref between two objects has been created, the "to" object is considered
+reachable from the "from" object.
+
+Also, softrefs are stored in a way that makes it easy and quick to find all
+the "to" objects reachable from a given "from" object.
+
+The softrefs db consists of two files: `.git/softrefs.unsorted` and
+`.git/softrefs.sorted`. Both files use the same format; one softref per line
+of the form "`<from-sha1> <to-sha1>\n`". Each sha1 sum is 40 bytes long; this
+makes each entry exactly 82 bytes long.
+
+The entries in `.git/softrefs.sorted` are sorted on `<from-sha1>`, in order to
+make lookup fast. This file is also known as the "sorted softrefs db".
+
+The entries in `.git/softrefs.unsorted` are 'not' sorted. This is to make
+insertion fast. This file is also known as the "unsorted softrefs db".
+
+When softrefs are created, they are appended to `.git/softrefs.unsorted`.
+When `.git/softrefs.unsorted` reach a certain number of entries, all the
+entries in `.git/softrefs.unsorted` are automatically merged into
+`.git/softrefs.sorted`.
+
+
+Author
+------
+Written by Johan Herland <johan@herland.net>.
+
+
+GIT
+---
+Part of the gitlink:git[7] suite
-- 
1.5.2.1.144.gabc40
Previous: Johan HerlandNext: Johan Herland
Message 31 of 52 in “Refactoring the tag object; Introducing soft references (softrefs); Git 'notes' (take 2)”
  1. Johan HerlandJun 4, 2007
  2. 0/6 Refactor the tag objectJohan Herland, Jun 4, 2007
  3. 1/6 Refactor git tag objects; make "tag" header optional; introduce new optional "keywords" headerJohan Herland, Jun 4, 2007
  4. Matthias LederhoferJun 4, 2007
  5. Johan HerlandJun 4, 2007
  6. 2/6 git-show: When showing tag objects with no tag name, show tag object's SHA1 instead of an empty stringJohan Herland, Jun 4, 2007
  7. 3/6 git-fsck: Do thorough verification of tag objects.Johan Herland, Jun 4, 2007
  8. Matthias LederhoferJun 4, 2007
  9. Johan HerlandJun 4, 2007
  10. Junio C HamanoJun 6, 2007
  11. 3/6 git-fsck: Do thorough verification of tag objects.Johan Herland, Jun 6, 2007
  12. Junio C HamanoJun 6, 2007
  13. Junio C HamanoJun 6, 2007
  14. Johan HerlandJun 6, 2007
  15. Junio C HamanoJun 6, 2007
  16. 4/6 Documentation/git-mktag: Document the changes in tag object structureJohan Herland, Jun 4, 2007
  17. 5/6 git-mktag tests: Fix and expand the mktag tests according to the new tag object structureJohan Herland, Jun 4, 2007
  18. 6/6 Add fsck_verify_ref_to_tag_object() to verify that refname matches name stored in tag objectJohan Herland, Jun 4, 2007
  19. Junio C HamanoJun 4, 2007
  20. Fix bug in tag parsing when thorough verification was in effectJohan Herland, Jun 7, 2007
  21. 0/7 Introduce soft references (softrefs)Johan Herland, Jun 9, 2007
  22. 1/7 Softrefs: Add softrefs header file with API documentationJohan Herland, Jun 9, 2007
  23. Johannes SchindelinJun 10, 2007
  24. Junio C HamanoJun 10, 2007
  25. Johannes SchindelinJun 10, 2007
  26. Johan HerlandJun 10, 2007
  27. Jakub NarebskiJun 10, 2007
  28. Teach git-gc to merge unsorted softrefsJohan Herland, Jun 10, 2007
  29. 2/7 Softrefs: Add implementation of softrefs APIJohan Herland, Jun 9, 2007
  30. 3/7 Softrefs: Add git-softref, a builtin command for adding, listing and administering softrefsJohan Herland, Jun 9, 2007
  31. 4/7 Softrefs: Add manual page documenting git-softref and softrefs subsystem in generalJohan Herland, Jun 9, 2007
  32. 5/7 Softrefs: Add testcases for basic softrefs behaviourJohan Herland, Jun 9, 2007
  33. 6/7 Softrefs: Administrivia associated with softrefs subsystem and git-softref builtinJohan Herland, Jun 9, 2007
  34. 7/7 Teach git-mktag to register softrefs for all tag objectsJohan Herland, Jun 9, 2007
  35. Change softrefs file format from text (82 bytes per entry) to binary (40 bytes per entry)Johan Herland, Jun 9, 2007
  36. Johannes SchindelinJun 10, 2007
  37. Junio C HamanoJun 10, 2007
  38. Johannes SchindelinJun 10, 2007
  39. Johan HerlandJun 10, 2007
  40. Comment on weak refsJunio C Hamano, Jun 9, 2007
  41. Johan HerlandJun 10, 2007
  42. Johannes SchindelinJun 10, 2007
  43. Johan HerlandJun 10, 2007
  44. Pierre HabouzitJun 10, 2007
  45. Pierre HabouzitJun 10, 2007
  46. Pierre HabouzitJun 10, 2007
  47. Jakub NarebskiJun 10, 2007
  48. Steven GrimmJun 9, 2007
  49. Johan HerlandJun 9, 2007
  50. Pierre HabouzitJun 10, 2007
  51. Johan HerlandJun 10, 2007
  52. Steven GrimmJun 10, 2007

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.