2008/6/19 Karl Hasselström <kha@xxxxxxxxxxx>: > On 2008-06-19 10:24:28 +0100, Catalin Marinas wrote: > >> 2008/6/18 Karl Hasselström <kha@xxxxxxxxxxx>: >> >> > On 2008-06-18 17:16:10 +0100, Catalin Marinas wrote: >> > > Making the first log entry special gets difficult with log >> > > pruning (unless you prune the whole log rather than entries >> > > older than a chosen time or number) since you might have to >> > > re-create all the chained log entries as the first log's sha1 >> > > will probably change. >> > >> > You have to re-create all the commits anyway, since they all are >> > immutable, and all have a back pointer. >> >> Ah, OK. So, at least initially, we should only support the full log >> pruning. > > How do you imagine we'd do anything except a "full" pruning? There are > grafts and shallow clones, I guess, but both of them have drawbacks. Recreate the log but we I wouldn't spend time on this. >> > > The applied patches are chained automatically via HEAD. For >> > > unapplied patches, we could add the correponding commits as >> > > parents of the logging commit (starting with the third parent as >> > > the first two are used for log chaining and applied patches). Do >> > > we hit any OS limit with the number of arguments? >> > >> > Not until long after we hit git limits to the number of parents of >> > a commit. I believe the octopus merge refuses to create merges >> > with more than about 25 parents, and we probably shouldn't do more >> > than that either. We'll have to do a tree of octopuses. >> >> For the first log only, we could chain the unapplied patches using >> commits with 2 parents. We just need to warn people not to stare at >> the <branch>.stgit directly :-) > > We could make chains (or trees) of 16-parent commits -- that'd speed > it up by a factor of 15. :-) Yes, good idea. >> > * Parents: the previous log entry; branch head; something that >> > (recusively) points to all unapplied commits, if necessary. >> >> As you pointed below, "branch head" should probably be the "stack >> top". We don't need to track the "branch head" if different, just >> need to fix up the error and add the patches to the stack. And, >> anyway, if one modifies the HEAD using git directly, the log will >> still point to the top of the stack. > > If we ever want to be able to undo "stg repair", we have to be able to > represent an inconsistent state where head != top. I wouldn't bother with this feature. Why would one want to break the stack again after repairing? If they merge patches and git commits, they either repair the stack or commit all the patches and continue with using Git only. >> The third head would only be needed for the first log entry or when >> we use pick --unapplied (in the latter, it only points to the >> unapplied commit). > > Actually, except for the previous log entry, all the parents are just > there for gc's benefit. So we could just put all of them in the same > bucket -- branch head, stack top, and unapplied patches. > > ( By "bucket" I mean something like: if there are just a few of them, > have them as direct parents of the log commit; otherwise, refer to > them using a tree of octopuses. But in any case, just treat them as > a set of sha1s that we need to have as ancestors but don't otherwise > care about. ) Yes. >> > * I'm pretty sure we want the kind of "simplified" log I have in >> > my proposal. The full log in your proposal is going to look >> > every bit as ugly as the one in mine. >> >> I agree it will look ugly but the simplified log adds an extra >> overhead on any stgit action. If we don't use stg log -g, a text >> only log command could show the diff. We can add it afterwards >> though if it is fast enough. > > I'd actually say the opposite: until we have a good visualizer that > doesn't need the simplified log, we need to have the simplified log. > If I actually have to look at the diffs in the log, I find gitk > indispensible. And what would the simplified log contain if we decide to go with a new scheme? In your proposal, it points to the tree of main log and you get the diff of diffs (which also means that the diffs must be generated for every modification of a patch). Would this be the same? Again, I worry a bit about the overhead to generate the patch diff for every push (with refresh I'm OK). It can be optimised as in the stable branch where we try git-apply followed by a three-way merge (which, BTW, I'd like added before 0.15). If git-apply succeeds, there is no need to re-generate the diff. -- 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
