On Wed, Aug 6, 2014 at 6:26 PM, Nico Williams <nico@xxxxxxxxxxxxxxxx> wrote: > On Wed, Aug 6, 2014 at 10:58 AM, Jakub Narębski <jnareb@xxxxxxxxx> wrote: >> W dniu 2014-08-01 22:55, Nico Williams pisze: >>> >>> It would help if cherry-pick history where recorded somewhere (beyond >>> the reflog)... >>> >>> Cherry-picks should record two parents, like merges. >>> >>> (Of course, it does no good to know about an unreachable parent, when >>> a commit with two parents is pushed to a repo that doesn't have one of >>> those parents, which can happen when topic branches aren't pushed >>> upstream.) >> >> There was (long time ago) a long thread about idea of adding some >> kind of 'weak' references (links), 'weakparent' that can be automatically >> used by Git but do not pollute the commit message, >> and do not affect reachability calculations. Ultimately it went >> nowhere (as you can see) - there were many problems. > > 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? 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... BTW. sometimes I do wonder if we are not making a mistake trying to shoehorn new features like stash, replacements and notes into DAG, objects (commit, tree, blob), refs and reflogs. I'd rather Git did not make the same mistake (well, I think it was a mistake) that Mercurial did with .hgtags file, (ab)using file transfer for tags, instead of adding separate transfer mechanism like Git has... which led to contortions in interpreting / deling with said file (most recent version is used, not the one in checked out revision) and things like having to commit creating a tag for it to be transferrable. >> For example: how it would work for reverts and rebases? > > 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... > 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. > 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... -- Jakub Narębski -- 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