[gentoo-dev] [git migration] The problem of ChangeLog generation

[gentoo-dev] [git migration] The problem of ChangeLog generation

[Nirbheek Chauhan]

One of the few remaining problems to be solved for the migration to
git for our gentoo-x86/ and gentoo/ trees (besides other
projects/overlays) is the problem of how to handle ChangeLogs.

====
Gist:
====
* 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
* Proposed is to generate ChangeLogs from git commits on the rsync
server side when metadata generation is done
  - Scripts to do this already exist[1]


Now, there are obviously problems with this. Some of them are
documented below alongwith their proposed solutions. If people foresee
other problems with this; they are requested to comment. They are also
welcome to comment if they have a better solution to the problems
listed below.

Also, please try to keep this thread on-topic.


========
Problems:
========
* Messages in ChangeLog are not always the same as the commit messages
(~1% are different)
* Some people place additional information in the commit message which
is intended only for developer use
  - Most of the difference in ChangeLog/commit messages comes from this
* Trivial changes are often not documented in ChangeLogs
  - This is upto the developer's personal preference
  - Some folks do this because of the extra time it takes
    + This use-case becomes irrelevant due to automatic generation of ChangeLog

========
Solutions:
========
* Do not re-generate the existing ChangeLog; rather make the ChangeLog
generation script smart enough to only append
  - Solves the "messages not same" problem for existing commits
* Use a separator in the commit message like "== \n" to denote that
everything after this is dev-only information and should be skipped
from the user ChangeLog
  - Solves the problem for people who like to add extra dev-only info
in the CVS commit message
* Ignore commits with "[$tag][trivial]" in the tag[2] from being added
to ChangeLog
  - Keeps the wishes of the developer and does not pollute ChangeLog
with such info


1. http://live.gnome.org/Git/ChangeLog
2. http://live.gnome.org/Git/CommitMessages
-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Fabian Groffen]

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

In CVS we are not allowed to use branches, as a policy, that somehow
makes sense.  Our stable tree is visible via keywords instead.

Why would we suddenly do branches?  It still isn't a good thing.  If you
talk about branches in the sense of a clone of the entire repo, why
would we suddenly do massive concurrent development on the same ebuilds?

I can tell you from good experience that you only do such things if you
really have to, e.g. when you are in an overlay that needs to have
modifications to nearly everything and you try to keep that overlay
up-to-date with its origin, gentoo-x86.  It's no fun, because it
conflicts pretty much on lots of things, not ChangeLogs.

It seems to me, that if you are in a clone working on something, you
just only write the ChangeLog once you merge it with its origin,
gentoo-x86.  You have to review what happened at that stage anyway.

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.  Conclusion, if you can, try hard to keep your changes
minimal, and preferably zero compared to the origin, gentoo-x86.


-- 
Fabian Groffen
Gentoo on a different level

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Nirbheek Chauhan]

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

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Fabian Groffen]

On 06-04-2010 12:31:51 +0530, Nirbheek Chauhan wrote:
> 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?

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

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Angelo Arrifano]

First, I've been using git to hack Linux for some embedded devices. My
development was in sync with upstream linux-omap to which I sent several
patches. So, consider yourself that I have some experience with git.

On 06-04-2010 08:41, Fabian Groffen 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
> 
> In CVS we are not allowed to use branches, as a policy, that somehow
> makes sense.  Our stable tree is visible via keywords instead.
> 
> Why would we suddenly do branches?  It still isn't a good thing.  If you
> talk about branches in the sense of a clone of the entire repo, why
> would we suddenly do massive concurrent development on the same ebuilds?

IMHO repository branching would be greatly useful on Gentoo portage,
specially for third-party and other Gentoo-based distros. It will be a
lot easier for them to keep their own changes to ebuilds while in sync
with main Gentoo tree. This is a big win for everyone.

With my experience in Gentoo-embedded I can also present a problem where
branching is extremely useful:
1) Package foobar-1.2 is in the tree and keyworded only for ~x86 ~amd64.
2) Some dev at -embedded decides that package is useful and applies his
traditional cross-compile hackery.
3) The usual route would be to open a shi*load of bugs, wait a cr*pload
of time for the maintainer response and if the weather feels like it,
there is authorization to commit. Then there is also need to retest for
already keyworded arches so we know we don't break others.

3*) With git, one would just branch (lets call it embedded branch) the
package. Apply the patches there and let people using embedded profiles
to emerge from that branch instead of master.
Benefits? I think they are pretty obvious - people can start putting
quick patches in the tree for specific arches while not breaking others.

IMHO, the only bottleneck I see on Gentoo development is the massive
policy (not saying it is not needed) a -dev has to follow just to commit
a simple fix. Git my friends, will be our holly grail.
> 
> I can tell you from good experience that you only do such things if you
> really have to, e.g. when you are in an overlay that needs to have
> modifications to nearly everything and you try to keep that overlay
> up-to-date with its origin, gentoo-x86.  It's no fun, because it
> conflicts pretty much on lots of things, not ChangeLogs.
> 
> It seems to me, that if you are in a clone working on something, you
> just only write the ChangeLog once you merge it with its origin,
> gentoo-x86.  You have to review what happened at that stage anyway.
> 
> 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.  Conclusion, if you can, try hard to keep your changes
> minimal, and preferably zero compared to the origin, gentoo-x86.
> 
> 

I don't know why but people seem to have eternal scarring to merge
conflicts. Yes, they happen and yes they are trivial to fix if people
don't commit crap that touches a lot of stuff. In portage, the tree is
very well organized and with some good policies like restricting each
commit to one package will pretty much prevent conflicts.

I will not comment on if Changelogs are going to give conflicts or not.
That would be best answered by the people that is running portage git
for some time.

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Ciaran McCreesh]

[-- Attachment #1: Type: text/plain, Size: 1596 bytes --]

On Wed, 07 Apr 2010 11:58:13 +0200
Angelo Arrifano <miknix@gentoo.org> wrote:
> With my experience in Gentoo-embedded I can also present a problem
> where branching is extremely useful:
> 1) Package foobar-1.2 is in the tree and keyworded only for ~x86
> ~amd64. 2) Some dev at -embedded decides that package is useful and
> applies his traditional cross-compile hackery.
> 3) The usual route would be to open a shi*load of bugs, wait a
> cr*pload of time for the maintainer response and if the weather feels
> like it, there is authorization to commit. Then there is also need to
> retest for already keyworded arches so we know we don't break others.
> 
> 3*) With git, one would just branch (lets call it embedded branch) the
> package. Apply the patches there and let people using embedded
> profiles to emerge from that branch instead of master.
> Benefits? I think they are pretty obvious - people can start putting
> quick patches in the tree for specific arches while not breaking
> others.

And then you have to keep merging master into your embedded branch
every few hours to keep up. It's a waste of time. Instead, you should
just put a modified foobar-1.2 in your own repository and rely upon the
package manager's extensive and clean handling of multiple repositories
to avoid having to do any merging yourself.

There are uses for merges, but working around the shortcomings in a
package manager shouldn't be one of them. Migrating to Git should be
about addressing problems with CVS, not about addressing problems with
Portage.

-- 
Ciaran McCreesh

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Richard Freeman]

On 04/07/2010 05:58 AM, Angelo Arrifano wrote:
> 3*) With git, one would just branch (lets call it embedded branch) the
> package. Apply the patches there and let people using embedded profiles
> to emerge from that branch instead of master.
> Benefits? I think they are pretty obvious - people can start putting
> quick patches in the tree for specific arches while not breaking others.
>
> IMHO, the only bottleneck I see on Gentoo development is the massive
> policy (not saying it is not needed) a -dev has to follow just to commit
> a simple fix. Git my friends, will be our holly grail.

I think that allowing for different levels of QA standards, and 
accomodating things like this are good reasons to use branches. 
HOWEVER, we do need to manage this so that it doesn't get out of hand.

We really don't want users following 14 different branches and have 10 
different variations on every package in the tree - which is how it 
could get after a year or two of branching without any effort to do 
pruning and get things merged into a main tree.

Having branches to do development and facilitate access and testing 
seems fine, however we should always have the goal of getting these 
tested revisions merged back into the main tree.  We really don't want 
divergent development to be the norm.

[gentoo-dev] Re: [git migration] The problem of ChangeLog generation

[Christian Faulhammer]

[-- Attachment #1: Type: text/plain, Size: 813 bytes --]

Hi,

Richard Freeman <rich0@gentoo.org>:
> Having branches to do development and facilitate access and testing 
> seems fine, however we should always have the goal of getting these 
> tested revisions merged back into the main tree.  We really don't
> want divergent development to be the norm.

 Right, the extensive use of overlays shows a clear problem here.
Users could work on a branch of the normal tree to bring in their
changes, which gets merged by a normal developer at some point.  The
offical dev-lisp category is in bad shape (== not usable at all), while
the overlay is in great condition because of some dedicated users.

V-Li

-- 
Christian Faulhammer, Gentoo Lisp project
<URL:http://www.gentoo.org/proj/en/lisp/>, #gentoo-lisp on FreeNode

<URL:http://www.faulhammer.org/>

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [git migration] Proposition for tags supported by git hooks

[Maciej Mrozowski]

On Tuesday 06 of April 2010 04:13:02 Nirbheek Chauhan wrote:
> One of the few remaining problems to be solved for the migration to
> git for our gentoo-x86/ and gentoo/ trees (besides other
> projects/overlays) is the problem of how to handle ChangeLogs.

Great that you touched this topic.

> ========
> Problems:
> ========
> * Messages in ChangeLog are not always the same as the commit messages
> (~1% are different)
> * Some people place additional information in the commit message which
> is intended only for developer use
>   - Most of the difference in ChangeLog/commit messages comes from this
> * Trivial changes are often not documented in ChangeLogs
>   - This is upto the developer's personal preference
>   - Some folks do this because of the extra time it takes
>     + This use-case becomes irrelevant due to automatic generation of
> ChangeLog
> 
> ========
> Solutions:
> ========
> * Do not re-generate the existing ChangeLog; rather make the ChangeLog
> generation script smart enough to only append
>   - Solves the "messages not same" problem for existing commits

I don't think its' good idea, changelog should reflect state of remote 
repository, not the state of local clone. Besides storing Changelog is simply 
redundant and would increase repository size unnecessarily. It already 
increases rsync size considerably.

> * Use a separator in the commit message like "== \n" to denote that
> everything after this is dev-only information and should be skipped
> from the user ChangeLog
>   - Solves the problem for people who like to add extra dev-only info
> in the CVS commit message
> * Ignore commits with "[$tag][trivial]" in the tag[2] from being added
> to ChangeLog
>   - Keeps the wishes of the developer and does not pollute ChangeLog
> with such info

Both would work fine, maybe tag syntax could be improved - certainly we want 
it error prone and relatively simple to use - I've moved it to separate 
subthread.

Maybe something like this: (modeled a bit after KDE tags allowed in svn 
messages):
Each entry in its own line in commit message:

BUG: <bugnumber>
	Marks the bug as RESO/FIXED, as comment adding full git commit message
	with tags removed and just below gitweb URL corresponding to this
	particular commit. For bugzilla, instead of full gitweb URL, maybe make
	bugzilla aware of hashes in comments and expand gitweb links
	automatically

CCBUG: <bugnumber>
	Adds comment to the bugreport containing full git commit message with
	tags removed and just below gitweb URL corresponding to this particular
	commit. For bugzilla, instead of full gitweb URL, maybe make
	bugzilla aware of hashes in comments and expand gitweb links
	automatically

CCMAIL: <one-email-address>
	Sends email to given address containing full git commit message with
	tags removed and just below gitweb URL corresponding to this particular
	commit

SILENT:
	Marks entire commit message as "silent" by adding "(silent)" to the
	subject of the mail or adding some mail header to allow filtering out
	trivial commits. (like those containing typo fixes in comments and
	such). Such commits could also be skipped by ChangeLog generator.

I specifically don't like [tag][sth] format, because I'd suggest to impose 
some guidelines to git commit messages:
- put [$CATEGORY/$PN] in first line of commit message for git commits
  related to packages
- same with [$profile] for profiles or [package.mask] for p.mask, 
[eclass/$ECLASS] etc

to make history a bit more readable, see example:
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary

Also some number (for instance up to 80) of characters from first line could 
be used as email Subject in CCMAIL, so I think it's vital to have it organized 
a bit.

-- 
regards
MM

Re: [gentoo-dev] [git migration] Proposition for tags supported by git hooks

[Nirbheek Chauhan]

On Tue, Apr 6, 2010 at 12:58 PM, Maciej Mrozowski <reavertm@gmail.com> wrote:
>> ========
>> Solutions:
>> ========
>> * Do not re-generate the existing ChangeLog; rather make the ChangeLog
>> generation script smart enough to only append
>>   - Solves the "messages not same" problem for existing commits
>
> I don't think its' good idea, changelog should reflect state of remote
> repository, not the state of local clone. Besides storing Changelog is simply
> redundant and would increase repository size unnecessarily. It already
> increases rsync size considerably.
>

I think you've misunderstood this; ChangeLog appending would be done
entirely on the rsync server side. ChangeLog would be irrelevant for
the local clone. Also, the content of the old ChangeLog would anyway
already be in the history; so it doesn't take much space locally.

>> * Use a separator in the commit message like "== \n" to denote that
>> everything after this is dev-only information and should be skipped
>> from the user ChangeLog
>>   - Solves the problem for people who like to add extra dev-only info
>> in the CVS commit message
>> * Ignore commits with "[$tag][trivial]" in the tag[2] from being added
>> to ChangeLog
>>   - Keeps the wishes of the developer and does not pollute ChangeLog
>> with such info
>
> Both would work fine, maybe tag syntax could be improved - certainly we want
> it error prone and relatively simple to use - I've moved it to separate
> subthread.
>

If you see the link "[2]" which was
http://live.gnome.org/Git/CommitMessages you'll see that by that tag;
I meant the one inside the subject itself. Tags in the commit message
however are a good idea that I haven't thought about, and are used
extensively in other projects :)

> Maybe something like this: (modeled a bit after KDE tags allowed in svn
> messages):
> Each entry in its own line in commit message:
>
> BUG: <bugnumber>
>        Marks the bug as RESO/FIXED, as comment adding full git commit message
>        with tags removed and just below gitweb URL corresponding to this
>        particular commit. For bugzilla, instead of full gitweb URL, maybe make
>        bugzilla aware of hashes in comments and expand gitweb links
>        automatically
>
> CCBUG: <bugnumber>
>        Adds comment to the bugreport containing full git commit message with
>        tags removed and just below gitweb URL corresponding to this particular
>        commit. For bugzilla, instead of full gitweb URL, maybe make
>        bugzilla aware of hashes in comments and expand gitweb links
>        automatically
>
> CCMAIL: <one-email-address>
>        Sends email to given address containing full git commit message with
>        tags removed and just below gitweb URL corresponding to this particular
>        commit
>
> SILENT:
>        Marks entire commit message as "silent" by adding "(silent)" to the
>        subject of the mail or adding some mail header to allow filtering out
>        trivial commits. (like those containing typo fixes in comments and
>        such). Such commits could also be skipped by ChangeLog generator.
>
> I specifically don't like [tag][sth] format, because I'd suggest to impose
> some guidelines to git commit messages:
> - put [$CATEGORY/$PN] in first line of commit message for git commits
>  related to packages
> - same with [$profile] for profiles or [package.mask] for p.mask,
> [eclass/$ECLASS] etc
>

++, we do something similar in the gnome overlay, and this change is
*very* much required because commit messages in git are quite
different from CVS.

cat/pkg-ver: I changed foo because of bar
eclass/gnome2: Fix stupid USE=doc behaviour

What you're proposing is also covered in the same link:
http://live.gnome.org/Git/CommitMessages

On an offtopic note; I would love to see git bz[1] work with our
bugzilla once the migration is done ;)

1. http://blog.fishsoup.net/2009/09/05/git-bz-push/
-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Richard Freeman]

On 04/05/2010 10:13 PM, Nirbheek Chauhan wrote:
> * Proposed is to generate ChangeLogs from git commits on the rsync
> server side when metadata generation is done
>    - Scripts to do this already exist[1]

I haven't seen this discussed, so I'm going to toss this out there and duck:

Why not just get rid of the in-tree Changelogs entirely?  The scm logs 
already document this information, so why have it in a file?

It seems like the main purpose for it is for end-users to have some idea 
what changed in an ebuild.  However, in my experience the upstream 
changes are far more impactful than the ebuild changes, and those aren't 
in the Changelogs at all.

Instead, why not just create a script that gets distributed with portage 
that will upon request tell a user what changed based on the scm logs? 
I can't imagine that the hit on the servers will be all that large, and 
since this is read-only traffic it might be manageable through replication.

Rich

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Robin H. Johnson]

On Tue, Apr 06, 2010 at 09:06:24AM -0400, Richard Freeman wrote:
> Why not just get rid of the in-tree Changelogs entirely?  The scm
> logs already document this information, so why have it in a file?
The major concern with this is users that are NOT connected to the
internet always.
If you are connected, you can just use --exclude Changelog in your rsync
options.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Angelo Arrifano]

On 07-04-2010 00:21, Robin H. Johnson wrote:
> On Tue, Apr 06, 2010 at 09:06:24AM -0400, Richard Freeman wrote:
>> Why not just get rid of the in-tree Changelogs entirely?  The scm
>> logs already document this information, so why have it in a file?
> The major concern with this is users that are NOT connected to the
> internet always.
> If you are connected, you can just use --exclude Changelog in your rsync
> options.
> 

That's a good point. But can't we generate the ChangeLogs automatically
from git on the main rsync server?

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Hans de Graaff]

[-- Attachment #1: Type: text/plain, Size: 909 bytes --]

On Tue, 2010-04-06 at 09:06 -0400, Richard Freeman wrote:
> Why not just get rid of the in-tree Changelogs entirely?  The scm logs 
> already document this information, so why have it in a file?
> 
> It seems like the main purpose for it is for end-users to have some idea 
> what changed in an ebuild.  However, in my experience the upstream 
> changes are far more impactful than the ebuild changes, and those aren't 
> in the Changelogs at all.

I pretty much always use the -l option of portage to include the
pertinent changes in the ChangeLog, because this is the only way to know
about any changes before the package is merged. Yes, the NEWS from the
package usually contains a lot more detail, but I won't be able to read
it until after the fact. In my experience plenty of ChangeLogs in our
tree at least briefly document what changed in the package as opposed to
the ebuild.

Hans

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Dirkjan Ochtman]

On Tue, Apr 6, 2010 at 04:13, Nirbheek Chauhan <nirbheek@gentoo.org> wrote:
> * Use a separator in the commit message like "== \n" to denote that
> everything after this is dev-only information and should be skipped
> from the user ChangeLog

I think this is fairly elegant, and a good solution to this problem.

Cheers,

Dirkjan

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Markos Chandras]

On Tuesday 06 April 2010 05:13:02 Nirbheek Chauhan wrote:
Just a question:

Why do we even need to care about ChangeLog files? Can't we just use the git 
commit message to generate logs? E.g run a script on server side which will 
read the whole git shortlog and generate a changelog every $timeframe?

-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Nirbheek Chauhan]

On Wed, Apr 7, 2010 at 10:24 PM, Markos Chandras <hwoarang@gentoo.org> wrote:
> On Tuesday 06 April 2010 05:13:02 Nirbheek Chauhan wrote:
> Just a question:
>
> Why do we even need to care about ChangeLog files? Can't we just use the git
> commit message to generate logs? E.g run a script on server side which will
> read the whole git shortlog and generate a changelog every $timeframe?
>

You seem to have missed the gist of the situation. I'm quoting it here
again to highlight it:

* It makes zero sense to manually manage ChangeLogs in git[1]
[snip]
* Proposed is to generate ChangeLogs from git commits on the rsync
server side when metadata generation is done
 - Scripts to do this already exist[1]
[snip]

1. http://live.gnome.org/Git/ChangeLog
-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Markos Chandras]

On Wednesday 07 April 2010 21:41:49 Nirbheek Chauhan wrote:
> On Wed, Apr 7, 2010 at 10:24 PM, Markos Chandras <hwoarang@gentoo.org> 
wrote:
> > On Tuesday 06 April 2010 05:13:02 Nirbheek Chauhan wrote:
> > Just a question:
> > 
> > Why do we even need to care about ChangeLog files? Can't we just use the
> > git commit message to generate logs? E.g run a script on server side
> > which will read the whole git shortlog and generate a changelog every
> > $timeframe?
> 
> You seem to have missed the gist of the situation. I'm quoting it here
> again to highlight it:
> 
> * It makes zero sense to manually manage ChangeLogs in git[1]
> [snip]
> * Proposed is to generate ChangeLogs from git commits on the rsync
> server side when metadata generation is done
>  - Scripts to do this already exist[1]
> [snip]
> 
> 1. http://live.gnome.org/Git/ChangeLog
Ah you are right. It seems that I missed that e-mail on my inbox. Thanks for 
posting it again.
It seems we are on the same page :)
-- 
Markos Chandras (hwoarang)
Gentoo Linux Developer
Web: http://hwoarang.silverarrow.org

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Peter Volkov]

В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет:
> * It makes zero sense to manually manage ChangeLogs in git[1]

Once I had stupid cut&paste mistake and entered wrong credits in
ChangeLog. I don't see how to resolve this issue in case ChangeLog's
will be generated from git log and until somebody suggests how to edit
ChangeLogs generated from git I think have to keep ChangeLogs in
gentoo-x86.

-- 
Peter.

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Angelo Arrifano]

On 13-04-2010 13:25, Peter Volkov wrote:
> В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет:
>> * It makes zero sense to manually manage ChangeLogs in git[1]
> 
> Once I had stupid cut&paste mistake and entered wrong credits in
> ChangeLog. I don't see how to resolve this issue in case ChangeLog's
> will be generated from git log and until somebody suggests how to edit
> ChangeLogs generated from git I think have to keep ChangeLogs in
> gentoo-x86.
> 

If in kernel.org they don't seem to need to edit changelogs, why would
we? Between all of us developers, how many needed to change a ChangeLog
after commit? I guess we would be pretty low in number.

And lets not forget that we can --amend commits (log included) until we
push them to origin.

- Angelo

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Nirbheek Chauhan]

On Tue, Apr 13, 2010 at 4:55 PM, Peter Volkov <pva@gentoo.org> wrote:
> В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет:
>> * It makes zero sense to manually manage ChangeLogs in git[1]
>
> Once I had stupid cut&paste mistake and entered wrong credits in
> ChangeLog. I don't see how to resolve this issue in case ChangeLog's
> will be generated from git log and until somebody suggests how to edit
> ChangeLogs generated from git I think have to keep ChangeLogs in
> gentoo-x86.
>

I didn't know that editing existing ChangeLog entries manually was an
accepted practice with CVS. Even if it was to correct typos or
something else.

The traditional ChangeLog that is currently employed in gentoo-x86
(and in other projects) is simply an ugly hack to cheaply distribute
commit messages to users in an offline manner.

Think of it like this: if you make a typo in a commit message, or
forget to add something; you can't change it after you've published
the commit (cvs/svn commit or git push) to the world. Since ChangeLogs
are offline commit messages; you shouldn't edit them either; only
(app|pre)pend to them.

Also, with git, you usually review and double-check your commits and
amend/rebase before pushing, so such mistakes can be corrected then.
And now that we have the ability to cheaply generate ChangeLogs from
the commit messages, there is no reason to keep this ugly hack around.


-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Ulrich Mueller]

>>>>> On Tue, 13 Apr 2010, Nirbheek Chauhan wrote:

>> Once I had stupid cut&paste mistake and entered wrong credits in
>> ChangeLog. I don't see how to resolve this issue in case
>> ChangeLog's will be generated from git log and until somebody
>> suggests how to edit ChangeLogs generated from git I think have to
>> keep ChangeLogs in gentoo-x86.

> I didn't know that editing existing ChangeLog entries manually was
> an accepted practice with CVS. Even if it was to correct typos or
> something else.

So far, the ChangeLog is just a normal file. So why should it be
forbidden to edit it and correct mistakes? Examples are wrong or
forgotten credits, or wrong bug references. It is a service to our
users that such information is accurate.

> Also, with git, you usually review and double-check your commits and
> amend/rebase before pushing, so such mistakes can be corrected then.

This assumes that everybody is perfect. ;-) But mistakes will still
happen, even if you double-check.

Ulrich

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Nirbheek Chauhan]

On Tue, Apr 13, 2010 at 6:49 PM, Ulrich Mueller <ulm@gentoo.org> wrote:
>>>>>> On Tue, 13 Apr 2010, Nirbheek Chauhan wrote:
>
>>> Once I had stupid cut&paste mistake and entered wrong credits in
>>> ChangeLog. I don't see how to resolve this issue in case
>>> ChangeLog's will be generated from git log and until somebody
>>> suggests how to edit ChangeLogs generated from git I think have to
>>> keep ChangeLogs in gentoo-x86.
>
>> I didn't know that editing existing ChangeLog entries manually was
>> an accepted practice with CVS. Even if it was to correct typos or
>> something else.
>
> So far, the ChangeLog is just a normal file. So why should it be
> forbidden to edit it and correct mistakes? Examples are wrong or
> forgotten credits, or wrong bug references. It is a service to our
> users that such information is accurate.
>

So, such changes; where would you document them? Would you ChangeLog
an edit to the ChangeLog? CVS log is not an option for documenting
anything; access to it is slow, quirky, and time-consuming.

From my PoV, editing ChangeLog is like editing history. Complete no-no.

Of course, all of this goes out the window with git since access to
the log is trivially quick.

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Matti Bickel]

[-- Attachment #1: Type: text/plain, Size: 410 bytes --]

Nirbheek Chauhan wrote:
> From my PoV, editing ChangeLog is like editing history. Complete no-no.

It is possible in all major SCMs for a reason. And I (as a user) would
laugh at Changelog entries saying "um, I got that bug number wrong, it
is really #1234". If I (as a developer) log such edits, I'm wasting my
users time.

So I'll continue to edit and commit Changelogs without additional notice.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Angelo Arrifano]

On 13-04-2010 18:12, Matti Bickel wrote:
> Nirbheek Chauhan wrote:
>> From my PoV, editing ChangeLog is like editing history. Complete no-no.
> 
> It is possible in all major SCMs for a reason. And I (as a user) would
> laugh at Changelog entries saying "um, I got that bug number wrong, it
> is really #1234". If I (as a developer) log such edits, I'm wasting my
> users time.
> 
> So I'll continue to edit and commit Changelogs without additional notice.
> 
Can't we just create a commit hook that appends the bug summary as a
comment if a #XXXXX bug string is present on the commit log?

Something like:
- -
Foobar commit

Description bl a bla bla

# bug 1234: Show summary for those that don't double check the bug
# number.
#
# Other git crap that usually appears at end of log
# ...
- -

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Alec Warner]

On Tue, Apr 13, 2010 at 9:12 AM, Matti Bickel <mabi@gentoo.org> wrote:
> Nirbheek Chauhan wrote:
>> From my PoV, editing ChangeLog is like editing history. Complete no-no.
>
> It is possible in all major SCMs for a reason. And I (as a user) would
> laugh at Changelog entries saying "um, I got that bug number wrong, it
> is really #1234". If I (as a developer) log such edits, I'm wasting my
> users time.

Its not possible in perforce once your change has been submitted.

>
> So I'll continue to edit and commit Changelogs without additional notice.
>
>

I agree that you should do this (it is rather convenient for everyone
after all) but I don't think editable changelog entries are really a
blocker for this migration.  It seems you can append to changelogs in
git which is likely sufficient for fixing mistakes that will occur.

-A

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Matti Bickel]

[-- Attachment #1: Type: text/plain, Size: 868 bytes --]

Alec Warner wrote:
> On Tue, Apr 13, 2010 at 9:12 AM, Matti Bickel <mabi@gentoo.org> wrote:
>> Nirbheek Chauhan wrote:
>>> From my PoV, editing ChangeLog is like editing history. Complete no-no.
>> It is possible in all major SCMs for a reason. And I (as a user) would
>> laugh at Changelog entries saying "um, I got that bug number wrong, it
>> is really #1234". If I (as a developer) log such edits, I'm wasting my
>> users time.
> 
> Its not possible in perforce once your change has been submitted.

Oh, missed that one. Maybe that makes perforce more "auditble" or whatnot.

I rather like the changelogs auto-generated. A method to link my git
commit to bugzie would be awesome. I *do* envy debian and others for the
auto bughandling they have. Previewing more than a raw number would also
reduce (not eliminate) the errors committed, i guess.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Richard Freeman]

On 04/13/2010 12:33 PM, Matti Bickel wrote:
> Alec Warner wrote:
>> Its not possible in perforce once your change has been submitted.
>
> Oh, missed that one. Maybe that makes perforce more "auditble" or whatnot.

I suspect that is the gist of it.  I work with numerous systems that 
have audit trails that are subject to regulation, and it is pretty 
typical that the way to "correct" an audit trail entry is to add an 
additional audit trail entry (with the old entry still being there - 
perhaps with a pointer to the new entry).  There is no shame in 
admitting that you made a mistake - the kinds of people who audit these 
systems look at a lack of mistakes as evidence that something is being 
hidden.

Rich

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Nirbheek Chauhan]

On Tue, Apr 13, 2010 at 10:03 PM, Matti Bickel <mabi@gentoo.org> wrote:
> I rather like the changelogs auto-generated. A method to link my git
> commit to bugzie would be awesome. I *do* envy debian and others for the
> auto bughandling they have. Previewing more than a raw number would also
> reduce (not eliminate) the errors committed, i guess.
>

I think you will *really* like `git bz`[1][2][3]. It's exactly what
you need (needs porting to pybugz and our workflow however).

1. http://blog.fishsoup.net/2009/09/05/git-bz-push/
2. http://git.fishsoup.net/cgit/git-bz/plain/git-bz
3. http://git.fishsoup.net/man/git-bz.html

-- 
~Nirbheek Chauhan

Gentoo GNOME+Mozilla Team

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Matti Bickel]

[-- Attachment #1: Type: text/plain, Size: 670 bytes --]

Nirbheek Chauhan wrote:
> On Tue, Apr 13, 2010 at 10:03 PM, Matti Bickel <mabi@gentoo.org> wrote:
>> I rather like the changelogs auto-generated. A method to link my git
>> commit to bugzie would be awesome. I *do* envy debian and others for the
>> auto bughandling they have. Previewing more than a raw number would also
>> reduce (not eliminate) the errors committed, i guess.
>>
> 
> I think you will *really* like `git bz`[1][2][3].

Actually, I do :)
Someone posted a link in a thread I can't remember now and it looks very
promising. Though i don't know if there's anything barring us from using
it. But I image it would make my life easier a lot.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Peter Volkov]

В Втр, 13/04/2010 в 17:18 +0530, Nirbheek Chauhan пишет:
> The traditional ChangeLog that is currently employed in gentoo-x86
> (and in other projects) is simply an ugly hack 

The difference between gentoo-x86 ebuild ChangeLogs and ChangeLogs used
in other projects is that gentoo-x86 ChangeLog is more like NEWS file
that summarizes important (affecting package) changes. That is why
emerge -l was implemented. And that is why it's better to avoid typos
there (fix them), drop redundant messages like comment edits, empty
lines removal and etc...

> Think of it like this: if you make a typo in a commit message, or
> forget to add something; you can't change it after you've published
> the commit (cvs/svn commit or git push) to the world.

And then it's better to keep ChangeLogs. For developers it was never a
problem to script `echangelog "log" && repoman commit -m "log"` and
conflict resolution is really not that hard with git. In spirit of
Gentoo, it's better to write some tool to update Manifests after
conflict resolution instead of making ChangeLogs less useful for those
who uses them.


BTW as for profiles ChangeLogs... May be it's better to generate them.

-- 
Peter.

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Jim Ramsay]

[-- Attachment #1: Type: text/plain, Size: 2598 bytes --]

Peter Volkov wrote:
> ?? ??????, 13/04/2010 ?? 17:18 +0530, Nirbheek Chauhan ??????????:
> > The traditional ChangeLog that is currently employed in gentoo-x86
> > (and in other projects) is simply an ugly hack 
> 
> The difference between gentoo-x86 ebuild ChangeLogs and ChangeLogs used
> in other projects is

I think another very important distinction (that you imply below,
but I want to specifically point out here) is that we have *many*
per-project ChangeLogs whereas most other projects have a
*single* monolithic ChangeLog.

> > Think of it like this: if you make a typo in a commit message, or
> > forget to add something; you can't change it after you've published
> > the commit (cvs/svn commit or git push) to the world.
> 
> And then it's better to keep ChangeLogs. For developers it was never a
> problem to script `echangelog "log" && repoman commit -m "log"` and
> conflict resolution is really not that hard with git. In spirit of
> Gentoo, it's better to write some tool to update Manifests after
> conflict resolution instead of making ChangeLogs less useful for those
> who uses them.

This is a very good point regarding ease of conflict resolution.

Further to my other point above, the traditional ChangeLog
ugliness really only hits you with a centralized setup+git if
*everyone* is editing the *same* ChangeLog: If every commit
touches the same file in the same place (ie, prepending to a
ChangeLog file in the same location), you are guaranteed to have
collisions every time you pull a new version of the file.  This
is why most projects with a single monolithic changelog
auto-generate them, or perhaps just craft them at release time.

Our case, though it is a centralized repository model, is quite
different.  The chance of collisions in a package-specific
ChangeLog is, as it is today with CVS, pretty unlikely.  In fact,
I think the only time it usually happens to me is when an arch
stabilizes my package while I'm making a change, and these are
very easy to fix.

(In fact, it may be possible to help git out with this specific
ChangeLog situation by using a "custom merge driver", see
GITATTRIBUTES(5) for details, though deployment of a custom merge
driver can be tricky)

> BTW as for profiles ChangeLogs... May be it's better to generate them.

That's another important distinction and probably a good idea.  I
think those profile ChangeLogs are also not as user-facing as the
per-package ones, so an autogenerated one makes a lot of sense.

-- 
Jim Ramsay
Gentoo/Linux Developer (rox/fluxbox/gkrellm)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Luca Barbato]

On 04/13/2010 01:25 PM, Peter Volkov wrote:
> В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет:
>> * It makes zero sense to manually manage ChangeLogs in git[1]
> 
> Once I had stupid cut&paste mistake and entered wrong credits in
> ChangeLog. I don't see how to resolve this issue in case ChangeLog's
> will be generated from git log and until somebody suggests how to edit
> ChangeLogs generated from git I think have to keep ChangeLogs in
> gentoo-x86.
> 

We could abuse git-note

-- 

Luca Barbato
Gentoo/linux
http://dev.gentoo.org/~lu_zero

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 800 bytes --]

On Thu, 2010-06-24 at 20:59 +0200, Luca Barbato wrote:
> On 04/13/2010 01:25 PM, Peter Volkov wrote:
> > В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет:
> >> * It makes zero sense to manually manage ChangeLogs in git[1]
> > 
> > Once I had stupid cut&paste mistake and entered wrong credits in
> > ChangeLog. I don't see how to resolve this issue in case ChangeLog's
> > will be generated from git log and until somebody suggests how to edit
> > ChangeLogs generated from git I think have to keep ChangeLogs in
> > gentoo-x86.
> > 
> 
> We could abuse git-note

Or you could review the changes before pushing (since in git these
operations are separate). And live with the consequences of your
mistakes!

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Peter Volkov]

В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет:
> On Thu, 2010-06-24 at 20:59 +0200, Luca Barbato wrote:
> > On 04/13/2010 01:25 PM, Peter Volkov wrote:
> > > В Втр, 06/04/2010 в 07:43 +0530, Nirbheek Chauhan пишет:
> > >> * It makes zero sense to manually manage ChangeLogs in git[1]
> > > 
> > > Once I had stupid cut&paste mistake and entered wrong credits in
> > > ChangeLog. I don't see how to resolve this issue in case ChangeLog's
> > > will be generated from git log and until somebody suggests how to edit
> > > ChangeLogs generated from git I think have to keep ChangeLogs in
> > > gentoo-x86.
> > 
> > We could abuse git-note

May be. I found this mail: http://lists.zerezo.com/git/msg623699.html
Was the problem resolved?

> Or you could review the changes before pushing (since in git these
> operations are separate). And live with the consequences of your
> mistakes!

No. We are humans and thus mistakes are unavoidable.

-- 
Peter.

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Arun Raghavan]

On 25 June 2010 14:15, Peter Volkov <pva@gentoo.org> wrote:
> В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет:
[...]
>> Or you could review the changes before pushing (since in git these
>> operations are separate). And live with the consequences of your
>> mistakes!
>
> No. We are humans and thus mistakes are unavoidable.

He didn't say don't make mistakes. He said, be careful and if mistakes
happen, so be it.
-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Peter Volkov]

В Птн, 25/06/2010 в 14:19 +0530, Arun Raghavan пишет:
> On 25 June 2010 14:15, Peter Volkov <pva@gentoo.org> wrote:
> > В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет:
> [...]
> >> Or you could review the changes before pushing (since in git these
> >> operations are separate). And live with the consequences of your
> >> mistakes!
> >
> > No. We are humans and thus mistakes are unavoidable.
> 
> He didn't say don't make mistakes. He said, be careful and if mistakes
> happen, so be it.

And I disagreed. This is unacceptable since we are talking about credits
to our users. It's like paying salary to random person and blaming tools
after that.

-- 
Peter.

Re: [gentoo-dev] [git migration] The problem of ChangeLog generation

[Olivier Crête]

[-- Attachment #1: Type: text/plain, Size: 974 bytes --]

On Fri, 2010-06-25 at 13:00 +0400, Peter Volkov wrote:
> В Птн, 25/06/2010 в 14:19 +0530, Arun Raghavan пишет:
> > On 25 June 2010 14:15, Peter Volkov <pva@gentoo.org> wrote:
> > > В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет:
> > [...]
> > >> Or you could review the changes before pushing (since in git these
> > >> operations are separate). And live with the consequences of your
> > >> mistakes!
> > >
> > > No. We are humans and thus mistakes are unavoidable.
> > 
> > He didn't say don't make mistakes. He said, be careful and if mistakes
> > happen, so be it.
> 
> And I disagreed. This is unacceptable since we are talking about credits
> to our users. It's like paying salary to random person and blaming tools
> after that.

You can just make a new commit with just a message saying "Hey, last
time I was wrong, this is from A, not B" if you care enough.

-- 
Olivier Crête
tester@gentoo.org
Gentoo Developer

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]