From: Linus Torvalds <torvalds@osdl.org>
To: Junio C Hamano <junkio@cox.net>
Cc: git@vger.kernel.org
Subject: Re: My Itchlist
Date: Fri, 5 Aug 2005 19:39:01 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.58.0508051924390.3258@g5.osdl.org> (raw)
In-Reply-To: <7v8xzfde7t.fsf@assigned-by-dhcp.cox.net>
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
next prev parent reply other threads:[~2005-08-06 2:39 UTC|newest]
Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-08-06 1:52 My Itchlist Junio C Hamano
2005-08-06 2:39 ` Linus Torvalds [this message]
2005-08-06 6:50 ` Johannes Schindelin
2005-08-06 19:04 ` Junio C Hamano
2005-08-13 20:05 ` Petr Baudis
2005-08-07 6:00 ` GIT 0.99.4 (preview) Junio C Hamano
2005-08-08 3:18 ` Horst von Brand
2005-08-08 9:09 ` GIT 0.99.4 preview: current status Junio C Hamano
2005-08-08 17:38 ` Request for help from binary packaging people Junio C Hamano
2005-08-08 18:20 ` Sergey Vlasov
2005-08-08 18:58 ` Chris Wright
2005-08-08 22:02 ` Junio C Hamano
2005-08-08 22:21 ` Chris Wright
2005-08-08 22:49 ` Junio C Hamano
2005-08-10 21:15 ` Matthias Urlichs
2005-08-10 22:11 ` [PATCH] Debian packaging for 0.99.4 Matthias Urlichs
2005-08-10 22:56 ` Martin Langhoff
2005-08-10 23:39 ` Matthias Urlichs
2005-08-11 3:17 ` Sebastian Kuzminsky
2005-08-11 4:44 ` Martin Langhoff
2005-08-11 5:01 ` Sebastian Kuzminsky
2005-08-11 6:12 ` Junio C Hamano
2005-08-11 5:05 ` Linus Torvalds
2005-08-11 5:30 ` Johannes Schindelin
2005-08-11 5:48 ` Sebastian Kuzminsky
2005-08-11 16:04 ` Matthias Urlichs
2005-08-11 16:30 ` Linus Torvalds
2005-08-11 19:06 ` Sebastian Kuzminsky
2005-08-11 20:15 ` Sam Ravnborg
2005-08-11 20:23 ` Sebastian Kuzminsky
2005-08-11 20:32 ` Matthias Urlichs
2005-08-11 20:44 ` Sebastian Kuzminsky
2005-08-11 20:24 ` Matthias Urlichs
2005-08-11 20:32 ` Sam Ravnborg
2005-08-11 22:13 ` Alan Chandler
2005-08-11 22:18 ` Sebastian Kuzminsky
2005-08-12 8:34 ` Matthias Urlichs
2005-08-12 8:41 ` David Lang
2005-08-12 10:35 ` Matthias Urlichs
2005-08-13 23:57 ` Ryan Anderson
2005-08-14 0:11 ` Matthias Urlichs
2005-08-15 5:08 ` Ryan Anderson
2005-08-14 0:48 ` Junio C Hamano
2005-08-14 0:49 ` Junio C Hamano
2005-08-11 21:51 ` Linus Torvalds
2005-08-11 21:53 ` Linus Torvalds
2005-08-11 22:20 ` Sebastian Kuzminsky
2005-08-11 23:09 ` Christian Meder
2005-08-11 23:12 ` Matthias Urlichs
2005-08-12 8:08 ` [PATCH] Debian packaging for 0.99.4 [u] Andreas Jellinghaus [c]
2005-08-11 19:11 ` [PATCH] Debian packaging for 0.99.4 Junio C Hamano
2005-08-11 21:45 ` Gene Heskett
2005-08-11 22:21 ` Junio C Hamano
[not found] ` <7vd5olqtvp.fsf@assigned-by-dhcp.cox.net>
[not found] ` <20050810235436.GW28270@kiste.smurf.noris.de>
2005-08-12 20:21 ` Junio C Hamano
2005-08-12 22:54 ` Martin Langhoff
2005-08-13 0:41 ` Matthias Urlichs
2005-08-13 0:38 ` [PATCH] more Debian packaging fixes Matthias Urlichs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.58.0508051924390.3258@g5.osdl.org \
--to=torvalds@osdl.org \
--cc=git@vger.kernel.org \
--cc=junkio@cox.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).