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

Re: [StGit PATCH 03/14] Write to a stack log when stack is modified

From
CMCatalin Marinas <catalin.marinas@gmail.com>
Date
Jun 17, 2008, 10:24 UTC
Message-ID
<b0943d9e0806170324j12605a55m41b582ad09925cce@mail.gmail.com>
In-Reply-To
<20080612053424.23549.64457.stgit@yoghurt>
Hi Karl,
There are some comments below but I think I haven't fully understood this.
2008/6/12 Karl Hasselström <kha@treskal.com>:
Show 7 quoted lines
> Create a log branch (called <branchname>.stgit) for each StGit branch,
> and write to it whenever the stack is modified.
>
> Commands using the new infrastructure write to the log when they
> commit a transaction. Commands using the old infrastructure get a log
> entry write written for them when they exit, unless they explicitly
> ask for this not to happen.
I was more thinking for this to be the default for backwards API compatibility.
>  class _Directory(object):
> -    def __init__(self, needs_current_series = True):
> +    def __init__(self, needs_current_series = True, log = True):
i.e. we make log = False here by default.
> --- /dev/null
> +++ b/stgit/lib/log.py
> @@ -0,0 +1,254 @@
> +r"""This module contains functions and classes for manipulating
Why does this start with an 'r'? I thought this is for regular expressions.
Show 5 quoted lines
> +A stack log is a git branch. Each commit contains the complete state
> +of the stack at the moment it was written; the most recent commit has
> +the most recent state.
> +
> +For a branch C{I{foo}}, the stack log is stored in C{I{foo}.stgit}.
The main question. Is this history preserved after a git-gc?
Show 30 quoted lines
> +Tree
> +----
> +
> +The top-level tree object has the following entries:
> +
> +  - C{version}: a blob containing the string "C{5\n}".
> +
> +  - C{head}: a blob containing the ASCII hex sha1 of the current HEAD,
> +    followed by a newline.
> +
> +  - C{applied}, C{unapplied}: blobs containing one line for each
> +    applied or unapplied patch, in order. Each line consists of
> +
> +      - the ASCII hex sha1 of the patch's commit object,
> +
> +      - a space, and
> +
> +      - the patch's name.
> +
> +  - C{patches}: a tree containing one subtree for each patch, named
> +    after that patch. Each such subtree contains:
> +
> +      - C{a}, C{b}: the patch's I{bottom} and I{top} trees.
> +
> +      - C{info}: a blob containing::
> +
> +          Author: <author name and e-mail>
> +          Date: <patch timestamp>
> +
> +          <commit message>

I might not fully understand this but can we not store just the commit object if the patch, which would have the bottom/top information.

Show 13 quoted lines
> +Simplified log
> +--------------
> +
> +The simplified log looks exactly like the normal, or I{full}, log,
> +except for the following:
> +
> +  - Instead of having a tree per patch in the C{patches} subtree, it
> +    has a blob per patch. This blob contains::
> +
> +      Bottom: <sha1 of patch's bottom tree>
> +      Top:    <sha1 of patch's top tree>
> +      Author: <author name and e-mail>
> +      Date:   <patch timestamp>

Can we not point to the original commit corresponding to the patch? It already has this information.

Show 6 quoted lines
> +
> +      <commit message>
> +
> +      ---
> +
> +      <patch's diff>
What is the patch's diff here? Cannot it be determined from the trees?
> +The simplified log contains no information not in the full log; its
> +purpose is ease of visualization."""

Ah, OK. But I think it would be more useful to see the diff between subsequent revisions of a stack rather than the full patch diff.

Thanks.
-- 
Catalin
Previous: Karl HasselströmNext: Karl Hasselström
Message 5 of 32 in “Undo series”
  1. 00/14 Undo seriesKarl Hasselström, Jun 12, 2008
  2. 01/14 Fix typoKarl Hasselström, Jun 12, 2008
  3. 02/14 Library functions for tree and blob manipulationKarl Hasselström, Jun 12, 2008
  4. 03/14 Write to a stack log when stack is modifiedKarl Hasselström, Jun 12, 2008
  5. Catalin MarinasJun 17, 2008
  6. Karl HasselströmJun 17, 2008
  7. Karl HasselströmJun 17, 2008
  8. Catalin MarinasJun 17, 2008
  9. Karl HasselströmJun 17, 2008
  10. Catalin MarinasJun 18, 2008
  11. Karl HasselströmJun 18, 2008
  12. Catalin MarinasJun 18, 2008
  13. Karl HasselströmJun 18, 2008
  14. Catalin MarinasJun 19, 2008
  15. Karl HasselströmJun 19, 2008
  16. Catalin MarinasJun 20, 2008
  17. Karl HasselströmJun 23, 2008
  18. Catalin MarinasJul 12, 2008
  19. Karl HasselströmJul 14, 2008
  20. Karl HasselströmJul 1, 2008
  21. Catalin MarinasJul 3, 2008
  22. 04/14 Add utility function for reordering patchesKarl Hasselström, Jun 12, 2008
  23. 05/14 New command: stg resetKarl Hasselström, Jun 12, 2008
  24. 06/14 Log conflicts separatelyKarl Hasselström, Jun 12, 2008
  25. 07/14 Log conflicts separately for all commandsKarl Hasselström, Jun 12, 2008
  26. 08/14 Add a --hard flag to stg resetKarl Hasselström, Jun 12, 2008
  27. 09/14 Don't write a log entry if there were no changesKarl Hasselström, Jun 12, 2008
  28. 10/14 Move stack reset function to a shared locationKarl Hasselström, Jun 12, 2008
  29. 11/14 New command: stg undoKarl Hasselström, Jun 12, 2008
  30. 12/14 New command: stg redoKarl Hasselström, Jun 12, 2008
  31. 13/14 Log and undo external modificationsKarl Hasselström, Jun 12, 2008
  32. 14/14 Make "stg log" show stack log instead of patch logKarl Hasselström, Jun 12, 2008

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.