Re: My Itchlist
Dear diary, on Sat, Aug 06, 2005 at 04:39:01AM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > On Fri, 5 Aug 2005, Junio C Hamano wrote: > > - teach git-apply "reverse" and possibly "fuzz". > > > > I think this might help Porcelain; currently they have to > > interpret git extended diff headers themselves. > > Reverse would definitely be useful. "fuzz" is really pretty dangerous. I > think that once a a patch doesn't apply, you really want to have helper > tools like a graphical "wiggle" etc, and that really means that it's not > "git-apply", it's something totally different. I don't know, but I come across fuzzy patches quite frequently and any problems have been always _extremely_ rare. And in any case, I can (and do) verify it right away by doing cg-diff and checking what changes did the patch really do. > And quite frankly, if you have a tool that can handle unified diffs > already, then extending it for the git rename stuff should be pretty easy. > It's not like we haven't wanted renaming patches for at least a _decade_ > already, it's just that nobody ever did them. That reminds me I should finally add support for renames to cg-patch... -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ If you want the holes in your knowledge showing up try teaching someone. -- Alan Cox - 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
Re: My Itchlist
Johannes Schindelin <[EMAIL PROTECTED]> writes: > I think that we need a method to do a push in reverse: If a central > repository has several branches, I might want to pull just those branches > where the local head is a strict parent of the remote side, and get > complains for the others. And maybe reference naming comes as a freebie > with that. I can first run "git ls-remote" to discover what are available heads and tags, and choose to "git fetch" without actually merging nor touching my references if I did not want to. I could then attempt to "git resolve" offline, and if it results in a real merge, not fast forward, and if I am in a hurry and do not want to risk merging without thinking, I can just keep my head and defer the merging part. I think that is what you are getting at by "pull only when local is a strict parent of the remote". It is really the matter of where the ancestry computation happens. You seem to think you would want to do it on the central server side, but I tend to think that should be done on the puller's side, like I outlined above. There are two reasons: (1) as you mentioned in a separate topic, the current upload-pack/fetch-pack protocol pair seems to put a nontrivial burden on the server side. I'd prefer to have the client side do more work. (2) You are interested in that remote branch, so while you may not want to merge the upstream changes into the branch you have your local modifications right away, it is likely you eventually will. Fetching the objects would not be a wasted traffic. What Linus said makes a lot of sense to me. While the current "git fetch" user interface captures a commonly used pattern of fetching a single remote reference and optionally storing that remote reference as a local reference under refs/heads, it is cumbersome to use when you want to slurp objects needed for multiple remote references and not store the references themselves anywhere. - 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
Re: My Itchlist
Hi, On Fri, 5 Aug 2005, Linus Torvalds wrote: > On Fri, 5 Aug 2005, Junio C Hamano wrote: > > > > - Teach fetch-pack reference renaming. > > Well, the fetch side at least needs it less. > > Right now the renaming means that you can only really fetch _one_ head at > a time, but that's at least a fairly common and important case, and you > can do the rest from there. > > And doing only one means that git-fetch-pack can just return the result > SHA1 of the head it was asked to fetch. In fact, even that could just be > extended to returning multiple heads: just return each SHA1 in order. No > "renaming" necessary, since it's then up to the user what to do with the > results. I think that we need a method to do a push in reverse: If a central repository has several branches, I might want to pull just those branches where the local head is a strict parent of the remote side, and get complains for the others. And maybe reference naming comes as a freebie with that. Ciao, Dscho - 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
Re: My Itchlist
On Fri, 5 Aug 2005, Junio C Hamano wrote: > > - Teach fetch-pack reference renaming. Well, the fetch side at least needs it less. Right now the renaming means that you can only really fetch _one_ head at a time, but that's at least a fairly common and important case, and you can do the rest from there. And doing only one means that git-fetch-pack can just return the result SHA1 of the head it was asked to fetch. In fact, even that could just be extended to returning multiple heads: just return each SHA1 in order. No "renaming" necessary, since it's then up to the user what to do with the results. In fact, many users don't even want to write the result to a ref _at_all_: they just use the raw name - no refs - to merge. So arguably it is _wrong_ to make git-fetch-pack write refs, because that just leads to the problem with temporary refs etc. "Local variables are good". > These are not 1.0 showstopper items but what I personally would > love to see. > > - teach mailsplit/mailinfo basic MIME (attachments and quoted-printable) > > Some people send patches in MIME quoted-printable. I could > drop them on the floor and ask the sender to resend, but I've > been being a nice guy, which currently involves manual > intervention. This really is a nasty problem. People add their own commentary etc, and the fact is, the maintainer _needs_ to edit it. Otherwise you'll have people saying "Hi there, I really like this thing, but I have this problem which this patch fixes" etc, which is all very nice, but dammit, that's simply not changelog material. Also, I definitely myself end up editing patches occasionally: fixing things up. Again, this is simply a major pain if the patch comes in as an attachment. So there are tons of reasons to just try to teach people that attachments are painful. Much better to teach people not to use them than having people use them and the tools "working" with them. > - teach git-apply "reverse" and possibly "fuzz". > > I think this might help Porcelain; currently they have to > interpret git extended diff headers themselves. Reverse would definitely be useful. "fuzz" is really pretty dangerous. I think that once a a patch doesn't apply, you really want to have helper tools like a graphical "wiggle" etc, and that really means that it's not "git-apply", it's something totally different. And quite frankly, if you have a tool that can handle unified diffs already, then extending it for the git rename stuff should be pretty easy. It's not like we haven't wanted renaming patches for at least a _decade_ already, it's just that nobody ever did them. So I'm hoping that git can act as a impetus for people to just finally have a standard way of saying "rename". EVERYBODY wants it. Anybody who ever sees a rename as a patch will always go "damn, it would be nice to have renames". And dammit, we have them, so let's try to push out the concept. And if that means that we should use rename patches and let non-git users have some pain until they say "ok, ok, it's a good idea, I'll do it. Uncle, uncle!", then maybe the world will be a better place. It's not like they can't see how git-apply does it already ;) Linus - 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
My Itchlist
Here is a short list of itches I would like to get scratched before 1.0. I may be forgetting something big, though, so if your favorite feature request is not included in the list please speak up. - Teach send-pack to use get_sha1() on the source side. In addition to a pattern that matches one reference on the source side, we should be able to use anything get_sha1() can grok. Hopefully I'll be looking into this over the weekend. - Teach fetch-pack reference renaming. On the push side, send-pack now knows updating arbitrary remote references from local references. We need something similar for fetching. I personally do not feel we need it for cloning but my cursory reading of clone-pack indicates the command is meant to work reasonably even in an already populated repository. If somebody have a good use case for it and a clean patch, I may be tempted to accept it. - Glossary documentation Johannes Schindelin is working on. I think coming up with the concensus of terms would come fairly quickly on the list. Updating docs to match the concensus may take some time. Help is greatly appreciated. - Makefile variables updates from Pasky. While I do not have objections to rename dest to DESTDIR and such Pasky proposes, I want to have a matching change to RPM and deb generation. I can speak basic debian/rules, but I am reluctant to touch RPM side of the things. Whether we do the dest/DESTDIR rename or not, we need to tweak binary packaging anyway, or stop installing the default templates. I can be talked into either way. My tentative plan is for 0.99.4 to finish send-pack, 0.99.5 to enhance fetch-pack, 0.99.6 to finish the first pass for the documentation updates and stabilizing the binary packaging. These are not 1.0 showstopper items but what I personally would love to see. - teach mailsplit/mailinfo basic MIME (attachments and quoted-printable) Some people send patches in MIME quoted-printable. I could drop them on the floor and ask the sender to resend, but I've been being a nice guy, which currently involves manual intervention. - teach git-apply "reverse" and possibly "fuzz". I think this might help Porcelain; currently they have to interpret git extended diff headers themselves. - commit template filler discussed with Pasky some time ago. - "rev-list a...b" should mean "rev-list `merge-base a b`..b" - 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
