This patch rewrites append_todo_help() from shell to C. The C version
covers a bit more than the old shell version. To achieve that, some
parameters were added to rebase--helper.
This is part of the effort to rewrite interactive rebase in C.
Changes since v1:
- Renaming the parameter to insert
This rewrites append_todo_help() from shell to C. It also incorporates
some parts of initiate_action() and complete_action() that also write
help texts to the todo file.
Two flags are added to rebase--helper.c: one to call
append_todo_help() (`--append-todo-help`), and another one to tell
On Tue, Jun 05 2018, Tim Friske wrote:
> Hi Everyone,
>
> ten days ago I asked on https://unix.stackexchange.com/ why Git is not
> creating a merge commit when merging a signed/annotated tag. Does someone has
> an answer to my question
>
Hi Everyone,
ten days ago I asked on https://unix.stackexchange.com/ why Git is not creating
a merge commit when merging a signed/annotated tag. Does someone has an answer
to my question
On Tue, 5 Jun 2018, SZEDER Gábor wrote:
> > Change deprecated "--set-upstream" branch option to
> > preferred "--set-upstream-to".
> >
> > Signed-off-by: Robert P. J. Day
> >
> > ---
> >
> > i'm assuming this should use "--set-upstream-to" as do all the
> > others.
>
> I don't think so, see
> Change deprecated "--set-upstream" branch option to
> preferred "--set-upstream-to".
>
> Signed-off-by: Robert P. J. Day
>
> ---
>
> i'm assuming this should use "--set-upstream-to" as do all the
> others.
I don't think so, see 52668846ea (builtin/branch: stop supporting the
Change deprecated "--set-upstream" branch option to
preferred "--set-upstream-to".
Signed-off-by: Robert P. J. Day
---
i'm assuming this should use "--set-upstream-to" as do all the
others.
diff --git a/t/t3200-branch.sh b/t/t3200-branch.sh
index 69ea8202f4..ef887a0b32 100755
---
On 5 June 2018 at 11:49, Merland Romain wrote:
>
>> @@ -91,6 +93,13 @@ def p4_build_cmd(cmd):
>> real_cmd = ' '.join(real_cmd) + ' ' + cmd
>> else:
>> real_cmd += cmd
>> +
>> +# now check that we can actually talk to the server
>> +global p4_access_checked
>> +if
On 5 June 2018 at 10:54, Eric Sunshine wrote:
> On Tue, Jun 5, 2018 at 5:14 AM Luke Diamand wrote:
>> This change lays some groundwork for better handling of rowcount errors
>> from the server, where it fails to send us results because we requested
>> too many.
>>
>> It adds an option to
On Tue, Jun 5, 2018 at 5:14 AM Luke Diamand wrote:
> git-p4 originally would fetch changes in one query. On large repos this
> could fail because of the limits that Perforce imposes on the number of
> items returned and the number of queries in the database.
>
> To fix this, git-p4 learned to
On Tue, Jun 5, 2018 at 5:14 AM Luke Diamand wrote:
> This change lays some groundwork for better handling of rowcount errors
> from the server, where it fails to send us results because we requested
> too many.
>
> It adds an option to p4CmdList() to return errors as a Python exception.
>
> The
The current code traps all exceptions around some code which parses an
integer, and then talks to Perforce.
That can result in errors from Perforce being ignored. Change the code
to only catch the integer conversion exceptions.
Signed-off-by: Luke Diamand
---
git-p4.py | 2 +-
1 file changed,
This patchset improves the way that git-p4 sends requests in "blocks".
The problem comes about because the Perforce server limits the maximum
number of results it will send back (there are actually two different
limits).
This causes git-p4 failures if you ask for too much data.
In commit
git-p4 originally would fetch changes in one query. On large repos this
could fail because of the limits that Perforce imposes on the number of
items returned and the number of queries in the database.
To fix this, git-p4 learned to query changes in blocks of 512 changes,
However, this can be
This change lays some groundwork for better handling of rowcount errors
from the server, where it fails to send us results because we requested
too many.
It adds an option to p4CmdList() to return errors as a Python exception.
The exceptions are derived from P4Exception (something went wrong),
If git-p4 cannot talk to the Perforce server, it will either give a
confusing error message, or just crash. Even I get tripped up by this.
This change just checks that the client can talk to the server, and in
particular that the user is logged in (the default login timeout is 12
hours).
It
Currently when p4 fails to run, git-p4 just crashes with an obscure
error message.
For example, if the P4 ticket has expired, you get:
Error: Cannot locate perforce checkout of in client view
This change checks whether git-p4 can talk to the Perforce server when
the first P4 operation is
On Tue, Jun 5, 2018 at 4:29 AM Luke Diamand wrote:
> Add an option to the git-p4 submit command to disable syncing
> with Perforce.
>
> This is useful for the case where a git-p4 mirror has been setup
> on a server somewhere, running from (e.g.) cron, and developers
> then clone from this. Having
Add an option to the git-p4 submit command to disable syncing
with Perforce.
This is useful for the case where a git-p4 mirror has been setup
on a server somewhere, running from (e.g.) cron, and developers
then clone from this. Having the local cloned copy also sync
from Perforce just isn't
This is a small patch to git-p4 to disable the automatic sync after
submit.
In my day-to-day work, I have a central git-p4 repo which is
automatically kept up-to-date, so the repos where I actually work and
submit from don't even need the sync. I usually end up hitting Ctrl-C
partway through the
This just lets you set the --disable-rebase option with the
git configuration options git-p4.disableRebase. If you're
using this option, you probably want to set it all the time
for a given repo.
Signed-off-by: Luke Diamand
---
Documentation/git-p4.txt | 5 -
git-p4.py| 2 +-
On Sun, Jun 3, 2018 at 8:19 PM, Junio C Hamano wrote:
> Elijah Newren writes:
>
>> `git merge-recursive` does a three-way merge between user-specified trees
>> base, head, and remote. Since the user is allowed to specify head, we can
>> not necesarily assume that head == HEAD.
>>
>> We modify
101 - 122 of 122 matches
Mail list logo
