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
20 matches
Mail list logo
