On 20 April 2016 at 16:51, Junio C Hamano wrote:
> Luke Diamand writes:
>
>> One thing I wondered about is whether this should be enabled by
>> default or not. Long-time users of git-p4 might be a bit surprised to
>> find their git commits suddenly gaining an extra Job: field.
>
> Ahh, I didn't e
> One thing I wondered about is whether this should be enabled by
> default or not. Long-time users of git-p4 might be a bit surprised to
> find their git commits suddenly gaining an extra Job: field.
I thought about that too when but then I realized that there's no
switch for the reverse directio
Luke Diamand writes:
> One thing I wondered about is whether this should be enabled by
> default or not. Long-time users of git-p4 might be a bit surprised to
> find their git commits suddenly gaining an extra Job: field.
Ahh, I didn't even wonder about but that is not because I didn't
think it
On 19 April 2016 at 22:39, Junio C Hamano wrote:
> Jan Durovec writes:
>
>> On Tue, Apr 19, 2016 at 11:09 PM, Junio C Hamano wrote:
>>
>>> For a series this small it does not matter, but anything longer it
>>> would be easier to review with a cover letter (i.e. [PATCH 0/N]). I
>>> do not know i
On 19 April 2016 at 22:44, Jan Durovec wrote:
>> By the way, you may or may not have noticed that I've been
>> reordering the lines of your message quoted in my responses; around
>> here, top-posting is frowned upon.
>
> I haven't noticed. Thanks for pointing out.
>
> As for the submitGit cover le
> By the way, you may or may not have noticed that I've been
> reordering the lines of your message quoted in my responses; around
> here, top-posting is frowned upon.
I haven't noticed. Thanks for pointing out.
As for the submitGit cover letter I wanted to raise at least an issue
(if not create
Jan Durovec writes:
> On Tue, Apr 19, 2016 at 11:09 PM, Junio C Hamano wrote:
>
>> For a series this small it does not matter, but anything longer it
>> would be easier to review with a cover letter (i.e. [PATCH 0/N]). I
>> do not know if submitGit lets us do that, though.
>
> There's a comment
There's a comment on PR itself (in addition to individual commits) so
theoretically it could.
It seems that for [PATCH ... n/m] e-mails the commit messages are used,
so there's no reason why the PR comment couldn't be used for a cover
letter.
In this case the PR comment was the same as for one of
Jan Durovec writes:
> On Tue, Apr 19, 2016 at 8:50 PM, Jan Durovec wrote:
>>> Any submitGit users? I think it lets you throw multiple-patch
>>> series just fine. In this case, you'd prepare a two patch series on
>>> a branch, 1/2 being the clean-up and 2/2 being the new feature, and
>>> if you
Huh... seems that it works :)
v3 sent in 2 parts
On Tue, Apr 19, 2016 at 8:50 PM, Jan Durovec wrote:
>> Any submitGit users? I think it lets you throw multiple-patch
>> series just fine. In this case, you'd prepare a two patch series on
>> a branch, 1/2 being the clean-up and 2/2 being the new
> Any submitGit users? I think it lets you throw multiple-patch
> series just fine. In this case, you'd prepare a two patch series on
> a branch, 1/2 being the clean-up and 2/2 being the new feature, and
> if you give that branch to submitGit as a whole it should do the
> right thing, I'd imagine
Jan Durovec writes:
> On Tue, Apr 19, 2016 at 7:47 PM, Junio C Hamano wrote:
>>
>> If you really want to know the preference, we prefer a preliminary
>> clean-up patch to correct existing style issues, followed by a new
>> feature patch that builds on the cleaned up codebase.
>
> Would it be acc
Would it be acceptable the other way around? I.e. this patch followed
by the one that fixes code style (once this gets merged)?
Reason being that I don't know how to use submitGit to generate a patch
against a state that is not already in git repo (ie. based on another
patch).
In the following pa
Junio C Hamano writes:
> Not a new problem in this script, but we'd prefer to spell this as
>
> p4_add_job () {
>
> i.e. a space on both sides of ().
>
>> +name=$1 &&
>> +p4 job -f -i <<-EOF
>> +Job: $name
>> +Status: open
>> +User: dummy
>> +Description:
>> +EOF
>
Jan Durovec writes:
> given the fact that the rest of the code just follows existing
> source code style, i.e.
>
> * using %s not %d to add number to string (see git-p4.py:2301)
This one I do not care too deeply about, as formatting anything that
can be formatted via '%s' could just be more Pyth
Hi,
given the fact that the rest of the code just follows existing
source code style, i.e.
* using %s not %d to add number to string (see git-p4.py:2301)
* no space between function name and parentheses (see all functions
in t/lib-git-p4.sh)
* no tab when specifying in-line expected output (see
Luke Diamand writes:
>> I am not familiar with "Perforce jobs", but I assume that they are
>> always named as "job" + small non-negative integer in a dense way
>> and it is OK for this loop to always begin at 0 and immediately stop
>> when job + num does not exist (i.e. if job7 is missing, it is
On 19 April 2016 at 02:15, Junio C Hamano wrote:
> Jan Durovec writes:
>
>> When migrating from Perforce to git the information about P4 jobs
>> associated with P4 changelists is lost.
>>
>> Having these jobs listed on messages of related git commits enables smooth
>> migration for projects that
On 16 Apr 2016, at 21:58, Jan Durovec wrote:
> When migrating from Perforce to git the information about P4 jobs
> associated with P4 changelists is lost.
>
> Having these jobs listed on messages of related git commits enables smooth
> migration for projects that take advantage of e.g. JIRA int
Jan Durovec writes:
> When migrating from Perforce to git the information about P4 jobs
> associated with P4 changelists is lost.
>
> Having these jobs listed on messages of related git commits enables smooth
> migration for projects that take advantage of e.g. JIRA integration
> (which uses jobs
When migrating from Perforce to git the information about P4 jobs
associated with P4 changelists is lost.
Having these jobs listed on messages of related git commits enables smooth
migration for projects that take advantage of e.g. JIRA integration
(which uses jobs on Perforce side and parses comm
21 matches
Mail list logo
