On 1 February 2011 07:11, Karl Wiberg <[email protected]> wrote:
> On Sun, Jan 30, 2011 at 00:01, Catalin Marinas <[email protected]>
> wrote:
>> It's been a while since the last StGit release, mainly because it had
>> all the features I needed (well, a few bug fixes since then that
>> should have been released).
>>
>> Anyway, I recently had to work in a team on a Linux kernel project and
>> because our patches were interdependent, we decided that the best
>> approach is to share the same branch on a common repository. But we
>> also had to keep patches relatively clean for pushing upstream
>> (http://git.kernel.org/?p=linux/kernel/git/cmarinas/linux-2.6-cm.git;a=shortlog;h=refs/heads/arm-lpae).
>>
>> To make merging between us easier, we went with using plain Git and
>> instead of refreshing patches (the StGit way) we used new commits with
>> the "fixup!" prefix. At some point one of us did a "git rebase -i
>> --autosquash" to bring the fixups into patches (and some other
>> clean-up, patch reordering). It all went well but I missed StGit in
>> this workflow.
>>
>> What's missing in StGit is easy interworking with git commands like
>> commit and rebase. This could be fixed by changing (reducing) the
>> StGit metada to rely more on what Git already provides. The main
>> visible effect would be patch names becoming automatic, similar to
>> those generated by "stg uncommit" but without the possibility of
>> renaming. The corresponding --name options and the "new" and "rename"
>> commands would also disappear ("new" can be replaced by either "git
>> commit" or an "stg commit" alias).
>>
>> The base of the stack is no longer maintained by StGit but determined
>> as the common ancestor between the current branch and a
>> parent/upstream branch (maybe defaulting to origin/master). All the
>> commits from the common ancestor to HEAD are considered applied
>> patches.
>>
>> The unapplied/popped patches (commits) could be linked into a separate
>> refs/heads/<branch>.unapplied. The refs/<branch>/patches/<patch-name>
>> are no longer created since refs/heads/* files can reach any of the
>> applied or unapplied patches. The standard Git reflog can be used for
>> undo information (though not infinite undo).
>>
>> Any thoughts? I don't want to start implementing this if people find
>> the UI changes annoying.
>
> I'm with you regarding the applied patches---I've had the exact same
> idea myself. As you say, the big user-visible downside is the loss of
> user-defined patch names. I don't really use that feature, so it's
> fine by me, but it's a huge UI change.
I think the idea appeared when someone asked us if StGit can work
better with git rebase. But I didn't need this feature until recently.
We can release the current HEAD as 0.15.1 and then make the UI change
in a 0.16.
> For unapplied patches, we could look into "git stash"---I haven't done
> that yet, but I think it might be a good fit. If so, I think we've
> completely eliminated all StGit-specific metadata and achieved
> Nirvana.
At a first look, there may be some issues with "git stash". Currently
it seems to be globally stored in refs/stash with some "On <branch>:"
prefix. It may need more processing on the StGit side with multiple
branches.
Popping an StGit patch could be slower with git stash. We currently
don't do anything with the index or worktree when popping a patch.
With stash we would have to.
A related question - git stash stores the the last patch in refs/stash
and previous patches in the stash@{*} reflog. Does the reflog resist
through a "git gc"?
For unapplied patches, we could create something like git stash but
without worktree information, just the index (tree). If he reflog is
preserved through "git gc", we could easily save popped patches in the
reflog. Otherwise we may need to chain them with a second parent.
Most of this looks doable with the new lib infrastructure, some
changes to PatchOrder and Patch classes and of course converting
additional commands.
BTW, I also plan to make stg status and alias to git status. We lose
the --reset option but if StGit is safe with git changes, people can
just run "git reset --hard".
--
Catalin
_______________________________________________
stgit-users mailing list
[email protected]
https://mail.gna.org/listinfo/stgit-users
