git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Catalin Marinas" <catalin.marinas@gmail.com>
To: "Karl Hasselström" <kha@treskal.com>
Cc: git@vger.kernel.org
Subject: Re: [StGit PATCH 03/14] Write to a stack log when stack is modified
Date: Tue, 17 Jun 2008 11:24:53 +0100	[thread overview]
Message-ID: <b0943d9e0806170324j12605a55m41b582ad09925cce@mail.gmail.com> (raw)
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>:
> 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.

> +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?

> +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.

> +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.

> +
> +      <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

  reply	other threads:[~2008-06-17 10:25 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-06-12  5:34 [StGit PATCH 00/14] Undo series Karl Hasselström
2008-06-12  5:34 ` [StGit PATCH 01/14] Fix typo Karl Hasselström
2008-06-12  5:34 ` [StGit PATCH 02/14] Library functions for tree and blob manipulation Karl Hasselström
2008-06-12  5:34 ` [StGit PATCH 03/14] Write to a stack log when stack is modified Karl Hasselström
2008-06-17 10:24   ` Catalin Marinas [this message]
2008-06-17 12:31     ` Karl Hasselström
2008-06-17 12:55       ` Karl Hasselström
2008-06-17 14:11       ` Catalin Marinas
2008-06-17 15:32         ` Karl Hasselström
2008-06-18 13:03           ` Catalin Marinas
2008-06-18 14:36             ` Karl Hasselström
2008-06-18 16:16               ` Catalin Marinas
2008-06-18 17:32                 ` Karl Hasselström
2008-06-19  9:24                   ` Catalin Marinas
2008-06-19 10:07                     ` Karl Hasselström
2008-06-20  9:14                       ` Catalin Marinas
2008-06-23 12:36                         ` Karl Hasselström
2008-07-12 10:09                           ` Catalin Marinas
2008-07-14  6:32                             ` Karl Hasselström
2008-07-01 20:13           ` Karl Hasselström
2008-07-03 22:05             ` Catalin Marinas
2008-06-12  5:34 ` [StGit PATCH 04/14] Add utility function for reordering patches Karl Hasselström
2008-06-12  5:34 ` [StGit PATCH 05/14] New command: stg reset Karl Hasselström
2008-06-12  5:34 ` [StGit PATCH 06/14] Log conflicts separately Karl Hasselström
2008-06-12  5:34 ` [StGit PATCH 07/14] Log conflicts separately for all commands Karl Hasselström
2008-06-12  5:34 ` [StGit PATCH 08/14] Add a --hard flag to stg reset Karl Hasselström
2008-06-12  5:35 ` [StGit PATCH 09/14] Don't write a log entry if there were no changes Karl Hasselström
2008-06-12  5:35 ` [StGit PATCH 10/14] Move stack reset function to a shared location Karl Hasselström
2008-06-12  5:35 ` [StGit PATCH 11/14] New command: stg undo Karl Hasselström
2008-06-12  5:35 ` [StGit PATCH 12/14] New command: stg redo Karl Hasselström
2008-06-12  5:35 ` [StGit PATCH 13/14] Log and undo external modifications Karl Hasselström
2008-06-12  5:35 ` [StGit PATCH 14/14] Make "stg log" show stack log instead of patch log Karl Hasselström

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b0943d9e0806170324j12605a55m41b582ad09925cce@mail.gmail.com \
    --to=catalin.marinas@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=kha@treskal.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).