>> 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.
Is "git notes" the answer? http://progit.org/2010/08/25/notes.html 2011/2/1 Catalin Marinas <[email protected]>: > 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
