login
Search
Hello!
I was recently disappointed to learn that one of the Linux drivers
(bcm43xx_mac80211, to be precise) switched from git to quilt. I asked
whether StGIT was considered, a discussion followed, and I think the key
points need to be shared with StGIT developers. I'll add some of my
ideas to the mix.
The main point in favor of quilt is that it allows to edit the patches
with the text editor. One can pop all patches, edit them and push the
all back.
I don't suggest that StGIT gives up on the git-based storage, but this
mode of operation could be implemented in two ways.
One is to have a command opposite to "export". It would read the files
that "export" produces, replacing the existing patches.
Another approach would be to reexamine the patch after "stg refresh -es"
and to apply it instead of the original patch. If the patch doesn't
apply, the options would be to discard the edits or to re-launch the
editor.
Next issue is that it should be possible to create a patch in one
operation. StGIT follows quilt too closely here in requiring "new" and
"refresh", instead of utilizing the advantage of the workflow that
allows immediate editing of the sources without any commands.
Basically, I want one command that:
1) shows user what was changed
2) allows user to name the patch
3) allows user to describe the patch
4) allows user to exclude files from the patch
5) doesn't require another command to put the changes to the patch
I think the most natural approach would be to enhance "stg new". I see
"stg new -s" is supposed to show the changes, but it's currently broken.
This is run in a clean StGIT repository with no patches:
$ stg new -s foo
Traceback (most recent call last):
File "/home/proski/bin/stg", line 43, in <module>
main()
File "home/proski/lib/python2.5/site-packages/stgit/main.py", line 284, in main
File "/usr/lib64/python2.5/new.py", line 82, in func
File "home/proski/lib/python2.5/site-packages/stgit/stack.py", line 842, in ...git's shiny new git rebase -i has removed, for me, those times when I needed stgit. Perhaps those who've move from git to quilt would try again when 1.5.3 is out with the magic that is "rebase -i". Andy -- Dr Andy Parkins, M Eng (hons), MIET andyparkins@gmail.com -
Hello, Andy! I don't understand how one option can replace StGIT. I assume you were trying to avoid StGIT already, and "git-rebase -i" was just the last missing piece. It would be great if you could tell me how your approach would deal with the issue of editable patches I mentioned already. In case I was unclear, here's the quote from one of the developers: [quote] Sometimes, I just make patches in quilt, then I do "quilt refresh", "quilt pop -a", "cd patches" and modify the patches and series file manually, e.g. by moving one patch from one file into the other. The "cd ..", "quilt push -a" and off I am. That the "database" of quilt is in a known format and I can hack on it with an editor is a plus for me :-) [end of quote] -- Regards, Pavel Roskin -
I agree with Andy. Aside from the performance issues that I am currently having with a 55 patch series, "rebase -i" (and its predecessor script from Dscho) have been a major part of my toolkit, to the point that I really don't need something like StGIT on my system. (Regarding the performance, cherry-picking 55 patches is slow, especially when many of them would apply trivially with Oh, I'm sure there's features in StGIT that are useful that aren't available via "rebase -i". But to be honest, "rebase -i" is good enough. It just ain't fast enough. Editing a patch that is 50 Uh, the "database" of "rebase -i" is just a chain of commits in a git repository. These are a well known format and can be easily edited with "rebase -i". This is a real plus for me as the series can be edited directly in my favorite vi clone, then applied to my working directory. ;-) -- Shawn. -
I understand that "git-rebase -i" is good for keeping local changes up-to-date, but the real issue is managing the local patches so that they can be enhanced to the point that they are ready for submission. That includes such things as moving chunks between patches, editing descriptions, joining patches together, sorting patches into groups by their urgency and so on. Keeping the patches up-to-date is just one aspect. Anyway, I'm going to give "git-rebase -i" a try. -- Regards, Pavel Roskin -
FWIW, I have written a couple of scripts to help moving stuff around between patches. Those are not yet integrated in stgit proper, and it happens that the 0.13 tarball does not contain them, they are only available from the git tree (better use my tree[1], since I updated them recently). Most notably relevant to this use are stg-fold-files-from and stg-dispatch, to move diff hunks between patches. They only cases (off the top of my hand) where they do not fit my needs are: - when I need to move a part of a diff hunk that is not possible to isolate using -U<n> (but I have read interesting things about git-gui for such functionnality, so that will surely come one day) - when I need to move git-specific diff hunks (moves, permissions, etc.), since it uses filterdiff, which is not git-aware (yet ?) (in short, there are lots of dev to do in/around stgit, but there are not as many contributors as there is for git - hint, hint ;) If there are other typical situations where they need to edit patches, I'd be interested to hear about them. Not to avoid implementing patch edition in stgit, since it is occasionally useful to fix a typo when reviewing at refresh time, but to see what higher-level tools we could provide. Best regards, -- Yann [1] gitweb at http://repo.or.cz/w/stgit/ydirson.git -
That's probably because I haven't updated the MANIFEST.in file (I don't look in the contrib directory much :-)). -- Catalin -
FWIW, I'm in the same camp. I'm a huge fan of quilt, and used it
extensively and with large stacks. (Actually, I still use it whenever
I don't want to bother with importing-to-git a large CVS or SVN
project that I'm tracking.) When I started using git (and up until
the first time I used git-rebase -i), I assumed I'd eventually have to
use one of the quilt-like add-ons, but I wanted to hold off a little
while until I was comfortable with core-git.
But, after using git-rebase -i, I can't see why I'd need any
quilt-like add-on. Every time I use git-rebase -i, it's like I'm
Well, there are many different ways one might want to modify the
stack, but I find that most of them are quite easy with git-rebase -i.
IMO, here are things that are easier with git-rebase -i than with an
external patch stack:
- editing the headers (git-rebase makes it easy to find/select the
patch and even opens the editor for me)
- reordering patches
- combining patches (squashing)
- moving one file's diff from one patch to another
IMO, here are some things that would probably be easier with an external
patch stack:
- directly editing the diff hunks
- moving single diff hunks between patches
Maybe there are others, too, but these are things I just don't do
nearly as frequently as the things that git-rebase -i is good at. (I
That sounds more like an argument from familiarity than anything else.
Nobody (reasonable) directly hacks git's internal binary format. The
"known format" I can hack with my editor is just the content itself.
Honestly, when you have commit-handling that is as good as git's,
there's really very little appeal left to editing the diffs directly.
-chris
-
Hi, Good to hear! (I almost missed this mail, since I usually skip the StGit Of course, you _could_ just export the patches as one mbox, edit them, and reapply them: git format-patch --stdout HEAD~4 > mbox.txt $EDITOR mbox.txt # even moving hunks git reset --hard HEAD~4 git am mbox.txt If the need is great enough, it should be easy to hack something like this into git rebase -i. Ciao, Dscho -
This should be already possible (although I never used it), with "stg Sure, something like this could be done. A syntax like the following would IMHO fit in how things are done, but does not exactly address 4: $ stg new <name> -m <msg> -s [--] <files> <to> <add> Maybe another --exclude flag to reverse the meaning of the listed Hm, I'm not sure what -s would be supposed to show here, since we're asking for the creation of a patch, which currently always starts empty. Especially confusing is that if there are already applied patches, the diff shown is the one of the previous top patch - and if there is no applied patches, we get the exception you noticed. This appears to occur when there is no description file, or when it is empty. Thanks for the report. I also tried with "stg refresh -m ''" to see if it caused the same problem, but it appears to have another problem instead: it does not refresh the patch description at all. My guess is that we should not allow empty patch description (and maybe fill it with provided patchname). What did you want to acheieve Added to wishes: https://gna.org/bugs/index.php?9673 Thanks, -- Yann -
The story for the 'new -s' option was that with StGIT (not possible with Quilt), one can start modifying the local tree and only create a patch afterwards. The newly created patch is always empty, even if there were local changes and showing them was useful for writing the patch description. One can use refresh for checking the changes in. Indeed, the 'new' command can be improved to have part of the Are you sure it doesn't only show the local changes (which you might I'll still like to keep it for the rare cases when I use the diff to I think we should put some default patch description. -- Catalin -
And that's what I really like about StGIT. I like that I can edit code I agree. Sometimes it's too early to write a description. -- Regards, Pavel Roskin -
<shameless plugs> If Guilt doesn't find a description in the patch file during push, it uses "patch $patchname" as the commit message. This makes it enough of an eye-sore that you notice before you submit the patches upstream :) Josef 'Jeff' Sipek. -- Failure is not an option, It comes bundled with your Microsoft product. -
You might also ask them if they considered "guilt", which uses
text-based patches. It's a lot easier to use, and if they really want
quilt-like functionality, "guilt" will provide it.
My main reason for avoiding StGIT is the fact that at least in the
past, I've found it very fragile when I forget and use "git checkout"
instead of "stg branch" to switch between branches. The fact that
sometimes you have to use the StGit variant of basic git commands has
always struck me as confusing, and then recovering when things get
screwed can be exciting. Usually it's when I start having to cut and
paste SHA1 hashes and running diffs to recreate my patch series after
things get screwed is usually about the time when I wonder why I tried
using StGIT again. (Don't get me wrong; I'm sure I did something
really stupid, and wrong, that caused things to get screwed up. My
complaint is that when I do something stupid, StGIT isn't robust and
is painful to recover from.)
That's why I like guilt; it doesn't require that you use alternate stg
commands for manipulating branches, and since it maintains an external
set of text patches, recovering is much easier; worst case I can just
do a "git reset --hard" and then follow it up with a guilt push -a.
And because it's so stupid simple, it's much rarer that something goes
seriously wrong that requires me to use a recovery procedure in the
first place.
Editing patch headers are also a lot easier with guilt; you can just
go ahead and edit them all, and then you can fresh them in git by
doing a "guilt pop -a; guilt push -a". Since it's not using a
git-based storage, it doesn't have to rewrite the whole patch stack
when you modify a single patch header; you can edit a whole bunch of
text headers and then refresh the git commit series just once.
Of course, that's just my preference; others may find StGIT more
convenient, or folks may find the new rebase -i to be better yet.
YMMV.
- Ted
-
FWIW, I exclusively use git-checkout to switch between git branches and stgit stacks, and it works like a charm. I don't remember ever seeing a problem with this, so I guess it has been fixed for a long time. But yes, there are still robustness issues with stgit. It looks like the user base is small, since there are not so many bugreports. We tend to take care about the workfows we use, and people with other workflows obviously should tell us what gets wrong :) Best regards, -- Yann -
I guess I should chime in. The goal behind guilt is to be very simple yet powerful enough to do what is FYI: v0.27 allows you to edit the patch headers with: guilt header -e Pavel, if you have any questions, you know where to ask :) Josef 'Jeff' Sipek. -- Don't drink and derive. Alcohol and algebra don't mix. -
Thanks everybody. guilt and "git-rebase -i" are on my list of things to try. -- Regards, Pavel Roskin -
Hi Pavel, All the interesting discussion usually happen during my holidays :-). If this is the main feature they need, they probably don't need git at all and quilt would be enough. I was using quilt before starting StGIT but the main problem I had with plain patches approach was the conflict solving. StGIT does a 'git-diff | git-apply' as a patch push optimization and we could even cache the diff but the current algorithm is that if git-apply fails, StGIT falls back to a three-way merge and even an interactive user merge (via xxdiff for example). I find the three-way merging (automatic or interactive) much more powerful than fuzzy patch application. If we would allow patch editing, the 'stg push' algorithms wouldn't know when git-apply failed because the patch was edited or the base was changed. Falling back to the three-way merge would lose the edited patch. If one doesn't need three-way merging, quilt is good enough. Other advantages of the three-way merging is the detection of full patches or hunks merged upstream (the former can also be achieved by testing the reverse-application of the patches). I don't usually edit patches during development, I prefer to edit the source files and review the diff. It happens many times to move hunks between patches but I usually towards the bottom patches in the stack (using stg export and emacs) and the three-way merging automatically As Yann said, we already have 'stg import --replace'. I mainly use this feature with series sent to me and when they need some editing to apply cleanly. There is also 'stg import --ignore' to ignore the patches already applied (mainly when the importing fails in the middle That's an interesting idea but maybe we should have a separate command like --edit-full to edit the full patch + log (part of the Thanks for reporting this. I don't use the --showpatch options much Indeed, the SMTP Python objects already provide support for TLS via starttls(). -- Catalin -
I never really understood why commit message editing had to be part of the "refresh" command. If it were a separate command and not tied to refresh, we could allow editing the message (and author, committer, date, ...) of any commit in the stack -- since the tree objects would be unchanged, we could just reuse the same tree objects when rewriting the commit objects on top of it. That's obviously not going to work if we allow editing of the patch. But patch editing isn't a good fit as a refresh switch either, since it's not at all related to replacing the tree of the current patch with the working tree. -- Karl Hasselstr
On 2007-08-06 08:42:05 -0400, Pavel Roskin wrote: > On Mon, 2007-08-06 at 11:56 +0200, Karl Hasselstr
OK, I understand it wasn't a good idea to ask for improvement on behalf I suggest that StGIT saves the original patch and then does interdiff between the old and the new patch. The original patch is applied first just as it's applied now, and then the difference is applied on top of that. What I normally need to edit is the comments. Editing the code is risky, although I may want to rename some badly named variable I hate to be in a situation when I want to edit something but cannot, because I didn't run some command before. What I like about StGIT is that it allows me to do things my way. And hg provides a great example. -- Regards, Pavel Roskin -
