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
signature.asc
Description: This is a digitally signed message part.
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
