git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Tao Klerks <tao@klerks.biz>
To: git <git@vger.kernel.org>
Subject: branch.autoSetupMerge option for "if name matches only"?
Date: Thu, 3 Feb 2022 19:58:15 +0100	[thread overview]
Message-ID: <CAPMMpog6vKBfYEWqKDgK7YQQ96pPVMH7hYPXUHMnJsgLNgYMXA@mail.gmail.com> (raw)

Hi folks,

In trying to recommend sane simple understandable git flows for large
numbers of (often not git-proficient) users, I've found upstream
tracking branches to be a sticky area.

The main problem is that when users intentionally create a new branch
"test1" from origin/master, for example, they automatically get
upstream tracking... but after they've pushed their new branch to the
remote, they (unless they do something "wrong") typically have
tracking switched to "origin/test1" (after a weird error about not
pushing to a differently-named upstream - because they have
push.default set to "simple", the safe default - unless they're using
a GUI that sweeps this under the rug). So the behavior of "pull"
changes dramatically, from the user's perspective, after the first
time they push. Until that point, the system is behaving "weird".

On the other hand, when another user wants to work on "test1"
directly, they branch from "origin/test1", they get upstream tracking,
and everything is normal/predictable.

I *think* the simplest / most understandable behavior for most users
would be a variation on the current branch.autoSetupMerge=true
behavior, except *only set up tracking if the local branch name
matches*.

This new branch.autoSetupMerge behavior (dare we call it "simple", to
match push.default?) would mean that when branching from origin/master
to test1, you would not get an upstream. Pull would say something like
"hey, you haven't pushed yet", and everything would be understandable.

Is this a scheme that makes sense to people here?

Alternatively, another workable option for my not-so-sophisticated
users would be something like branch.autoSetupMerge=current, which
would simply always assume the same-name branch on the same remote. If
this were a new branch, initial pulls would say "but there's no such
branch on the remote!", and the first push would be even simpler,
succeeding without the current surprising "The current branch has no
upstream branch -0 run this slightly-more-complex command" message.

Are my users the only ones who get caught out by the default tracking
behavior when branching from a different upstream branch (but *expect*
tracking when creating a local instance of a remote branch)?

Thanks,
Tao

             reply	other threads:[~2022-02-03 18:58 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-02-03 18:58 Tao Klerks [this message]
2022-02-09 13:46 ` branch.autoSetupMerge option for "if name matches only"? Xavier Morel
2022-02-24 16:47   ` Tao Klerks

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=CAPMMpog6vKBfYEWqKDgK7YQQ96pPVMH7hYPXUHMnJsgLNgYMXA@mail.gmail.com \
    --to=tao@klerks.biz \
    --cc=git@vger.kernel.org \
    /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).