Python script for automatic synchronization based on inotify

[Dieter Plaetinck]

On Mon, 14 Mar 2011 15:53:44 -0500
"Chanoch (Ken) Bloom" <kbloom at gmail.com> wrote:

> On Mon, Mar 14, 2011 at 08:53:03PM +0100, Rene Mayrhofer wrote:
> > On 14.03.2011 17:15, Dieter Plaetinck wrote:
> > >why are many code changes committed as "autocommit"? why do you
> > >commit .pyc files?
> > .pyc removed from history with --force push to gitorious done.
> > However, my git-fu is not yet good enough to properly change the
> > past commit messages and merge them for a cleaner history. If you'd
> > like to have a go at, I would welcome a clean history and could
> > (probably as the owner of the project) do another force push to get
> > it on gitorious.
> 
> I just took a look at your repository, and here's how to fix it.
> 
> First, run `git filter-branch` with the `--prune-empty` option to get
> rid of the empty commits that used to contain only changes to the .pyc
> file.
> 
> Second, rewriting the history to be sane should be a simple (though
> potentially time consuming) application of `git rebase --interactive`.
> Look over the tree using gitk to see which commits can be grouped into
> logically related sets of changes, then find the number of the first
> commit on the repository (or the first commit where the history starts
> to get really hairy) and start rebasing from there. Make liberal use
> of the `squash` operation to merge commits that should be related but
> were broken up by the way autocommit works. Write a useful commit
> message for each of the new commits you're creating.
> 
> When you're done, look over the tree again with gitk. You can run `git
> rebase --interactive` again (on the rebased tree) if you spot errors.
> 
> --Ken
> 

+1 on that.
Also be aware that the suggestion of somebody else rewriting the
entire history and contributing that is quite awkward: which author
should those new commits have? you (Rene) did all the work originally so
it should probably stay you, OTOH the contributor would be responsible
for the changes to the commits he did (especially when he messed
something up during the cleaning process), and currently git supports
only 1 author per commit.

for more info on rewriting history:
* how: any tutorial on git rebase --interactive, i.e. http://progit.org/book/ch6-4.html
* why: http://dieter.plaetinck.be/why-rewriting-git-history-and-why-commits-imperative-present-tense.html
(shameless self-plug)

Dieter