On 16/10/07, Brandon Allbery wrote:
On Fri, Oct 7, 2016 at 12:43 PM, Chris Jones <jon...@hep.phy.cam.ac.uk>
wrote:
On 07/10/16 17:39, Craig Treleaven wrote:
On Oct 7, 2016, at 12:16 PM, Sterling Smith <smit...@fusion.gat.com>
wrote:
On Oct 7, 2016, at 7:20AM, Chris Jones <jon...@hep.phy.cam.ac.uk> wrote:
My point still stands though, you have to actively try the things you
need to do, to get used to them.
+1
Yabut, then you hear things like “use —force when you need”, except then
you hear “—force can really screw things
up”. I’m a little gunshy of that screw-things-up part!
Indeed, I was a little dubious of the suggestions that involve -force. I
suspect there are better ways of working that should avoid the need for
that.
--force only comes into it when you are rewriting history (i.e. merging
existing commits that were already sent upstream). Best is to not do this;
work in a branch, combine commits after, and cherrypick those to *another*
clean branch (or diff the first branch to get all changes as one patch, and
apply it in the new branch to get a single commit). Or just accept multiple
commits instead of trying to pretend to be a neat freak after hosting a
wild party.
'push --force' should *never* be used when working in a team except for
dire emergencies like having cleaned the history of accidentally
committed login credentials or the like. It completely rewrites the
remote history of the repository, invalidating all local clones
immediately and leaving a mess for all collaborators. Git is designed to
work with branches whenever possible and 'merge' or 'merge --squash'
them when you're finished.
_______________________________________________
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
