On Mon, Nov 3, 2014 at 8:29 AM, Dave Goodell (dgoodell) <dgood...@cisco.com>
wrote:
> > btw, is there a push option to abort if that would make github history
> non linear ?
>
> No, not really. There are some options to "pull" to prevent you from
> creating a merge commit, but the fix when you encounter that situation
> would simply be to rebase in some fashion, so you might as well just do
> that every time.
>
The "some options" Dave is referring to is probably
git pull --ff-only
I have this aliased to "git ff" and use it instead of "git pull".
If your pull would require a merge, this will tell you so and not make any
changes.
As Dave says, "git pull --rebase" is *probably* going to be your next step
if "git pull --ff-only" fails. However, that is not *always* the case.
Sometimes you may wish to "stash" or create a new branch for the local
modifications.
I prefer "git pull --ff-only" because it allows (some may say "forces") me
to examine the situation before I create non-linear history. Without it,
imagine what happens when I login to some machine I seldom use, and there
are local mods from some experiment I had totally forgotten about.
- If I do a plain "git pull" I get a merge I probably didn't want
- If I do "git pull --rebase" then my local mods are (silently unless you
look carefully) rebased on the new tip.
In either of the above cases I may find myself resolving conflicts for
changes I didn't even remember making.
So, I favor "git pull --ff-only" because in the case of no local mods it
just updates my local repo, and otherwise I get to examine the local
changes before I let git merge or rebase them. If you are familiar enough
with using "stash", you can even choose to ignore the local changes for now
and get on with the task at hand.
-Paul
--
Paul H. Hargrove phhargr...@lbl.gov
Future Technologies Group
Computer and Data Sciences Department Tel: +1-510-495-2352
Lawrence Berkeley National Laboratory Fax: +1-510-486-6900
