2008/6/17 Karl Hasselström <kha@xxxxxxxxxxx>:
> On 2008-06-17 15:11:42 +0100, Catalin Marinas wrote:
>
>> 2008/6/17 Karl Hasselström <kha@xxxxxxxxxxx>:
>>
>> > On 2008-06-17 11:24:53 +0100, Catalin Marinas wrote:
>> > > 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?
>
> The log actually _contains_ those trees, so there is no problem.
OK, I begin to understand. It is a generic solution for storing
metadata but IMHO it is too overweight when we only need a list of
applied and unapplied files (we can remove hidden) that could be
easily stored in a commit log. It would be useful to run a quick
benchmark with many (hundreds) of patches and compare it with no
logging variant (or the current patch logging, which isn't as
advanced).
Could we not make this (much) simpler? I.e. <branch>.stgit is a commit
object whose tree is <branch>^{tree} and the message contains the
command followed by list of patches in the form "<commit> <patch>"?
This commit can have two parents - the previous <branch>.stgit and
current <branch> head. All the patches are referred via the <branch>
head or the previous <branch> heads if unapplied (assuming that when a
patch is created it is first applied and then popped, maybe this needs
a bit of thinking). This way, a diff between subsequent <branch>.stgit
commits would show the tree changes. The 'stg log' command could be
made to show differences in the commit messages.
>> > 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.
>
> Yes, much like diffs take some time to get used to if you haven't seen
> them before.
>
> If you have ideas for a better way to visualize this, I'm all ears.
The diff of diffs is generally useful but for 'refresh' logs, you can
show the diff between the old top tree and the new one (the current
patch log implementation does something like this but it doesn't show
anything for commands like 'push' where a diff of diffs would be more
appropriate).
--
Catalin
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
