Re: git-rerere observations and feature suggestions

Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]
From: Karl
Date: Thursday, June 19, 2008 - 3:35 am

On 2008-06-19 12:06:37 +0200, Miklos Vajna wrote:


If I don't store the pre or post tree in its entirety, I lose the
ability to do patch application by three-way merge. (The current StGit
design assumes that we can always make a three-way merge as a last
resort when applying patches. Basically, StGit is just a fancy way to
rebase.)

But yes, this is a viable idea. (Though once I have to store one of
the trees, I believe it's actually simpler and cheaper to just store
the other tree as well, instead of having to compute the diff and
store that in a blob.)


There's actually no point in making more than one commit. A tree can
easily hold a lot of sub-trees.

I have an existing implementation that stores the pre and post tree
for each patch, plus some metadata (message, author). The issue with
this format is that every time we write a new log entry (that is, for
every StGit command), we have to call git multiple times in order to
write several new trees and blobs.

StGit normally represents each patch by a commit object, so it should
be faster to simply write a single new commit to the log that has some
metadata in its commit message and just refers to all the patches'
commit objects (by having them as parents). Which is why I was
inquiring about the maximum number of parents of a commit object.

( Some background: At a given point in time, your StGit stack consists
  of a few applied patches, and a few unapplied patches. The applied
  patches are just a linear sequence of commits at the top of your
  current branch, so we can trivially save them all from the garbage
  collector by making the stack top a parent of our log commit. The
  unapplied patches, however, are commits that are not reachable from
  the stack top -- they can be "pushed" onto the stack by rebasing, at
  which point they become applied, but until then we can't make any
  assumptions about them being ancestors of anything. So a log commit
  potentially has to have _every_ unapplied patch as a parent. (If we
  know that the commit of an unapplied patch used to be applied, we
  know that it's reachable from previous log commits, but we don't
  always know that.) )

-- 
Karl Hasselström, kha@treskal.com
      www.treskal.com/kalle
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Previous message: [thread] [date] [author]
Next message: [thread] [date] [author]

Messages in current thread:
git-rerere observations and feature suggestions, Ingo Molnar, (Mon Jun 16, 4:01 am)
Re: git-rerere observations and feature suggestions, Mike Hommey, (Mon Jun 16, 4:09 am)
Re: git-rerere observations and feature suggestions, Theodore Tso, (Mon Jun 16, 4:27 am)
Re: git-rerere observations and feature suggestions, Pierre Habouzit, (Mon Jun 16, 8:48 am)
Re: git-rerere observations and feature suggestions, Pierre Habouzit, (Mon Jun 16, 8:57 am)
Re: git-rerere observations and feature suggestions, Sverre Rabbelier, (Mon Jun 16, 9:18 am)
Re: git-rerere observations and feature suggestions, Junio C Hamano, (Mon Jun 16, 11:46 am)
Re: git-rerere observations and feature suggestions, Ingo Molnar, (Mon Jun 16, 12:09 pm)
Re: git-rerere observations and feature suggestions, Junio C Hamano, (Mon Jun 16, 12:10 pm)
Re: git-rerere observations and feature suggestions, Ingo Molnar, (Mon Jun 16, 12:44 pm)
Re: git-rerere observations and feature suggestions, Ingo Molnar, (Mon Jun 16, 12:52 pm)
Re: git-rerere observations and feature suggestions, Jakub Narebski, (Mon Jun 16, 1:11 pm)
Re: git-rerere observations and feature suggestions, Junio C Hamano, (Mon Jun 16, 1:25 pm)
Re: git-rerere observations and feature suggestions, Ingo Molnar, (Mon Jun 16, 1:46 pm)
Re: git-rerere observations and feature suggestions, Junio C Hamano, (Mon Jun 16, 1:50 pm)
Re: git-rerere observations and feature suggestions, Junio C Hamano, (Mon Jun 16, 2:37 pm)
Re: git-rerere observations and feature suggestions, Johannes Schindelin, (Tue Jun 17, 3:24 am)
Re: git-rerere observations and feature suggestions, Ingo Molnar, (Wed Jun 18, 3:57 am)
Re: git-rerere observations and feature suggestions, Miklos Vajna, (Wed Jun 18, 4:29 am)
Re: git-rerere observations and feature suggestions, Ingo Molnar, (Wed Jun 18, 4:36 am)
Re: git-rerere observations and feature suggestions, Ingo Molnar, (Wed Jun 18, 11:43 am)
Re: git-rerere observations and feature suggestions, Miklos Vajna, (Wed Jun 18, 12:53 pm)
Re: git-rerere observations and feature suggestions, Jakub Narebski, (Wed Jun 18, 3:01 pm)
Re: git-rerere observations and feature suggestions, Miklos Vajna, (Wed Jun 18, 3:38 pm)
Re: git-rerere observations and feature suggestions, Miklos Vajna, (Thu Jun 19, 12:29 am)
Re: git-rerere observations and feature suggestions, Junio C Hamano, (Thu Jun 19, 12:30 am)
Re: git-rerere observations and feature suggestions, Miklos Vajna, (Thu Jun 19, 1:33 am)
Re: git-rerere observations and feature suggestions, Miklos Vajna, (Thu Jun 19, 3:06 am)
Re: git-rerere observations and feature suggestions, Karl , (Thu Jun 19, 3:35 am)
Re: git-rerere observations and feature suggestions, Ingo Molnar, (Mon Jun 23, 2:49 am)
Re: git-rerere observations and feature suggestions, Peter Zijlstra, (Mon Jun 23, 7:19 am)
Re: git-rerere observations and feature suggestions, Peter Zijlstra, (Mon Jun 23, 7:26 am)
Re: git-rerere observations and feature suggestions, Jeff King, (Mon Jun 23, 8:12 am)
Re: git-rerere observations and feature suggestions, Ingo Molnar, (Mon Jun 23, 8:22 am)