On 1 February 2011 14:16, Marc Herbert <[email protected]> wrote: >>>> 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). > > This looks like a big change indeed. I use patch names a lot. I do not > think I could reshuffle my stack as quickly and reliably as today if > they are gone. Generated names are usually truncated before being > complete, sometimes even truncated before being meaningful. Yet they > are too long to type on the command line.
That's why I raised the issue. I don't want to (badly) break existing habits by no longer allowing patch renaming (or shorter patch names). I don't use the emacs interface at all, just the command line and I'm not sure if I could cope with too long patch names. > Couldn't a new stg patch name be sneaked into some "private"/reserved > git metadata field? I'm not sure. We could add some field in the message as well but I was looking for easy interworking with standard "git rebase". Once you touch the stack outside StGit, it gets confused because commit ids no longer match the patches. > Besides this naming issue I agree that the general direction makes a > lot of sense. Well, actually the patch naming becomes the real issue. If we have patch names we need additional metadata. >>> 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". > > I started looking into Stacked Git when I hit a wall with git stash. > To me Stacked Git looks like a superior version of git stash. A tiny > bit slower and more complex to use, and of course an order of > magnitude more powerful. I am not sure this makes sense but... I think > both should be merged together into a single, unified product. That's not easy, mainly because StGit is written in Python and the Git people would prefer C, sh or perl. I thought about a simple git-patch script to push/pop commits from a stack but using SHA1 keys rather than patch names. But I would still prefer to work on StGit :). > The > user interface of this day-dreaming software would make simple things > simple (git stash) and complex things possible (Stacked Git). > > In a shorter term, maybe could git stash make a few steps into Stacked > Git direction and accept a few "upgrades"/modifications if Stacked > Git's needs them. git stash could be changed to stash a commit inside the stack and rebase the rest of the commits. That would give minimal StGit functionality. -- Catalin _______________________________________________ stgit-users mailing list [email protected] https://mail.gna.org/listinfo/stgit-users
