Re: [egit-dev] Commit + Push no longer using "Push to origin" config

[<rsbecker@xxxxxxxxxxxxx>]

On March 22, 2022 5:58 PM, Thomas Wolf wrote:
>On 22.03.22 21:20 , Gunnar Wagenknecht wrote:
>> I noticed a change in the last release. The "Commit and Push" button no
longer
>seems to use the "Push to origin" configuration. It seems to push only the
specific
>branch.
>>
>> I work in feature branches a lot and use commit amend. This requires
force
>push, which I have enable in the "Push to origin" configuration.
>>
>> Is this an intentional change or a regression?
>
>It's intentional insofar as the code was changed and does what it's
supposed to do.
>See [1]. The problem is that the "Push to origin" spec, depending on how
it's
>configured, may actually push several branches.
>
>OTOH it's unintentional since I just didn't think of the force flag.
>
>It was changed because of bug 441031.[2] Apparently there are conflicting
wishes:
>some people would like the branch config to take precedence; others the
remote
>config.
>
>I'm not sure what the best thing to do here would be. I guess we'll have to
figure
>out something for that...
>
>1. Make push behave like "push to origin" again? Even if that would push
>    more than one branch?
>2. Do so only if the remote config has exactly one non-wildcard refspec?
>3. Leave as is now, but figure out a way to push or force push? (Bug
>    411219.[3])
>4. Add a preference where the user can choose whether to consider the
>    branch config (branch.<name>.merge) in preference over the remote
>    config?
>5. Something else?

Something else, please. Add a [] force check-box, and add an [] all
check-box, as with standard git. By default, push to the configured origin.
I guess you could specify some EGit-specific property that chooses all or
only the config or something else. But the .git/config should behave as
close to standard git as practical. While at it, [] tags might be useful
also. Of course this does not make things pretty or simple. I have to
support workflows with more clients than I care to number, so having as
close to predictable as possible (a.k.a. core git) is my preference.

One workflow in question is the rebase --autosquash --interactive, which is
used by a few Open-Source projects. In that case, a force is required almost
always, to squash pull requests down to single commits. I have not found a
good way to do this in EGit so went full CLI.

>If the remote has no push refspec, though, (1) would for many users not
consider
>branch.<name>.merge since push.default=simple by default.
>People would have to configure push.default=upstream explicitly otherwise,
>which may not always be appropriate either.
>
>I have no clear idea how to do (3). An extra checkbox might take too much
screen
>estate, but is otherwise the simplest option. (State would need to be
persisted
>per repo.) A "SplitButton" (Button with drop- down menu) as suggested in
bug
>411219 doesn't exist in SWT apparently because it doesn't exist natively on
all
>platforms; I don't think Cocoa has something that. Using Ctrl-Click or
Ctrl-Space for
>"force push" is not easily discoverable by the user and I'm off-hand not
even sure
>we'd have the keypress state in a mouse click event.

How about an expanding window/popup where all the options check-boxes live.
It's a bit like the hiding (X) in those annoying apps that have ads. Click
the expand arrow (or something) and the check-box options show up. I prefer
the clean interface EGit has now, but options are options and force is
really important and needs to be in the workflow.

>One thing I don't quite get: do you change the remote's push refspec every
time
>you switch branches to update the destination? That can't be a comfortable
>workflow either... I imagine you have something like
>+HEAD:refs/heads/some_branch. How do you set the destination per
>local feature branch?

The remote push refspec is supposed to change when you switch, based on the
configuration. If there is no refspec, you should consider prompting for it
from the set of existing origins, maybe a pulldown, or rejecting the push if
none is selected. A change like this should update .git/config.

Just my thoughts - but consistency is important for push and pull.

--Randall