On 20:05 Mon 26 Jan , Mike Auty wrote:
> Donnie Berkholz wrote:
> > Wouldn't it be great if Mike could simple merge his package into the
> > tree without losing all that history? This would make git-bisect
> > meaningful, instead of bringing in a huge collection of unrelated
> > changes in a single commit.
> I don't think "huge collection of unrelated changes in a single commit"
> fits for either 1 repo/tree or 1 repo/package. In either case I'd
> expect a single commit to be a single set of relevant changes, or have I
> not understood what you meant? In the 1 repo/tree, I'd only expect to
> see commits that spanned package directories if they were in some way
> relevant (changing all the license for something like gst-plugins-*)...
Many people develop eclasses in overlays. They might make 30 commits,
and then merge it all to the main tree in a single commit that says
something like "Merge from kde overlay." That makes tracking down bugs a
> > Just curious why you want to post it as a separate repo? If you come up
> > with a magic repacking command, just push your new commits and ask Robin
> > to run a repack.
> I wasn't intending to, it was just if people had specific requests. I'm
> also hoping to keep it more up to date (the one on exp/gentoo-x86.git
> doesn't seem to have had a history update in a few months).
> Unfortunately since I'm using cvsimport rather than cvs2svn, the log
> messages produced are likely to be different. Since they're a part of
> the commit, it won't be a case of simply commiting my changes, since all
> the hashes will be different. However, as I said, it's mostly a little
> local experiment, and I'd only post it if there were requests...
When it's an experiment, it's more important to test functionality than
to keep it up to date. We aren't making real commits to it.
Developer, Gentoo Linux