Daniel Barkalow <[EMAIL PROTECTED]> wrote: > On Tue, 23 Aug 2005, Jan Veldeman wrote: >> The parents which should be visible to the outside, will always be versions >> of my development tree, which I have previously pushed out. My way of >> working would become: >> * make changes, all over the place, using stgit >> * still make changes (none of these gets tracked, intermittent versions are >> lost) >> * having a good day: changes looks good, I want to push this out: >> * push my tree out >> * stgit-free (which makes the pushed out commits, the new parents of my >> stgit patches) >> * restart from top > > I'm not sure how applicable to this situation stgit really is; I see stgit > as optimized for the case of a patch set which is basically done, where > you want to keep it applicable to the mainline as the mainline advances. > > For your application, I'd just have a git branch full of various stuff, > and then generate clean commits by branching mainline, diffing development > against it, cutting the diff down to just what I want to push, and > applying that. Then the clean patch goes into stgit.
StGIT has the 'refresh' command which allows a patch to be indefinitely modified (that's pretty much how I use StGIT). I use it for the case where I would like to keep the changes in separate logical entities (patches) but they are not independent enough to create separate branches. Take for example a new platform port, you can have some of the existing code re-worked in a patch, some CPU support in the next patch, basic platform support in another patch, some device drivers specific to this platform in yet another patch. Subsequent patches are dependent on the previous ones. Branching from the mainline for each of these features might not make sense and keeping all of them in the same branch can make maintenance a bit more difficult. -- Catalin - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
