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

[Junio C Hamano <gitster@pobox.com>]

Jeff King <peff@peff.net> writes:

> Two caveats before I go further:
>
>   1. You might argue that the real problem is that I'm building the
>      tentative change somewhere inappropriate.

No, that is completely normal for a developer to start into one direction
and then later realize something and change his course.  In fact, many
parts of Git strive to help you avoid being bound by premature commitments
(e.g. "checkout [-m] <branch>" takes local changes with you).  I think
this discussion is only showing that the @{upstream} part wasn't as
carefully designed as other parts of the system.

>   2. I really just want everything based off of origin/master, because
>      that is an implicit part of my workflow for this project.

I think this probably shows that "autosetupmerge" mechanism is not
polished enough.  Perhaps it can take, in addition to "true/false", a ref
in refs/remotes namespace, or something.  If you have "these branches are
to be off of this, this other set of branches are to be off of that", it
may need to become more elaborate.

> 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).

Yeah, the above is starting to sound a bit overengineered black magic.

>> Perhaps this can be a good sample entry for the experimental "tracker"
>> thing to keep track of to see how the workflow will evolve around it;
>> unless neither of us would get to work on it immediately, it is very
>> likely to be forgotten, as this is a tangent in the overall discussion,
>> even though the bug is real and solution is clear.

Heh, I find myself already forgetting what this "clear bug" was and having
to look up in your message (the issue is "git push $there" when $there
does not match branch.$current.remote, it should error out).

> 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.

That is why I think any demand (I wouldn't call it "proposal" or
"suggestion") to this project to use tracker fundamentally is flawed.

> 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.

I agree with this 100%.  If it takes more than just adding an email
address to Cc: line to either a tracker bot or a human project secretary,
I cannot be bothered to spend extra 10 minutes to go to an extra web site,
log-in and fill the form fields.