On Sun, Aug 16, 2015 at 2:12 PM, Robin H. Johnson wrote:
>
> Ebuild:
> - User copies .ebuild with expanded $Id$ to /usr/local/portage/...
> - User modifies local ebuild copy
> - User submits changed ebuild to bugzilla
> - Developer uses Header/Id to figure out what to base a diff on for
> mergin
On Sun, Aug 16, 2015 at 12:33:05PM -0500, William Hubbs wrote:
> On Sat, Aug 15, 2015 at 02:44:47PM +0200, Peter Stuge wrote:
> > Hi and happy Git days! :)
> >
> >
> > Robin H. Johnson wrote:
> > > It expands to the hash of the blob of that file; and from that, you can
> > > identify which commit
On Sat, Aug 15, 2015 at 02:44:47PM +0200, Peter Stuge wrote:
> Hi and happy Git days! :)
>
>
> Robin H. Johnson wrote:
> > It expands to the hash of the blob of that file; and from that, you can
> > identify which commits the blob exists in.
>
> $ git ls-tree HEAD README
> 100644 blob 08ae16956b
On Sat, Aug 15, 2015 at 8:44 AM, Peter Stuge wrote:
>
> $ git ls-tree HEAD README
> 100644 blob 08ae16956b8944da2fef75fee892dcba457cf4f0README
> $
>
> $ (stat --printf='blob %s\0' README; cat README) | sha1sum
> 08ae16956b8944da2fef75fee892dcba457cf4f0 -
> $
>
> This is so simple to generate
On Sat, Aug 15, 2015 at 7:24 AM, hasufell wrote:
>
> No one has proven that git is cryptographically insecure. Everyone
> claiming that probably refers to
> https://www.schneier.com/blog/archives/2012/10/when_will_we_se.html and
> the fact that we don't sign blob objects.
>
> While that is somethi
On 15 Aug 2015 20:45, "Peter Stuge" wrote:
>
> Hi and happy Git days! :)
>
>
> Robin H. Johnson wrote:
> > It expands to the hash of the blob of that file; and from that, you can
> > identify which commits the blob exists in.
>
> $ git ls-tree HEAD README
> 100644 blob 08ae16956b8944da2fef75fee892
Hi and happy Git days! :)
Robin H. Johnson wrote:
> It expands to the hash of the blob of that file; and from that, you can
> identify which commits the blob exists in.
$ git ls-tree HEAD README
100644 blob 08ae16956b8944da2fef75fee892dcba457cf4f0README
$
$ (stat --printf='blob %s\0' READM
On 08/15/2015 11:56 AM, Andrew Savchenko wrote:
> On Sat, 15 Aug 2015 11:02:19 +0200 Michał Górny wrote:
> OK, if manifests are that important, why not generate full manifest
> during repoman commit? If we do not tamper with $Id$, the only file
> outside of this manifest will be ChangeL
On 15 August 2015 at 21:56, Andrew Savchenko wrote:
> And even with current thin-manifest
> workflow there may be conflict if they touch the same files.
They'll be single-line conflicts though, which will mean assuming
different developers touch different files, git will be able to
trivially mer
On Sat, 15 Aug 2015 11:02:19 +0200 Michał Górny wrote:
> > > > OK, if manifests are that important, why not generate full manifest
> > > > during repoman commit? If we do not tamper with $Id$, the only file
> > > > outside of this manifest will be ChangeLog generated during rsync
> > > > propagatio
Dnia 2015-08-15, o godz. 11:51:01
Andrew Savchenko napisał(a):
> On Sat, 15 Aug 2015 09:53:37 +0200 Michał Górny wrote:
> > Dnia 2015-08-15, o godz. 10:50:02
> > Andrew Savchenko napisał(a):
> >
> > > Hi,
> > >
> > > On Fri, 14 Aug 2015 10:54:57 -0400 Rich Freeman wrote:
> > > > On Fri, Aug 14
On Sat, 15 Aug 2015 09:53:37 +0200 Michał Górny wrote:
> Dnia 2015-08-15, o godz. 10:50:02
> Andrew Savchenko napisał(a):
>
> > Hi,
> >
> > On Fri, 14 Aug 2015 10:54:57 -0400 Rich Freeman wrote:
> > > On Fri, Aug 14, 2015 at 8:45 AM, Kristian Fiskerstrand
> > > wrote:
> > > > They will be Open
Dnia 2015-08-15, o godz. 10:50:02
Andrew Savchenko napisał(a):
> Hi,
>
> On Fri, 14 Aug 2015 10:54:57 -0400 Rich Freeman wrote:
> > On Fri, Aug 14, 2015 at 8:45 AM, Kristian Fiskerstrand
> > wrote:
> > > They will be OpenPGP signed by a releng key during thickening and
> > > portage will auto-
Hi,
On Fri, 14 Aug 2015 10:54:57 -0400 Rich Freeman wrote:
> On Fri, Aug 14, 2015 at 8:45 AM, Kristian Fiskerstrand
> wrote:
> > They will be OpenPGP signed by a releng key during thickening and
> > portage will auto-verify it using gkeys once things are in place. As
> > such checksum for ebuild
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 08/14/2015 04:54 PM, Rich Freeman wrote:
> On Fri, Aug 14, 2015 at 8:45 AM, Kristian Fiskerstrand
> wrote:
>>
>>>
>>> 2. The question is why manifests are modified for rsync. In
>>> git manifests are thin (only distfiles are there), in rsync
>>
On Fri, Aug 14, 2015 at 8:45 AM, Kristian Fiskerstrand wrote:
>
>>
>> 2. The question is why manifests are modified for rsync. In git
>> manifests are thin (only distfiles are there), in rsync they also
>> contain checksums for ebuilds and files dir content. Do we really
>> need this? These manife
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 14/08/15 07:56 AM, Andrew Savchenko wrote:
> 2. The question is why manifests are modified for rsync. In git
> manifests are thin (only distfiles are there), in rsync they
> also contain checksums for ebuilds and files dir content. Do we
> really
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 14/08/15 07:16 AM, hasufell wrote:
> On 08/14/2015 01:10 PM, Andrew Savchenko wrote:
>> On Fri, 14 Aug 2015 02:11:09 -0700 Daniel Campbell (zlg)
>> wrote:
>>> I honestly don't see the point of this when `git log` or even
>>> `git diff` or standard
> They will be OpenPGP signed by a releng key during thickening and
> portage will auto-verify it using gkeys once things are in place. As
> such checksum for ebuilds and other files certainly needs to be part
> of the manifest, otherwise it can open up for malicious alterations of
> these files.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 08/14/2015 01:56 PM, Andrew Savchenko wrote:
..
>
> 2. The question is why manifests are modified for rsync. In git
> manifests are thin (only distfiles are there), in rsync they also
> contain checksums for ebuilds and files dir content. Do
On Fri, 14 Aug 2015 13:16:47 +0200 hasufell wrote:
> On 08/14/2015 01:10 PM, Andrew Savchenko wrote:
> > On Fri, 14 Aug 2015 02:11:09 -0700 Daniel Campbell (zlg) wrote:
> >> I honestly don't see the point of this when `git log` or even `git
> >> diff` or standard `diff` will tell you if what's in y
On 08/14/2015 01:10 PM, Andrew Savchenko wrote:
> On Fri, 14 Aug 2015 02:11:09 -0700 Daniel Campbell (zlg) wrote:
>> I honestly don't see the point of this when `git log` or even `git
>> diff` or standard `diff` will tell you if what's in your overlay
>> differs from the source. With some bash magi
On Fri, 14 Aug 2015 02:11:09 -0700 Daniel Campbell (zlg) wrote:
> I honestly don't see the point of this when `git log` or even `git
> diff` or standard `diff` will tell you if what's in your overlay
> differs from the source. With some bash magic it could even be
> automated. The point of that 'fe
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 08/13/2015 12:43 PM, Robin H. Johnson wrote:
> On Thu, Aug 13, 2015 at 10:36:16AM -0500, William Hubbs wrote:
>> I understood the usefulness of this line to some when we were
>> using CVS since it expanded into the ebuild revision, date, etc.
>>
On 14 August 2015 at 17:45, Michał Górny wrote:
> Don't force the implicit expansion on all developers and users forking
> the repo.
You wouldn't, I thought we were talking about $Id$ only being expanded
on the git->rsync transition, and people worrying that $Id$ would be
expanded in patches, wh
Dnia 2015-08-14, o godz. 13:55:47
Kent Fredric napisał(a):
> On 14 August 2015 at 07:59, Rich Freeman wrote:
> > Will that include any case where the string "$Id$" appears in a patch file?
>
>
> Surely that can be avoided by using a git attributes specification
> that only applies to */*/*.eb
On 14 August 2015 at 07:59, Rich Freeman wrote:
> Will that include any case where the string "$Id$" appears in a patch file?
Surely that can be avoided by using a git attributes specification
that only applies to */*/*.ebuild ?
--
Kent
KENTNL - https://metacpan.org/author/KENTNL
On Thu, Aug 13, 2015 at 7:28 PM, Robin H. Johnson wrote:
> On Thu, Aug 13, 2015 at 03:59:37PM -0400, Rich Freeman wrote:
>> On Thu, Aug 13, 2015 at 3:43 PM, Robin H. Johnson wrote:
>> > The intent is that the ONLY place the keywords are expanded, will be in
>> > the rsync export. FUTURE tense, it
On Thu, Aug 13, 2015 at 03:59:37PM -0400, Rich Freeman wrote:
> On Thu, Aug 13, 2015 at 3:43 PM, Robin H. Johnson wrote:
> > The intent is that the ONLY place the keywords are expanded, will be in
> > the rsync export. FUTURE tense, it's not ready yet.
> Will that include any case where the string
On Thu, Aug 13, 2015 at 3:43 PM, Robin H. Johnson wrote:
>
> The intent is that the ONLY place the keywords are expanded, will be in
> the rsync export. FUTURE tense, it's not ready yet.
>
Will that include any case where the string "$Id$" appears in a patch file?
That is the main source of prob
On Thu, Aug 13, 2015 at 10:36:16AM -0500, William Hubbs wrote:
> I understood the usefulness of this line to some when we were using CVS
> since it expanded into the ebuild revision, date, etc.
>
> This expansion doesn't take place under git, so now I don't understand
> the usefulness of this line
31 matches
Mail list logo
