Re: pull/merge --no-commit

kurt_p_lloyd [off-list ref] writes:

Maybe there is a different workflow to effectively achieve what
I want via steps 1, 2, and 3 (way above).  In other words, OK I do
a 'pull', and all 3 steps occur together.  Then suppose that I
contemplate the changes that got committed, and that I disapprove
of either a majority or all of those changes.  I'd like to be able
to cleanly and easily recover from this with no related commits and
"revert commits" in git log.

Let's say you did this:

 $ git pull $other_party

A "pull" is a "fetch" (download their history and objects)
followed by a "merge" (integrate that history with your
history).  When it goes without merge conflicts you need to
resolve by hand, the above will move your HEAD to reflect the
new histroy of your project, including the fact that you merged
with the $other_party, at this point.  The above command gives
you the overview of the change in the form of diffstat.

You would naturally want to inspect and convince yourself that
you did not pull crap from the $other_party.  A special symbol
ORIG_HEAD is set up after a "merge" (be it a "fast forward" or a
true merge) that lets you easily access where the tip of your
branch was before the merge.

To view the damage the $other_party inflicted on you as a whole:

 $ git diff ORIG_HEAD..

Or to inspect individual patches:

 $ git log -p ORIG_HEAD..

Some people seem to prefer "git log --reverse -p ORIG_HEAD..",
which would give their changes in chronological order.

If it turns out that you pulled crap from the $other_party, you
can get rid of that away from the history of your branch with:

 $ git reset --hard ORIG_HEAD

I'll add my own deliberate commits if
and when I decide that I really /would/ like some or all of those
changes eventually, in which case I would still like the proper
context to exist in the "database" for me to bring the selective
remote changes into my local branch in a natural way.

In git managed projects that care about the readability of
global history, this often is done by asking $other_party to
redo the branch, discarding broken/undesirable bits.

But if you do not have the clout to do so over the $other_party,
then you could, after the above sequence, cherry pick good bits
from what the $other_party has and you don't.  This however will
make your history and their history to have different commits
that record the result of the same patch application; if you
later pull from the $other_party again, you will end up having
two copies of the (logically) same commit in your history.