On 06-04-2010 12:31:51 +0530, Nirbheek Chauhan wrote: > On Tue, Apr 6, 2010 at 12:11 PM, Fabian Groffen <grob...@gentoo.org> wrote: > > On 06-04-2010 07:43:02 +0530, Nirbheek Chauhan wrote: > >> * It makes zero sense to manually manage ChangeLogs in git[1] > >> - Irritating conflicts while merging branches or remote master > >> + Similar argument for having only distfile manifests; but I digress... > >> - Duplication of effort and information > >> - Saves space for local checkouts > > > > This seems to assume > > a) that we will do branches, and > > b) that those branches somehow are official and in use > > > > No. Conflicts can arise (and I have seen them arise) trivially if you > make changes and try to do a pull --rebase; which is then not > fast-forward, and you're left with an ugly mess of conflicts on your > hands. Say you're moving stuff from an overlay using git format-patch; > how do you handle the conflicts it will generate to ChangeLogs and > Manifests?
Ehm, you consider pkg-moving packages an operation you do from day to day? I surely hope not. The other changes you talk about sound like a generic problem to me, not related to ChangeLog files at all. > Also, this is not the only reason to not use ChangeLogs. > > Trivial example purely for demonstrative purposes: > > Without ChangeLog: > make change1; commit; test; realise it needs change2; commit; test; > rebase commits; push > With ChangeLog: > make change1; write ChangeLog; commit; test; realise it needs change2; > reset --hard ChangeLog HEAD^; rewrite ChangeLog; commit; test; rebase > commits; push If you just pull/update before you start your changes and commit/push afterwards there are no problems. I see no branching in your examples. In a branch, I wouldn't make ChangeLog changes until I merge with main and commit there. > Now which is easier? Don't forget that the major reason for moving to > git was the ability to make several local commits and pushing them in > an atomic way; so you are bound to make mistakes and want to rebase. Ohw, was that the major reason... What a nonsense. If you need to push several commits to the same package at the same time, you could have probably done it with a single commit on CVS as well, just using a single ChangeLog entry, which looks much cleaner to me. If you talk about bumping the whole of KDE at the same time, well nice, but then how are you going to solve the problem with the Manifest file? I'd say one of the requirements of a new VCS is the ability to do an atomic commit over multiple directories, which is quite different from making several local commits, to me. > > If you really have lots of changes, you will find that many commits on > > the other side will cause you conflicts, so the ChangeLog is just a very > > small part of it. > > I bump an ebuild; arch team member marks older version stable. Two > completely orthogonal changes that conflict now. With ChangeLogs, > *every* *single* change you make conflicts. You do a rebase; and it > conflicts! It's just stupid. WHY would you wait a couple of months with pushing your new version out? The conflict chance you get if you'd push immediately, is as big as the conflict chance you get with CVS if this happens. Your argument is more to get rid of the ChangeLog and Manifest file, then to start using git, IMO. > > Conclusion, if you can, try hard to keep your changes > > minimal, and preferably zero compared to the origin, gentoo-x86. > > With the inevitable increased activity on the gentoo-x86 tree, this > will become more and more difficult. Do Tove's stats actually show there is an increase in activity? One would have to plot it, but glancing over it, it actually looks about steady to me. Git doesn't solve the problem, you still have a couple of untackled issues standing out. I think Robin tried to address them in previous mails. -- Fabian Groffen Gentoo on a different level
