Python script for automatic synchronization based on inotify

[René Mayrhofer]

Am Dienstag, 15. März 2011, 10:05:17 schrieb 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.

Done and pushed --force to gitorious. Whoever cloned the repo, please discard the local history and clone afresh. This was painful and took me about 4h to go through. I therefore hope it was worth it and that I will receive many patches ;-)

> 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.

Now that I am more familiar with rebase --interactive, I agree.

best regards,
Rene
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.madduck.net/pipermail/vcs-home/attachments/20110319/baf53e5f/attachment.pgp>