Re: Minor annoyance with git push

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

 



Hi,

On Wed, 20 Feb 2008, Jay Soffian wrote:

> On Feb 20, 2008 8:06 AM, Johannes Schindelin <Johannes.Schindelin@xxxxxx> wrote:
> >
> > On Wed, 20 Feb 2008, Junio C Hamano wrote:
> >
> > > Putting this "push = HEAD" by default when "git clone" and "git 
> > > remote add" creates the [remote "$remote"] section is probably 
> > > possible, and at that stage we may even be able to do the "if the 
> > > other end is shared, then set this up automagically", as the result 
> > > of the magic can be inspected in the resulting config file.
> >
> > I think this is too magic, both of it.  Once people get used to "git 
> > push" being implicitly "git push origin HEAD", why should they not 
> > expect "git push <somewhere-else>" to push "HEAD" implicitly, too?
> 
> Well then, how about (don't cringe too much now...)
> 
>   push.conservative = true
> 
> If enabled and "git push" is run w/o arguments, it will first emit what 
> it plans to push and then prompt with "yes/no." I'm kinda opposed to 
> silly prompts -- folks just always go right past them -- so I dunno.
> 
> But it does make the operation a bit more safe I guess.

That depends awfully on your definition of "safe".

I, for one, hate the idea already, that I am "safe" when "git push" does 
not do the thing I asked it to, and which it has done for a couple of 
years now without complaint, and which I have gotten used to.

And then, there will be a great confusion for me, since I work on 5 
different machines on an average day, with 5 different git versions, and 
having different config settings.

That is not "safe" for me.

Thankyouverymuch,
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