Re: [RFC PATCH] push: start warning upcoming default change for push.default

On Tue, Mar 13, 2012 at 03:54:26PM -0700, Junio C Hamano wrote:

I think branch.*.rebase / pull.rebase is the only current example. But yeah, having a hierarchy like that makes sense to me.

Sorry, reading my example again, I was completely unclear. I was trying to simplify it down to a readable case and ended up omitting the parts that would have it make any sense. So let me try again:

I play around with a fix or a feature on top of some random branch. Eventually, I realize that this is a promising direction, and want to make a topic branch. I'm in a state where I have some work-in-progress commits on top of a random point (which yes, means my commits might be totally bogus when ported to origin/master, but in practice, they are close enough).

One option would be:

  $ git checkout -b jk/bug-fix origin/master
  $ git cherry-pick @{-1}~2..@{-1}

which sets up the upstream appropriately. But what I often end up doing is:

  $ git checkout -b jk/bug-fix
  $ git rebase -i --onto origin/master HEAD~2

to tweak the patch ordering. Or even:

  $ git checkout -b jk/bug-fix
  $ hack hack hack
  [oops, this should be based on master, not where I was]
  $ git rebase --onto origin/master HEAD~2

In all three cases, I end up in the same state of history, but only in the first one is my upstream config even remotely useful. There are other variants, too, where I use "stash" and "reset" to end up building on the history I want.

Two caveats before I go further:

  1. You might argue that the real problem is that I'm building the
     tentative change somewhere inappropriate. And that is kind of true,
     and this could all be averted by running "git checkout" in the
     first place to build on the appropriate spot. Though I do sometimes
     do that, too:

       $ git checkout origin/master
       $ test test test
       [ok, bug exists]
       $ fix fix fix
       [ok, this is worth a topic branch]
       $ git checkout -b jk/bug-fix

     and it also does not set up the upstream config. It would if I used
     a local "master" branch, but I do not have one (and I do not want
     one, as it would just be a pain to keep in sync with
     origin/master).

  2. I really just want everything based off of origin/master, because
     that is an implicit part of my workflow for this project. So I am
     not arguing that what "git checkout -b" does is wrong given the
     information I have given git, but that there is no place for me to
     give git that information.

So originally, I had a vague notion in my mind that I wanted some way to tell "no, really, I always want to think of origin/master as the upstream unless I explicitly tell you otherwise". Something like:

  $ git config branch.defaultUpstream refs/remotes/origin/master
  $ git config branch.autosetupmerge false

But having just typed out several examples, I think git _could_ figure this out automatically. My real complaint is that as I use lower-level tools to adjust the basis of my history, the upstream config is not similarly updated. So another option would be:

  1. git-rebase could re-adjust the upstream config when using "--onto"
     with a branch parameter.

  2. git-reset could re-adjust the upstream config when moving directly
     to a branch.

  3. When we detach HEAD, remember the original branch name (in
     .git/ORIGINAL_BRANCH or similar); when a branch is created from
     the detached HEAD, set up ORIGINAL_BRANCH as the upstream. You'd
     probably want the "rebase" and "reset" in steps (1) and (2) to
     update ORIGINAL_BRANCH when you're on a detached HEAD.

I think that would perfectly fit my workflow. But I'm not sure if other people would be confused by these operations changing the upstream config (e.g., if you expect "jk/bug-fix" to have an upstream of "origin/jk/bug-fix", when such a change would not be welcome).

If upstream is "here is where my topic is based from", then the ahead/behind tells you how big your topic is (ahead), and whether it might be a candidate for rebasing (behind). If your upstream is "the central repo version of topic", then it tells you what work you have yet to share with others (ahead), and what work others have done on the topic that you could merge (behind).

I agree this is a candidate for that. But this is where the concept of the tracker breaks down. Who is supposed to update it? You or me? Some volunteer who agrees to migrate email discussion into the tracker? I suspect the latter will not work for a point buried so deeply in a thread. Which leaves you and me.

I specifically stayed out of the tracker discussion this time around because all I had to contribute was "please no, web-based tools are an abomination". But now that we see a potential use-case in practice, I am realizing that I would not mind at all making a note in a todo file, or even sending an email. But the thought of filling out a structured problem report to go into a web-based database makes me not want to bother. Perhaps it is just my natural curmudgeonliness, but I think part of it is that I know I am unlikely to actually visit the page to ever retrieve the information.

I dunno.

-Peff