Re: [PATCH 2/2] Add support for URLs to git-apply

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Hi,

On Mon, 10 Dec 2007, Mike Hommey wrote:

> On Sun, Dec 09, 2007 at 02:54:58PM -0800, Junio C Hamano wrote:
> > Andreas Ericsson <ae@xxxxxx> writes:
> > 
> > > Mike Hommey wrote:
> > >> Instead of doing several "wget -O - url | git-apply -" in a raw, 
> > >> you now can just git-apply url1 url2 ...
> > >>
> > >
> > > I seriously like this idea. Combined with gitweb (or cgit), it could 
> > > be used as a cherry-pick from someone else's repo :)
> > 
> > FWIW, my initial impression is that I seriously dislike this.  It may 
> > be good if the patch were to git-am, but when git-apply rejects an 
> > inapplicable patch, there won't be nothing left for you to recover 
> > with and you need to re-download the patch anyway.
> 
> There are some usecase differences between git-apply and git-am. 
> Probably, this change would be good to have on both.

But what about Junio's comments about a failed patch?  You really want to 
hammer that poor webserver?

My first thought when seeing your patch was: this would give us a chance 
to "clone" via gitweb.  And while doing so, all but kill those webservers.  
So I thought it was wrong.

When Junio mentioned git-am it was obvious to me that this is the "right" 
solution.

I mean, we go out of our way to be nice to the servers, putting more load 
onto the clients, because there are many clients, but only one server 
(which is unfair).

Please address these issues before further arguing that both apply and am 
should learn about URLs.

Ciao,
Dscho

-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux