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, 14:11 UTC
Message-ID
<b0943d9e0806170711w6da8e841p3ac83a59a81f6577@mail.gmail.com>
In-Reply-To
<20080617123138.GA6932@diana.vm.bytemark.co.uk>
2008/6/17 Karl Hasselström <kha@treskal.com>:
Show 13 quoted lines
> On 2008-06-17 11:24:53 +0100, Catalin Marinas wrote:
>> 2008/6/12 Karl Hasselström <kha@treskal.com>:
>> >  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.
>
> I might not have understood precisely what you meant; but I don't
> think API backwards compatibilty should be an issue here? I simply fix
> all callers. If log should default to true or false is immaterial --
> it just means some extra text in one or the other of two equally
> common cases.

Not an issue, I just favour the existing one when the two cases are almost equal.

Show 12 quoted lines
>> > --- /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.
>
> "r" in front of a string literal means "raw" (or some such). Escape
> sequences aren't recognized inside a raw string -- e.g., r'\n' ==
> '\\n'. They are useful when you have to write strings with embedded
> backslashes, such as regexes -- or this string, which has \n in it.
Thanks, I didn't know this.
Show 11 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?
>
> Yes. It's stored in a regular git branch. (The design is such that it
> should even be possible to pull a stack log from another repository
> and _still_ get everything you need.)

But how are the patches recreated when undoing (the refs/patches/<branch>/* files)? Using the Bottom/Top tree ids that a patch had in the past? Are these trees still present after a git-gc?

Show 21 quoted lines
>> > +  - 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.
>
> You can't store a commit object in a tree. (Well, with submodules you
> can, but said commit object isn't protected from gc and won't be
> included when pulling.) The idea with this format is that with the two
> trees and the info file, you can recreate the patch's commit -- not
> exactly, but close enough as makes no difference.

What I meant is the SHA1 value of the patch commit instead of Bottom/Top, Author and Date. The corresponding commit object has all this information.

Show 7 quoted lines
>> > +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.
>
> Have you tried looking at a patch stack log (in gitk, say)?
I tried "gitk master.stgit" and got scared :-)
> That is, "stg log -g" in this patch series.
This is more readable.
> It shows you diffs between
> subsequent revisions of the simplified log. I'm sure it's far from
> perfect, but I think it's actually quite useful.

It is useful, though it might take a bit of time to get used to it. It might also be a bit difficult if you want to revert some changes to a single patch but not do a full stack undo which would affect other patches.

-- 
Catalin
Previous: Karl HasselströmNext: Karl Hasselström
Message 8 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.