public inbox for gentoo-dev@lists.gentoo.org
 help / color / mirror / Atom feed
From: Nirbheek Chauhan <nirbheek@gentoo.org>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [git migration] The problem of ChangeLog generation
Date: Tue, 6 Apr 2010 12:31:51 +0530	[thread overview]
Message-ID: <u2y8b4c83ad1004060001g630ce37ag6a1853cdd64ae33a@mail.gmail.com> (raw)
In-Reply-To: <20100406064118.GW817@gentoo.org>

On Tue, Apr 6, 2010 at 12:11 PM, Fabian Groffen <grobian@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?

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

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.

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

Extreme example: profiles/ChangeLog

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

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team



  reply	other threads:[~2010-04-06  7:02 UTC|newest]

Thread overview: 38+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-06  2:13 [gentoo-dev] [git migration] The problem of ChangeLog generation Nirbheek Chauhan
2010-04-06  6:41 ` Fabian Groffen
2010-04-06  7:01   ` Nirbheek Chauhan [this message]
2010-04-06 11:40     ` Fabian Groffen
2010-04-07  9:58   ` Angelo Arrifano
2010-04-07 10:03     ` Ciaran McCreesh
2010-04-07 14:36     ` Richard Freeman
2010-06-21 19:34       ` [gentoo-dev] " Christian Faulhammer
2010-04-06  7:28 ` [gentoo-dev] [git migration] Proposition for tags supported by git hooks Maciej Mrozowski
2010-04-06  8:00   ` Nirbheek Chauhan
2010-04-06 13:06 ` [gentoo-dev] [git migration] The problem of ChangeLog generation Richard Freeman
2010-04-06 22:21   ` Robin H. Johnson
2010-04-07 10:05     ` Angelo Arrifano
2010-04-07  6:25   ` Hans de Graaff
2010-04-07  7:55 ` Dirkjan Ochtman
2010-04-07 16:54 ` Markos Chandras
2010-04-07 18:41   ` Nirbheek Chauhan
2010-04-07 21:54     ` Markos Chandras
2010-04-13 11:25 ` Peter Volkov
2010-04-13 11:44   ` Angelo Arrifano
2010-04-13 11:48   ` Nirbheek Chauhan
2010-04-13 13:19     ` Ulrich Mueller
2010-04-13 13:35       ` Nirbheek Chauhan
2010-04-13 16:12         ` Matti Bickel
2010-04-13 16:22           ` Angelo Arrifano
2010-04-13 16:23           ` Alec Warner
2010-04-13 16:33             ` Matti Bickel
2010-04-14  1:47               ` Richard Freeman
2010-04-14  6:39               ` Nirbheek Chauhan
2010-04-14  9:08                 ` Matti Bickel
2010-04-13 16:47     ` Peter Volkov
2010-05-02 15:13       ` Jim Ramsay
2010-06-24 18:59   ` Luca Barbato
2010-06-24 20:43     ` Olivier Crête
2010-06-25  8:45       ` Peter Volkov
2010-06-25  8:49         ` Arun Raghavan
2010-06-25  9:00           ` Peter Volkov
2010-06-26  5:55             ` Olivier Crête

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=u2y8b4c83ad1004060001g630ce37ag6a1853cdd64ae33a@mail.gmail.com \
    --to=nirbheek@gentoo.org \
    --cc=gentoo-dev@lists.gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox