On Mon, Jun 23, 2014 at 09:17:32PM -0400, Evan Huus wrote:
> > >> So perhaps what we should do is:
> > >>
> > >> not check generated code into Git;
> > >>
> > >> put all generated code into the source tarballs.
+2
> > Presumably we should rebuild all the DCERPC files as well at bu
> On Jun 23, 2014, at 23:03, Anders Broman wrote:
>
>
> Den 24 jun 2014 03:18 skrev "Evan Huus" :
> >
> > On Mon, Jun 23, 2014 at 8:42 PM, Anders Broman wrote:
> >>
> >>
> >> -- Vidarebefordrat meddelande --
> >> Från: "Evan Huus"
> >> Datum: 24 jun 2014 00:14
> >> Ämne: Re: [
Den 24 jun 2014 03:18 skrev "Evan Huus" :
>
> On Mon, Jun 23, 2014 at 8:42 PM, Anders Broman
wrote:
>>
>>
>> -- Vidarebefordrat meddelande --
>> Från: "Evan Huus"
>> Datum: 24 jun 2014 00:14
>> Ämne: Re: [Wireshark-dev] Storing Generated Code in Git [Was: master
9079e3a: Cheat and
On Mon, Jun 23, 2014 at 8:42 PM, Anders Broman wrote:
>
> -- Vidarebefordrat meddelande --
> Från: "Evan Huus"
> Datum: 24 jun 2014 00:14
> Ämne: Re: [Wireshark-dev] Storing Generated Code in Git [Was: master
> 9079e3a: Cheat and try to fix the generated file manually.]
> Till: "
-- Vidarebefordrat meddelande --
Från: "Evan Huus"
Datum: 24 jun 2014 00:14
Ämne: Re: [Wireshark-dev] Storing Generated Code in Git [Was: master
9079e3a: Cheat and try to fix the generated file manually.]
Till: "Developer support list for Wireshark"
Kopia:
> On Mon, Jun 23, 2014
On Mon, Jun 23, 2014 at 5:32 PM, Guy Harris wrote:
>
> On Jun 23, 2014, at 2:06 PM, Evan Huus wrote:
>
> > As far as I can see, the main arguments for storing generated code in
> git are:
> > - not all platforms have the tools necessary to generate the code
> > - generating it can take lots of t
On Jun 23, 2014, at 2:06 PM, Evan Huus wrote:
> As far as I can see, the main arguments for storing generated code in git are:
> - not all platforms have the tools necessary to generate the code
> - generating it can take lots of time
I see four different types of people/groups building from so
Perhaps this is a discussion we should have had at Sharkfest, but it's come
up now. Oh well.
My objections to generated code in git are two-fold: practical and
philosophical.
Practically, it's painful to have to run make twice to test ASN.1 changes.
It's painful to review diffs full of #line chan
On Mon, Jun 23, 2014 at 4:32 PM, Pascal Quantin
wrote:
> Hi all,
>
> Le 23/06/2014 22:22, Jakub Zawadzki a écrit :
> > Hello Evan,
> >
> > On Mon, Jun 23, 2014 at 02:10:13PM -0400, Evan Huus wrote:
> >> Storing generated files in source control makes maintenance and patch
> >> review much harder
Hi all,
Le 23/06/2014 22:22, Jakub Zawadzki a écrit :
> Hello Evan,
>
> On Mon, Jun 23, 2014 at 02:10:13PM -0400, Evan Huus wrote:
>> Storing generated files in source control makes maintenance and patch
>> review much harder and puts extra requirements on us to keep things in
>> sync. I'd rather
On Mon, Jun 23, 2014 at 4:22 PM, Jakub Zawadzki
wrote:
> Hello Evan,
>
> On Mon, Jun 23, 2014 at 02:10:13PM -0400, Evan Huus wrote:
> > Storing generated files in source control makes maintenance and patch
> > review much harder and puts extra requirements on us to keep things in
> > sync. I'd ra
Hello Evan,
On Mon, Jun 23, 2014 at 02:10:13PM -0400, Evan Huus wrote:
> Storing generated files in source control makes maintenance and patch
> review much harder and puts extra requirements on us to keep things in
> sync. I'd rather the computer do the extra work :)
But in the same time, we can
Den 23 jun 2014 20:11 skrev "Evan Huus" :
>
> On Mon, Jun 23, 2014 at 1:50 PM, Anders Broman
wrote:
>>
>>
>> Den 23 jun 2014 19:08 skrev "Evan Huus" :
>>
>>
>> >
>> > I have nothing against the change in general, as long as we do it by
adding only the original .gperf file to git and run gperf duri
On Mon, Jun 23, 2014 at 1:50 PM, Anders Broman wrote:
>
> Den 23 jun 2014 19:08 skrev "Evan Huus" :
>
> >
> > I have nothing against the change in general, as long as we do it by
> adding only the original .gperf file to git and run gperf during build to
> generate C file.
>
> I don't want to pus
Den 23 jun 2014 19:08 skrev "Evan Huus" :
>
> I have nothing against the change in general, as long as we do it by
adding only the original .gperf file to git and run gperf during build to
generate C file.
I don't want to push this in absurdum but generating files on all platforms
might be difficu
On 23 June 2014 18:07, Evan Huus wrote:
> I have nothing against the change in general, as long as we do it by
> adding only the original .gperf file to git and run gperf during build to
> generate C file.
>
>
>
>
Which is unlikely to succeed on Windows.
__
I have nothing against the change in general, as long as we do it by adding
only the original .gperf file to git and run gperf during build to generate
C file.
On Mon, Jun 23, 2014 at 1:02 PM, Anders Broman wrote:
>
> Den 23 jun 2014 18:18 skrev "Bálint Réczey" :
>
> >
> > Hi,
> >
> > 2014-06-2
Den 23 jun 2014 18:18 skrev "Bálint Réczey" :
>
> Hi,
>
> 2014-06-23 17:54 GMT+02:00 Evan Huus :
> > I would *really* prefer we didn't do this.
> Me, too. Going this way makes maintaining Wireshark really hard. And
> for 1% speed increase in a very specific case
Well even small changes adds up...
Hi,
2014-06-23 17:54 GMT+02:00 Evan Huus :
> I would *really* prefer we didn't do this.
Me, too. Going this way makes maintaining Wireshark really hard. And
for 1% speed increase in a very specific case?
I generally don't agree with the approach and in this specific IMO the
gains did not justify t
Den 23 jun 2014 17:55 skrev "Evan Huus" :
>
> I would *really* prefer we didn't do this.
>
Feel free to revert the changes then.
Regards
Anders
>
> On Mon, Jun 23, 2014 at 11:30 AM, Wireshark code review <
code-review-do-not-re...@wireshark.org> wrote:
>>
>> URL:
https://code.wireshark.org/review/g
I would *really* prefer we didn't do this.
On Mon, Jun 23, 2014 at 11:30 AM, Wireshark code review <
code-review-do-not-re...@wireshark.org> wrote:
> URL:
> https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commit;h=9079e3ad1d32c594309a52ccef5936d11a93a55d
> Submitter: Anders Broman (a.
Hi,
First, a request: could the gitweb commit messages also be post-
processed such that things like "Bug: XXX" and URLs become clickable?
An arbitrary example that shows the expected and actual messages:
https://code.wireshark.org/review/999/
https://code.wireshark.org/review/gitweb?p=wireshark.
22 matches
Mail list logo
