On Wed, Aug 06, 2014 at 08:31:18PM +0200, Jakub Narębski wrote: > On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote: > > My proposal was to put this sort of ancillary history info in a > > "branch object" (and that branches should be objects). This would > > have a number of benefits, not the least of which is that at push time > > you can drop such ancillary history without having to alter the > > commits being pushed. > > Is it something like object-ified reflog, similar to how replacement > objects (git-replace) can be thought to be object-ified grafts (I know > they are more)? Do I understand it correctly? Yes, per-branch. At push time a commit would be pushed to the upstream branch listing the commits pushed now (and who by). Locally every rebase/cherry-pick/merge/commit onto the branch would appear in the branch object's history, kinda just like the reflog. The main difference is that the upstream branch's history could be viewed. > Did you plan to (ab)use known object types: tree and commit (a bit > similar to git-replace and git-note object, though there is no need for > fanout trees - the top level tree can reproduce refs hierarchy)? I see > that you planned to (ab)use existing transfer mechanism of refs and > objects... Just like signed tags, basically. > > Reverts upstream? The revert should record the commit hash of the > > commit it reverts (but file-level reverts lose), so that this could be > > noticed. > > If it is object-ified reflog then reverts are not a problem... Right. > > Rebases upstream? Well, that shouldn't happen, but if it does then > > you must rebase --onto and any cherry-picks of upstream rebased > > commits lose their ties to those (but this can be detected). > > With rebases the problem is that it would be nice to have (at least > for a short time) the history of series of patches (the metahistory, > or history of a branch), but usually one doesn't need old pre-rebase > version after cleaning up the history for publishing. Right. > > In general recording more metadata (assuming there's not privacy > > issues to consider) can't hurt. Using it might, but having the option > > to can also help. > > True... The principle should be to record as much metadata as possible, pruning ancillary metadata (reflog-like metadata that isn't on the commits) only at push time. Nico -- -- 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