On Wed, Mar 14, 2012 at 8:46 AM, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Dmitry Potapov <dpotapov@xxxxxxxxx> writes: > >>> 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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html