Re: Random Git Issues/Wishlist

[Catalin Marinas <catalin.marinas@arm.com>]

Shawn Pearce <spearce@spearce.org> wrote:
> Petr Baudis <pasky@suse.cz> 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