Re: push.default: current vs upstream

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

In message <CA+7g9JxK5DHj3vbdGgF2dEJxvn=_ZfjAv7Y+AL_P-aO1FVB6-w@xxxxxxxxxxxxxx>, Nathan Gray writes:

    If a user does some work on his new "features/frobnitz" branch and
    does a "git push" only to find that his work has been committed to the
    company's master branch he will be confused, frustrated, and publicly
    embarrassed.  He then has to apologize and figure out how to revert
    the changes.  I really don't see any scenario where that user ends up
    saying "oh yeah, I guess git was right and I was wrong."

When working with a single remote, I tend to agree with you (though
since I also think receive.denyDeletes should be on by default for
shared repos the public humiliation of creating a branch when you did
not mean to might still exist but of course it will be less damaging
to others) .  However, tracking really comes into its own when working
with multiple remotes.  Is creating a stumbling block between naïve
use and more sophisticated use really necessary?

However, the current message for this use case could seem to be
tweaked to take care of this:

$ git branch BB origin/B
Branch BB set up to track remote branch B from origin.

Add "If you push your changes will go there."
And "See git branch --upstream to modify both settings"

This provides the power of tracking with smaller possibility of
the type of embarrassment you envision.

					-Seth Robertson
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at

[Newbies FAQ]     [Linux Kernel Development]     [Free Online Dating]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Free Online Dating]     [Photo]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]     [Linux Resources]

Add to Google