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 wrote:
> > > В Чтв, 24/06/2010 в 16:43 -0400, Olivier Crête пишет:
> > [...]
> > >> Or you could review the changes before pushing (since in git th
В Птн, 25/06/2010 в 14:19 +0530, Arun Raghavan пишет:
> On 25 June 2010 14:15, Peter Volkov 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
On 25 June 2010 14:15, Peter Volkov 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 ar
В Чтв, 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]
> > >
>
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
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 Ch
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
Nirbheek Chauhan wrote:
> On Tue, Apr 13, 2010 at 10:03 PM, Matti Bickel 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
On Tue, Apr 13, 2010 at 10:03 PM, Matti Bickel 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
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
В Втр, 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
Alec Warner wrote:
> On Tue, Apr 13, 2010 at 9:12 AM, 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
On Tue, Apr 13, 2010 at 9:12 AM, 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,
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 rea
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'
On Tue, Apr 13, 2010 at 6:49 PM, Ulrich Mueller 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 so
> 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
On Tue, Apr 13, 2010 at 4:55 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 i
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 Chang
В Втр, 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 so
On Wednesday 07 April 2010 21:41:49 Nirbheek Chauhan wrote:
> On Wed, Apr 7, 2010 at 10:24 PM, Markos Chandras
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
On Wed, Apr 7, 2010 at 10:24 PM, Markos Chandras 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
> re
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 $timefram
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
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 N
On Wed, 07 Apr 2010 11:58:13 +0200
Angelo Arrifano 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
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 C
On Tue, Apr 6, 2010 at 04:13, Nirbheek Chauhan 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,
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 ebui
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 con
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
On 06-04-2010 12:31:51 +0530, Nirbheek Chauhan wrote:
> On Tue, Apr 6, 2010 at 12:11 PM, 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
On Tue, Apr 6, 2010 at 12:11 PM, 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 man
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 info
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 m
35 matches
Mail list logo
