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

On Wed, Mar 14, 2012 at 8:46 AM, Junio C Hamano [off-list ref] wrote:

Dmitry Potapov [off-list ref] writes:

quoted

quoted

One can easily get in this situation even in a kernel-style workflow:
work from your desktop, push, work from your laptop, try to push and it
fails.

IMHO, when you often switch between your desktop and laptop, 'matching'
makes much more sense. If 'push' fails then usually I want to force non-
fast-forward push, because the new series contain reworked patches that
already were on the other computer.

You are free to live dangerously, but please do not teach that to other
people.

Is it more dangerous than using "git reset --hard somewhere" ?
I believe both cases I should be able to recover the lost using reflog.
Anyway, so far I have never had any problem, because I do "git push"
first and then look at failures and decide whether I want to discard
the old series on the remote end.

Switching between two machines A and B is done a lot more safely if you
arrange them to cross pull from each other, i.e. on machine A, remotes/B/*
is where you keep copies of branches of B to with either of these

       machineA$ git fetch B refs/heads/*:refs/remotes/B/*
       machineB$ git push A refs/heads/*:refs/remotes/B/*

(the latter is to emulate the former "fetch" you wish to run on A to get
data from B in the reverse direction), and similarly on machine B, you use
remotes/A/* to keep copies of branches of A.

I am aware about that, but the thing that stops me from using this is
there is no way to delete automatically all references from the remote
end that were deleted locally. (There is --mirror option, which can do
this, but it is incompatible with refspecs)

If I use only "git fetch B ...", I can run "git remote prune B" from time
to time to remove branches that no longer exists on B. However, if I do
"git push A ..." as you suggested then A will accumulate old garabage
from B very quickly.


Dmitry