Am Dienstag, 15. März 2011, 10:05:17 schrieb Dieter Plaetinck: > On Mon, 14 Mar 2011 15:53:44 -0500 > "Chanoch (Ken) Bloom" <kbl...@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
Description: This is a digitally signed message part.
_______________________________________________ vcs-home mailing list firstname.lastname@example.org http://lists.madduck.net/listinfo/vcs-home