krb5-1.12 beta2 - New Feature - iprop notify

[Nico Williams]

On Mon, Dec 9, 2013 at 9:23 PM, Richard Basch <basch at alum.mit.edu> wrote:
> Unfortunately, the GIT commits are more complicated than needed be since
> c5c0a1d reverses part of 69b9221 (I reverted the timer-based trigger and
> implemented an event-based trigger for the downstream slaves once I realized
> I could use the NULLPROC method as a trigger).

This is why git rebase and git add -p/-e are such a wonderful
things...  I'm not saying that re-writing history is easy or fun, but
that it sure is helpful.

What I usually do is I create a new branch same as the old then rebase
-i one of them, then publish both so that upstream can see the
differences between the two branches (if any, besides the history),
and still we get clean history (plus I get my old history as a backup
in case I screw up a rebase, and it's useful for, e.g., showing how I
went from A to B).

I don't know how familiar you are with git rebase -i and git add -p/e,
so I'll write you a crash-course assuming you're not at all familiar
with them.

(There's plenty of videos and wiki and stackoverflow pages on all of
this, but hopefully I can a good enough job to get you started.)

Running

    git rebase -i origin/master

will enter interactive rebase mode.  In this mode git first runs
$EDITOR with a recipe consisting of all the commits between the merge
base with origin/master and HEAD, then when you exit $EDITOR git
applies the recipe.

You get to edit this recipe as follows:

 - any commits you don't want, just delete the corresponding "pick" entries

 - any commits you want to re-order, just move the corresponding
"pick" entries about so they come in the desired order

 - any two or more consecutive commits you want to merge into one,
just change the "pick" verb of all but the first to "squash" (merges
the commit messages too) or "fixup" (discards the commit message of
the fixup commits)

 - any commit whose message you want to reword, s/pick/reword/

 - any commit you want to split or edit, s/pick/edit/ -- this last is
very special, more on that below.

FYI, "pick" refers to git cherry-pick.  A recipe of nothing but picks
is akin to manually executing git cherry-pick for each of those
commits, in the order that they appear in the recipe.

Exit without saving to abort -- it's safe.

Save and exit to start the rebase.  Git will apply the recipe, one
action at a time, picking commits and doing whatever additional action
(like squashing commits).

If at any point there's a merge conflict git status will show them and
exit.  You then get your shell back and you must edit the affected
files to clear up the conflicts.  When you've cleared up the conflicts
you must git add those files before continuing.  When conflicts are
resolved you then run git rebase --continue.

If at any point you need to start over just git rebase --abort.  It
will undo everything and leave your branch as it was.  If you finish a
git rebase and are unhappy with the result you can file the old HEAD
for your branch in the git reflog (or in any backup branches you
made).

As for commits you want to split or change, you get your shell back
right after picking the commit in question.  To split a commit to a
file, just git reset HEAD^ that file, edit it, then git add -p, git
commit, then git add and git rebase --continue.  To add a new commit
you 'edit' the commit you want to add after, edit files, git add them,
then git commit, then git rebase --continue.

As for git add -p/-e, that lets git add only portions of extant
changes in the workspace, and you even get to edit the diffs to add to
the index.

It's hard to overstate just how powerful a feature this is.  And how
wonderful.  This is _teh_ killer feature of git.

Nico
--