Catalin Marinas wrote: > On 10/12/06, Jakub Narebski <jnareb@xxxxxxxxx> wrote: >> Catalin Marinas wrote: >>> Yes, only for updating HEAD. The refs in refs/patches/<branch>/ are >>> written directly. I initialy wanted to add patch history support using >>> reflogs and added "git-update-ref -m ..." for the patch commits but I >>> found slow the pushing operation a bit. Do you only want to track the >>> reflogs for HEAD? >> >> Yes, I want for StGit to provide reasons when updating HEAD. I know that >> StGit manages it's own versioning of patches not using reflog -- fine. >> What matters for me is reflog for HEAD after "stg commit; stg clean". > > Just curious, do you run the "stg commit; stg clean" commands together > and in this order? Neither of them would update the HEAD. The "commit" > command simply removes the StGIT metadata for the applied patches > since it no longer needs to track them (permanently stored to the > repository). It doesn't change HEAD. The "clean" command only affects > the HEAD if there are empty applied patches but after a "commit" there > won't be any patches (only the unapplied ones which do not affect > HEAD). > > Maybe we could have reflog info for "push", "refresh", some undo > operations. Are they of any use (I haven't used them so I can't tell)? Ooops, I haven't been clear enough. I meant that afer "stg commit; stg clean" I won't have any StGIT metadata, but I'd have git metadata in reflog. I'd like to have info in reflog for each command which changes head; for example "push", "refresh", perhaps "pop", "float", "uncommit". Just so I don't have long sequence of ref changes in reflog without description of said changes after some work with StGIT on branch. BTW. currently I use StGIT to manage a series of commits on feature branch which implements step-by-step single feature, and would be later send as a patch series. With StGIT I can work on final patch in series, notice that underlying feature developed in earlier patch (earlier commit) needs modification, so I do refresh, pop until given patch, change patch, push all, and work on patch. Or for example if I notice that I'd have to implement some basic feature separately, best at beginning: pop all, create new patch etc. Very nice. -- Jakub Narebski Poland - 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