Shawn Pearce <spearce@xxxxxxxxxxx> wrote: > Petr Baudis <pasky@xxxxxxx> wrote: >> (viii) Patches versioning in StGit - many people I've told about StGit >> complained that it doesn't version patches (and possibly moved to mq?). >> We should have some scheme for doing meta-history (especially >> interesting when/if we aim to make altering history easy). > > Doesn't StGit now have a single ref for every patch commit? Yes, it does and the history is lost. > What about turning on reflog support on those refs and reading the > reflog for the ``history'' of that patch? Granted the reflog isn't > prune proof but it is a history of that ref's values over time. That's a good idea indeed (I haven't noticed this feature). Anyway, I don't see any problem with not being prune-safe. I wouldn't want to preserve the refresh history of a patch forever. If I have a stable series I want to keep, I either clone it or simply tag it. I think that people willing to keep the patch history for a number of years (and be prune-safe) should use topic branches rather than StGIT. Patches are meant to be more lightweight than topic branches and might have a shorter life-time. There were some people at the OLS BOF session even mentioning that they don't care about long-term history. The StGIT feature wish-list after the OLS is: - patch history (I'll probably use reflogs as you suggested) - configurable pull command (currently uses git-pull only) - commit directly to a patch which is not top - patch synchronisation between between branches (as some people, including me have the same patches based on different branches and they have scripts for moving the changes in one to the others) - document the workflow on the StGIT wiki - maybe a separate undo command rather than passing a --undo option to push and refresh -- Catalin - : 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