On Fri, Jan 31, 2014 at 2:22 PM, Guy Harris wrote:
>
> On Jan 31, 2014, at 10:26 AM, Evan Huus wrote:
>
>> On Fri, Jan 31, 2014 at 12:44 PM, Guy Harris wrote:
>>>
>>> On Jan 31, 2014, at 2:22 AM, Roland Knall wrote:
>>>
But one clarification. You do not check-out a project with git. This
>
On Fri, Jan 31, 2014 at 6:20 PM, Evan Huus wrote:
> On Fri, Jan 31, 2014 at 4:01 PM, Graham Bloice
> wrote:
>>>
>>> I use git-review which adds a "git review" command that does the right
>>> thing with respect to gerrit.
>>> https://github.com/openstack-infra/git-review
>>>
>>
>> I was looking in
On Fri, Jan 31, 2014 at 4:01 PM, Graham Bloice
wrote:
>>
>> I use git-review which adds a "git review" command that does the right
>> thing with respect to gerrit.
>> https://github.com/openstack-infra/git-review
>>
>
> I was looking into git-review and it appears things work automagically if
> th
>
>
> I use git-review which adds a "git review" command that does the right
> thing with respect to gerrit.
> https://github.com/openstack-infra/git-review
>
>
I was looking into git-review and it appears things work automagically if
the repository has .gitreview file. Can someone who knows what
On Fri, Jan 31, 2014 at 3:29 PM, David Ameiss wrote:
> On 01/31/2014 02:03 PM, Evan Huus wrote:
>>
>> On Fri, Jan 31, 2014 at 2:33 PM, David Ameiss
>> wrote:
>>>
>>> On 01/31/2014 01:03 PM, Evan Huus wrote:
Wow, that sounds awesome.
Question: What is the current layout/st
On 1/31/14 8:55 AM, Peter Wu wrote:
> On Friday 31 January 2014 11:46:34 Hadriel Kaplan wrote:
>> Any specific leading character(s) we should use, so that bugzilla can
>> someday parse it and insert the appropriate url? Like ‘c[commit_id_sha1]'
>
> I propose the regex /\bcommit [0-9a-f]{4,40}\b/i
On 01/31/2014 02:03 PM, Evan Huus wrote:
On Fri, Jan 31, 2014 at 2:33 PM, David Ameiss wrote:
On 01/31/2014 01:03 PM, Evan Huus wrote:
Wow, that sounds awesome.
Question: What is the current layout/structure of the new code? I
imagine one c file per dissector in epan/dissectors/, but where a
On Fri, Jan 31, 2014 at 2:33 PM, David Ameiss wrote:
> On 01/31/2014 01:03 PM, Evan Huus wrote:
>>
>> Wow, that sounds awesome.
>>
>> Question: What is the current layout/structure of the new code? I
>> imagine one c file per dissector in epan/dissectors/, but where are
>> all the other c files? A
On Fri, Jan 31, 2014 at 2:22 PM, Guy Harris wrote:
>
> On Jan 31, 2014, at 10:26 AM, Evan Huus wrote:
>
>> On Fri, Jan 31, 2014 at 12:44 PM, Guy Harris wrote:
>>>
>>> On Jan 31, 2014, at 2:22 AM, Roland Knall wrote:
>>>
But one clarification. You do not check-out a project with git. This
>
On Jan 31, 2014, at 10:26 AM, Evan Huus wrote:
> On Fri, Jan 31, 2014 at 12:44 PM, Guy Harris wrote:
>>
>> On Jan 31, 2014, at 2:22 AM, Roland Knall wrote:
>>
>>> But one clarification. You do not check-out a project with git. This
>>> is a misconception. You clone the complete repository of
On Jan 31, 2014, at 11:45 AM, mman...@netscape.net wrote:
> Without looking at the details of the patch, my thoughts are:
>
> 1. I like the fact that a "workaround" has been created for insufficient
> heuristics. I just hope it doesn't have the unintended consequence of weaker
> heuristics b
Wow, that sounds awesome.
Question: What is the current layout/structure of the new code? I
imagine one c file per dissector in epan/dissectors/, but where are
all the other c files? Are the capabilities they add shared only
between your protocols, or might they be useful to other protocols?
How b
On Jan 31, 2014, at 5:13 AM, Michal Labedzki wrote:
> Use case: For example heuristic for "mp2t" fail on file in format VWR
> (VWR will be open as mp2t). Currently you are not able to open VWR in
> this case.
...unless the VWR file's name ends with ".vwr" and you're opening it on the
trunk, as
We've developed a set of dissectors for my company's protocols - all
based on UDP and TCP. I've gotten the OK to submit them to Wireshark,
and have spent the last 2 months tracking the development changes,
keeping things current, and just finished moving over to the new
git/gerrit approach.
T
On Fri, Jan 31, 2014 at 12:44 PM, Guy Harris wrote:
>
> On Jan 31, 2014, at 2:22 AM, Roland Knall wrote:
>
>> But one clarification. You do not check-out a project with git. This
>> is a misconception. You clone the complete repository of wireshark
>> into a local copy.
>
> Unfortunately, yes, th
On Jan 31, 2014, at 2:22 AM, Roland Knall wrote:
> But one clarification. You do not check-out a project with git. This
> is a misconception. You clone the complete repository of wireshark
> into a local copy.
Unfortunately, yes, that's what happens, imposing a requirement to push changes
afte
Without looking at the details of the patch, my thoughts are:
1. I like the fact that a "workaround" has been created for insufficient
heuristics. I just hope it doesn't have the unintended consequence of weaker
heuristics being created.
2. What I don't like is getting non capture file sup
Howdy,
I noticed myself and some others recently submitting changes to .gitignore,
adding files we keep in our directories, such as our favorite editor’s specific
files.
Being a git newbie I figured this was just going to be necessary, and
wireshark’s .gitignore would grow to include a very lar
On Friday 31 January 2014 11:46:34 Hadriel Kaplan wrote:
> Any specific leading character(s) we should use, so that bugzilla can
> someday parse it and insert the appropriate url? Like ‘c[commit_id_sha1]'
I propose the regex /\bcommit [0-9a-f]{4,40}\b/i (or /[Cc]ommit .../ without i
modifier). "c
Any specific leading character(s) we should use, so that bugzilla can someday
parse it and insert the appropriate url?
Like ‘c[commit_id_sha1]'
-hadriel
On Jan 31, 2014, at 11:28 AM, Bálint Réczey wrote:
> Hi Hadriel,
>
> 2014-01-31 Hadriel Kaplan :
>> In the past with svn, when we found a
Hi Hadriel,
2014-01-31 Hadriel Kaplan :
> In the past with svn, when we found a bug caused by a previous code change,
> we used the revision number in bugzilla comments with a leading ‘r’, like
> ‘r12345’. This would auto-create a very convenient url link in bugzilla to
> the svn browsing web
I believe the standard is typically to use the abbreviated SHA of the
commit (first 8-10 chars is usually enough to guarantee uniqueness). I
don't know whether bugzilla currently auto-links such text, but
presumably it can be configured.
On Fri, Jan 31, 2014 at 11:17 AM, Hadriel Kaplan
wrote:
> I
In the past with svn, when we found a bug caused by a previous code change, we
used the revision number in bugzilla comments with a leading ‘r’, like
‘r12345’. This would auto-create a very convenient url link in bugzilla to the
svn browsing web pages. Now that we’re on git, do we:
1) continu
Hi Evan,
2014-01-30 Evan Huus :
> On Thu, Jan 30, 2014 at 2:35 PM, Gerald Combs wrote:
>> On 1/30/14 6:17 AM, Bálint Réczey wrote:
>>> Hi,
>>>
>>> 2014-01-30 Evan Huus :
I believe the simpler answer is that the submit type has been set to
"Merge If Necessary" which means if changes are
Hello,
There is a need to have a feedback about my propose of change (extend)
default procedure of opening file in Wireshark. I propose add ability
to choose format. Default behaviour is still "Automatic". New is
component (GUI, list) where you can choose opening format.
Use case: For example heu
Btw, take a look at https://wiki.openstack.org/wiki/GitCommitMessages
to see more clear what I mean with commiting changes separately. They
have a very good discussion about what differs good commits from bad
ones, not necessarily applying to only git.
regards,
Roland
On Fri, Jan 31, 2014 at 11:2
On Fri, Jan 31, 2014 at 10:40 AM, Guy Harris wrote:
> ...and I use multiple sheets of paper for multiple ideas.
>
> I.e., it sounded as if you were talking about using a *single* checked-out
> tree for *multiple independent* projects, which I would no more do than would
> I use a single window f
On Jan 31, 2014, at 12:58 AM, Roland Knall wrote:
> Branches are more of sheets of paper, you add to a folder
> or remove, depending on your progress and ideas.
...and I use multiple sheets of paper for multiple ideas.
I.e., it sounded as if you were talking about using a *single* checked-out
On Fri, Jan 31, 2014 at 9:23 AM, Guy Harris wrote:
> Actually, if I'm working on various parts of the source at the same time,
> because I have more than one project in progress, I have multiple separate
> trees, so there's nothing to switch. (There are, I guess, people out there
> who actuall
On Jan 31, 2014, at 12:17 AM, Roland Knall wrote:
> You can also take a look at
> http://stackoverflow.com/questions/457927/git-workflow-and-rebase-vs-merge-questions
I did, and saw a comment that said:
Unfortunately, the new Pragmstic Programming book is mostly written
from using Git
On Jan 31, 2014, at 12:17 AM, Roland Knall wrote:
> 2. You may work on various parts of the source at the same time, e.g.
> changing an interface for the UI and therefore adding changes to gtk,
> qt and tshark at the same time. For this you add a branch for the
> underlying change, and each indi
Hi
There are a couple of reasons why you should not work on master, and
they nearly all come back to the argument: "rebase is nearly allways
preferable over merge"
1. You are doing local reviews of patches. Those can be done in
separate sub-branches and reside there, no matter if you pull up
mast
32 matches
Mail list logo
