So I have a simple git-find working, and now I want to use it to rip out some patches I am interested in. The repository I am working on has a lot of uninteresting deltas in it that I don’t care about. I am actually only interesting in backporting an interface change in one file from the klipsng branch:

    $ git-find klipsng --file linux/net/ipsec/ipsec_sa.c
    ...

This works as advertised, I get a list of revisions that altered that file. The current git command line parsing does not allow me to do much with this however.

So I am giving myself some time to write a git-find script that I can use to feed commits to another tool, like git-graft (or git-cherry-pick).

I don’t really know what I am doing yet, so I want to survey what is available in git-* tools and reuse as much of the available features.

I want to be able to take a bunch of patches that were applied to one semi-related branch and appened them to the current branch, or better yet a new branch of the current. The bunch of patches will be selected by what they change; I should be able to graft all patches that modify some file, or modify some regular expression.

Here is what I mean:

 ,-----X---X---X---X--- ... ---             "historical" branch
o
 `--------------------Y                     "current" branch
                       \
                        `---Z---Z---...     "working" branch

You start off at current branch and run something like:

git-find historical --file some_file.c --or --re 'some pattern' \
| git-graft --new-branch working -

This will let me take the interesting subset of X commits and apply them at some point Y. Should the patches X cause conflicts with the current branch, then git-graft needs to let the user resolve those conflicts a patch at a time. The default is to apply onto the current branch, however if desired it should be possible to create the changes on a new, working, branch. The result is a new set of Z commits, as shown above.

I accidentally committed a changeset without a description and wanted to fix it. As I was pushing enter I realized that I didn’t want to commit yet. I have not pushed anywhere – an important requirement for this kind of revert.

I basically want to do a bk fix -c (if I recall my bk correctly).

Since git revert pollutes the history, it is not the right thing to do here since the bad changeset was not pushed. But it would be the right thing to do had I pushed my change.

After working almost exclusively with git for a few months, I had to do some work on a freebsd kernel. The freebsd kernel is maintained in mercurial. I noticed right away a few features that I have started to take for granted with git.

I’ve been working for Xelerance, mcr’s company, for a couple of weeks now. The project I am working on is mostly bringing KLIPS, openswan ipsec kernel module, into the 21st centry. Since KLIPS is a patch against the Linux kernel, it makes sense to keep it in git.