kurt_p_lloyd <kplloyd@xxxxxxxxxxxxxxxxxx> 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. - 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
