On Wed, Mar 02, 2016 at 02:37:53PM +0700, Duy Nguyen wrote:
> On Wed, Mar 2, 2016 at 1:31 PM, Junio C Hamano wrote:
> > Al Viro writes:
> >
> >> FWIW, I wasn't proposing to recreate the remaining bits of that _pack_;
> >> just do the normal pull with one addition: start with sending the list
> >>
On Wed, Mar 2, 2016 at 2:37 PM, Duy Nguyen wrote:
>> So in order to salvage some transfer out of 2.4MB, the hypothetical
>> Al protocol would first have the upload-pack give 20*1396 = 28kB
>
> It could be 10*1396 or less
Oops somehow I read previous mails as client sends SHA-1 to server,
not
On Wed, Mar 2, 2016 at 1:31 PM, Junio C Hamano wrote:
> Al Viro writes:
>
>> FWIW, I wasn't proposing to recreate the remaining bits of that _pack_;
>> just do the normal pull with one addition: start with sending the list
>> of sha1 of objects you are about to send and let the recepient reply
>>
Hi,
Clean tested working pulls CPUs and QTYs in stock.
115 X X5650
65 X E5410
75 X X5660
145 X E5530
100 X E5645
40 X X5680
75 X X5690
Brand new sealed IP phones and QTYs in stock.
55 x CP-7937G
77 x CP-7942G
54 x CP-7945G
75 x CP-7962G
..
45 x Avaya 9630
65 x Avaya 9641
55 x Avaya 9640
U
Al Viro writes:
> FWIW, I wasn't proposing to recreate the remaining bits of that _pack_;
> just do the normal pull with one addition: start with sending the list
> of sha1 of objects you are about to send and let the recepient reply
> with "I already have , don't bother with those". And exclude
> Matthieu Moy writes:
>
>> "Sidhant Sharma [:tk]" writes:
>>
>>> Make receive-pack use the parse_options API,
>>> bringing it more in line with send-pack and push.
>> Thanks. This version looks good to me.
> I'll queue this with your "Reviewed-by:" to 'pu', just as a
> Microproject reward ;-).
On 1 March 2016 at 19:15, Eric Sunshine wrote:
> On Tue, Mar 1, 2016 at 5:49 AM, wrote:
>> Map a P4 user to a specific name and email address in Git with the
>> "git-p4.mapUser" config. The config value must be a string adhering
>> to the format "p4user = First Lastname ".
>>
>> Signed-off-by: L
On Tue, Mar 01, 2016 at 04:20:06PM -0500, David Turner wrote:
> On Tue, 2016-03-01 at 09:42 -0500, Jeff King wrote:
> > +/*
> > + * Read the repository format characteristics from the config file
> > "path". If
> > + * the version cannot be extracted from the file for any reason, the
> > version
>
On Tue, Mar 01, 2016 at 07:13:02PM -0500, David Turner wrote:
> On Tue, 2016-03-01 at 09:45 -0500, Jeff King wrote:
> > - char repo_version_string[10];
> >
> > /* This forces creation of new config file */
> > - xsnprintf(repo_version_string, sizeof(repo_version_string),
> > -
On Tue, Mar 01, 2016 at 06:47:52PM -0500, David Turner wrote:
> > My fix for this was to teach read_mailmap to avoid looking for
> > HEAD:.mailmap if we are not in a repository, but to continue with the
> > others (.mailmap in the cwd, and the mailmap.file config variable).
> > ...
> > But I do th
On Tue, Mar 01, 2016 at 05:40:28PM -0800, Stefan Beller wrote:
> So throwing away half finished stuff while keeping the front load?
Throw away the object that got truncated and ones for which delta chain
doesn't resolve entirely in the transferred part.
> > indexing the objects it
> > contains,
Hi,
Clean tested working pulls CPUs and QTYs in stock.
115 X X5650
65 X E5410
75 X X5660
145 X E5530
100 X E5645
40 X X5680
75 X X5690
Brand new sealed IP phones and QTYs in stock.
55 x CP-7937G
77 x CP-7942G
54 x CP-7945G
75 x CP-7962G
..
45 x Avaya 9630
65 x Avaya 9641
55 x Avaya 9640
U
On Wed, Mar 2, 2016 at 8:30 AM, Josh Triplett wrote:
> If you clone a repository, and the connection drops, the next attempt
> will have to start from scratch. This can add significant time and
> expense if you're on a low-bandwidth or metered connection trying to
> clone something like Linux.
>
+ Duy, who tried resumable clone a few days/weeks ago
On Tue, Mar 1, 2016 at 5:30 PM, Josh Triplett wrote:
> If you clone a repository, and the connection drops, the next attempt
> will have to start from scratch. This can add significant time and
> expense if you're on a low-bandwidth or metere
If you clone a repository, and the connection drops, the next attempt
will have to start from scratch. This can add significant time and
expense if you're on a low-bandwidth or metered connection trying to
clone something like Linux.
Would it be possible to make git clone resumable after a partia
On Tue, 2016-03-01 at 09:35 -0500, Jeff King wrote:
> After the discussion in:
>
> http://thread.gmane.org/gmane.comp.version-control.git/287949/focus
> =288002
>
> I came up with this series to try to address some of the warts in
> check_repository_format_gently().
>
> I had hoped to come up
On Tue, 2016-03-01 at 18:47 -0500, David Turner wrote:
> On Tue, 2016-03-01 at 03:35 -0500, Jeff King wrote:
> > On Mon, Feb 29, 2016 at 07:52:34PM -0500, David Turner wrote:
> >
> > > Usually, git calls some form of setup_git_directory at startup.
> > > But
> > > sometimes, it doesn't. Usually
On Tue, Mar 1, 2016 at 3:40 PM, Kevin Daudt wrote:
> git commit has a --no-verify option to prevent the pre-commit hook from
> running. When continuing a conflicted cherry-pick, git commit gets
> executed which also causes the pre-commit hook to be run.
>
> Add --no-verify and pass that through to
On Tue, 2016-03-01 at 09:45 -0500, Jeff King wrote:
> - char repo_version_string[10];
>
> /* This forces creation of new config file */
> - xsnprintf(repo_version_string, sizeof(repo_version_string),
> - "%d", GIT_REPO_VERSION);
> - git_config_set("core.repositoryf
On Tue, 2016-03-01 at 03:35 -0500, Jeff King wrote:
> On Mon, Feb 29, 2016 at 07:52:34PM -0500, David Turner wrote:
>
> > Usually, git calls some form of setup_git_directory at startup.
> > But
> > sometimes, it doesn't. Usually, that's OK because it's not really
> > using the repository. But
This will be necessary when we start reading from a split bundle
where the header and the thin-pack data live in different files.
The in-core bundle header will read from a file that has the header,
and will record the path to that file. We would find the name of
the file that hosts the thin-pack
The bundle header structure holds two lists of refs and object
names, which should be released when the user is done with it.
Signed-off-by: Junio C Hamano
---
bundle.c| 12
bundle.h| 1 +
transport.c | 1 +
3 files changed, 14 insertions(+)
diff --git a/bundle.c b/bundle
Junio C Hamano wrote:
> A more pertinent question may be which version of Git did the above
> ever work, I guess. We fairly liberally chdir around and I do not
> think we deliberately avoid assuming that "cd .git && cd .." might
> not come back to the original directory, for example, so I wouldn't
On Tue, Mar 01, 2016 at 02:49:58PM -0800, Stefan Beller wrote:
> The wording is introduced in c3f0baaca (Documentation: sync git.txt
> command list and manual page title, 2007-01-18), but rebase has evolved
> since then, capture the modern usage by being more generic about the
> rebase command in t
Stefan Beller wrote:
> To elaborate on that: Starting in 2.7 parts of the submodule stuff
> has been rewritten in C, in 2.8 even more and there is more in flight for
> > 2.8.
>
> However your bug is also to be found in 2.6, which doesn't contain any
> recent rewrites, so it is a rather long stand
On Tue, Mar 1, 2016 at 2:49 PM, Stefan Beller wrote:
> The wording is introduced in c3f0baaca (Documentation: sync git.txt
> command list and manual page title, 2007-01-18), but rebase has evolved
> since then, capture the modern usage by being more generic about the
> rebase command in the summar
From: "Junio C Hamano"
Even though the command does read the bundle header and checks to
see if it looks reasonable, the thin-pack data stream that follows
the header in the bundle file is not checked. More importantly,
because the thin-pack data does not have a trailing checksum like
on-disk p
The wording is introduced in c3f0baaca (Documentation: sync git.txt
command list and manual page title, 2007-01-18), but rebase has evolved
since then, capture the modern usage by being more generic about the
rebase command in the summary.
Signed-off-by: Stefan Beller
---
Inspired by
https://
Hi.
Recently I sent Eric (who is CC-ed and these days sporadic available
for deeper analyses) email titled as "git-svn cloning get stuck during
processing huge file".
It was about "git svn clone ..." against repository which had big
third-party files (1,3 GB, 1,1 GB, 80 MB, 55 MB ), temporary stor
Stefan Beller writes:
> * evicted patches:
> run-command: expose default_{start_failure, task_finished}
> run_processes_parallel: correctly terminate callbacks with an LF
> * rebased on top of
> origin/sb/no-child-process-access-in-run-parallel-callbacks
> * followed Jonathans advice on impr
Matthieu Moy writes:
> "Sidhant Sharma [:tk]" writes:
>
>> Make receive-pack use the parse_options API,
>> bringing it more in line with send-pack and push.
>
> Thanks. This version looks good to me.
I'll queue this with your "Reviewed-by:" to 'pu', just as a
Microproject reward ;-). Given tha
On Tue, Mar 1, 2016 at 11:07 AM, Junio C Hamano wrote:
>> I could call expect_askpass here at each time but I don't think it
>> would be meaningful after a test_must_fail.
>
> Even if you call expect_askpass to check, another set_askpass is
> expected to start the next cycle anyway (unless we rest
Stefan Beller writes:
> On Tue, Mar 1, 2016 at 12:42 PM, Joey Hess wrote:
>> git init gitdir
>> mkdir worktree
>> cd worktree
>> ln -s ../gitdir/.git .git
>> git submodule add /any/git/repo sub
>>
>> fatal: Could not chdir to '../../../sub': No suc
On Tue, Mar 1, 2016 at 1:39 PM, Stefan Beller wrote:
> On Tue, Mar 1, 2016 at 12:42 PM, Joey Hess wrote:
>> git init gitdir
>> mkdir worktree
>> cd worktree
>> ln -s ../gitdir/.git .git
>> git submodule add /any/git/repo sub
>>
>> fatal: Could not c
On Tue, Mar 1, 2016 at 12:42 PM, Joey Hess wrote:
> git init gitdir
> mkdir worktree
> cd worktree
> ln -s ../gitdir/.git .git
> git submodule add /any/git/repo sub
>
> fatal: Could not chdir to '../../../sub': No such file or directory
>
> Fairly su
Even though the command does read the bundle header and checks to
see if it looks reasonable, the thin-pack data stream that follows
the header in the bundle file is not checked. More importantly,
because the thin-pack data does not have a trailing checksum like
on-disk packfiles do, there isn't m
On Tue, 2016-03-01 at 09:42 -0500, Jeff King wrote:
> +/*
> + * Read the repository format characteristics from the config file
> "path". If
> + * the version cannot be extracted from the file for any reason, the
> version
> + * field will be set to -1, and all other fields are undefined.
> + */
>
git init gitdir
mkdir worktree
cd worktree
ln -s ../gitdir/.git .git
git submodule add /any/git/repo sub
fatal: Could not chdir to '../../../sub': No such file or directory
Fairly sure this is a bug..
--
see shy jo
signature.asc
Description: PGP
git commit has a --no-verify option to prevent the pre-commit hook from
running. When continuing a conflicted cherry-pick, git commit gets
executed which also causes the pre-commit hook to be run.
Add --no-verify and pass that through to the git commit command so that
the can prevent that from hap
"Sidhant Sharma [:tk]" writes:
> Make receive-pack use the parse_options API,
> bringing it more in line with send-pack and push.
Thanks. This version looks good to me.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bod
> Starting from here, the patch is a bit painful to read because the diff
> heuristics grouped hunks in a strange way. You may try "git format-patch
> --patience" or --minimal or --histogram to see if it gives a better
> result. The final commit would be the same, but it may make review
> easier.
Make receive-pack use the parse_options API,
bringing it more in line with send-pack and push.
Helped-by: Matthieu Moy
Signed-off-by: Sidhant Sharma [:tk]
---
Link to previous version: $gmane/288035
builtin/receive-pack.c | 53 +++---
1 file change
Hi,
As subject, the problem I'm facing is that, while doing an interactive
add, an edited patch fails to apply. The same patch content
successfully applies otherwise, with git apply.
To reproduce the problem:
- Add the attached site.css to an empty git repository, and make an
initial commit
Johannes Sixt writes:
> Am 01.03.2016 um 15:13 schrieb Johannes Schindelin:
>> The pthread_exit() function is not expected to return. Ever. On Windows,
>> we call ExitThread() whose documentation claims: "This function does not
>> return a value.":
>>
>> https://msdn.microsoft.com/en-us/libr
Am 01.03.2016 um 15:13 schrieb Johannes Schindelin:
The pthread_exit() function is not expected to return. Ever. On Windows,
we call ExitThread() whose documentation claims: "This function does not
return a value.":
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682659
This
On Tue, 2016-03-01 at 17:18 +, Ramsay Jones wrote:
>
> On 01/03/16 00:53, David Turner wrote:
> > This sets up the existing backend early, so that other code which
> > reads refs is reading from the right place.
> >
> > Signed-off-by: David Turner
> > Signed-off-by: Junio C Hamano
> > ---
>
On Tue, 2016-03-01 at 17:21 +, Ramsay Jones wrote:
>
> On 01/03/16 00:53, David Turner wrote:
> > It will soon be useful for resolve_ref_unsafe to support
> > submodules.
> > But since it is called from so many places, changing it would have
> > been painful. Fortunately, it's just a thin wra
On Tue, Mar 1, 2016 at 5:49 AM, wrote:
> Map a P4 user to a specific name and email address in Git with the
> "git-p4.mapUser" config. The config value must be a string adhering
> to the format "p4user = First Lastname ".
>
> Signed-off-by: Lars Schneider
> ---
> diff --git a/Documentation/git-p
Jacob Keller writes:
> On Tue, Mar 1, 2016 at 9:26 AM, Junio C Hamano wrote:
>> I find this in t/lib-httpd.sh:
>>
>> set_askpass() {
>> >"$TRASH_DIRECTORY/askpass-query" &&
>> echo "$1" >"$TRASH_DIRECTORY/askpass-user" &&
>> echo "$2" >"$TR
On Tue, Mar 1, 2016 at 12:57 PM, Matthieu Moy
wrote:
> Sidhant Sharma writes:
>> Another thing I'd like to ask is when I prepare the next patch, should
>> it be sent as reply in this thread, or as a new thread?
>
> No strict rule on that, but I usually use --in-reply-to on the root of
> the threa
Saurav Sachidanand writes:
> The values defined by the macro EXC_FLAG_* (1, 4, 8, 16) are
> stored in fields of the structs "pattern" and “exclude”, some
> functions arguments and a local variable.
It's a minor point, but it is somewhat irritating that "pattern" is
enclosed in a regular dq pair
Jeff King writes:
> On Sun, Feb 28, 2016 at 01:35:44AM +0600, Alexander Kuleshov wrote:
>
>> +DECLARE_GIT_GETTER(const char *, get_git_dir, git_dir)
>> +DECLARE_GIT_GETTER(const char *, get_git_namespace, namespace)
>> +DECLARE_GIT_GETTER(char *, get_object_directory, git_object_dir)
>> +DECLARE_
On Tue, Mar 1, 2016 at 9:26 AM, Junio C Hamano wrote:
> I find this in t/lib-httpd.sh:
>
> set_askpass() {
> >"$TRASH_DIRECTORY/askpass-query" &&
> echo "$1" >"$TRASH_DIRECTORY/askpass-user" &&
> echo "$2" >"$TRASH_DIRECTORY/askpass-pass"
>
Sidhant Sharma writes:
>>> + if (argc > 1)
>>> + usage_msg_opt(_("Too many arguments."), receive_pack_usage,
>>> options);
>>> + if (argc == 0)
>>> + usage_msg_opt(_("You must specify a directory."),
>>> receive_pack_usage, options);
>> Before that, the loop was ensuring
writes:
> Am 01.03.2016 um 15:13 schrieb Johannes Schindelin:
>> The pthread_exit() function is not expected to return. Ever. On Windows,
>> we call ExitThread() whose documentation claims: "This function does not
>> return a value.":
>
> Does this really mean that ExitThread() does not return ?
The expected way to pass data into the callback is to pass them via
the customizable callback pointer. The error reporting in
default_{start_failure, task_finished} is not user friendly enough, that
we want to encourage using the child data for such purposes.
Furthermore the struct child data is c
> Hi,
>
> Thanks for your patch.
>
> "Sidhant Sharma [:tk]" writes:
>
>> This patch makes receive-pack use the parse_options API,
> We usually avoid saying "this patch" and use imperative tone: talk to
> your patch and give it orders like "Make receive-pack use the
> parse_options API ...". Or ju
Johannes Sixt writes:
> Am 29.02.2016 um 22:57 schrieb Stefan Beller:
>> The expected way to pass data into the callback is to pass them via
>> the customizable callback pointer. The error reporting in
>> default_{start_failure, task_finished} is not user friendly enough, that
>> we want to encou
Stefan Beller writes:
> On Mon, Feb 29, 2016 at 2:58 PM, Jacob Keller
> wrote:
>>
>> +test_expect_success 'cmdline credential config passes into submodules' '
>> + git init super &&
>> + set_askpass user@host pass@host &&
>
> I wonder why we use pass@host as a password, it seems con
Hi,
Thanks for your patch.
"Sidhant Sharma [:tk]" writes:
> This patch makes receive-pack use the parse_options API,
We usually avoid saying "this patch" and use imperative tone: talk to
your patch and give it orders like "Make receive-pack use the
parse_options API ...". Or just skip that par
On 01/03/16 00:53, David Turner wrote:
> It will soon be useful for resolve_ref_unsafe to support submodules.
> But since it is called from so many places, changing it would have
> been painful. Fortunately, it's just a thin wrapper around (the
> former) resolve_ref_1. So now resolve_ref_1 beco
On 01/03/16 00:53, David Turner wrote:
> This sets up the existing backend early, so that other code which
> reads refs is reading from the right place.
>
> Signed-off-by: David Turner
> Signed-off-by: Junio C Hamano
> ---
> config.c | 1 +
> setup.c | 4
> 2 files changed, 5 insertions
A common mistake leading a user to see this message is to launch "git
commit", let the editor open (and forget about it), and try again to
commit.
The previous message was going too quickly to "a git process crashed"
and to the advice "remove the file manually".
This patch modifies the message in
Signed-off-by: Matthieu Moy
---
lockfile.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 80d056d..62583d1 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -149,13 +149,13 @@ static int lock_file_timeout(struct lock_file *lk, const
char *path,
The values defined by the macro EXC_FLAG_* (1, 4, 8, 16) are
stored in fields of the structs "pattern" and “exclude”, some
functions arguments and a local variable.
No variable that holds these values uses its most significant
bit in any special way, as it’s value is either checked for a
variant o
On Tue, Feb 23, 2016 at 04:44:49PM -0600, Joe Einertson wrote:
> I'm experiencing an annoying issue which leaves the repository in a
> weird, broken state. I am attempting a rather vanilla rebase, rebasing
> the commits from a feature branch on top of the newest commits on
> master.
Can you tell u
This patch makes receive-pack use the parse_options API,
bringing it more in line with send-pack and push.
Helped-by: Matthieu Moy
Signed-off-by: Sidhant Sharma [:tk]
---
builtin/receive-pack.c | 55 ++
1 file changed, 24 insertions(+), 31 deletio
On Tue, Mar 01, 2016 at 10:04:49AM -0500, Fred's Personal wrote:
> Thanks for the insight, it's been a while since I debugged a Windows call
> stack. Can you give me commands to view what gets passed to
> CreateProcessW().
Sorry, my Windows knowledge is several years old. Maybe procmon[1] will
sh
John,
Thanks for the insight, it's been a while since I debugged a Windows call
stack. Can you give me commands to view what gets passed to
CreateProcessW().
Regards,
Fred
freddie...@optonline.net
-Original Message-
From: John Keeping [mailto:j...@keeping.me.uk]
Sent: Monday, Februar
On Sun, Feb 28, 2016 at 01:35:44AM +0600, Alexander Kuleshov wrote:
> +DECLARE_GIT_GETTER(const char *, get_git_dir, git_dir)
> +DECLARE_GIT_GETTER(const char *, get_git_namespace, namespace)
> +DECLARE_GIT_GETTER(char *, get_object_directory, git_object_dir)
> +DECLARE_GIT_GETTER(char *, get_inde
On Mon, Feb 29, 2016 at 10:34:59AM -0800, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
> > Signed-off-by: Nguyễn Thái Ngọc Duy
> > ---
>
> All (or at least most of) these look old ones; even the ones blamed
> to 59f92959 (fmt_ident: refactor strictness checks, 2016-02-04) had
> orig
On Mon, Feb 29, 2016 at 06:38:28PM +0530, Guilherme wrote:
> @Peff Thank you for the heads up.
>
> I'm trying to find out if there are any credential helpers configured
> in the system that will be running tests. On the dedicated test
> machines that is not a problem but the developer machines ar
On Tue, Mar 01, 2016 at 03:48:30AM -0500, Jeff King wrote:
> On Mon, Feb 29, 2016 at 07:53:02PM -0500, David Turner wrote:
>
> > diff --git a/setup.c b/setup.c
> > index bd3a2cf..e2e1220 100644
> > --- a/setup.c
> > +++ b/setup.c
> > @@ -457,6 +457,10 @@ static int check_repository_format_gently(
Nobody reads this anymore, and they're not likely to; the
interesting thing is whether or not we passed
check_repository_format(), and possibly the individual
"extension" variables.
Signed-off-by: Jeff King
---
cache.h | 1 -
environment.c | 1 -
setup.c | 1 -
3 files changed, 3 del
Am 01.03.2016 um 15:13 schrieb Johannes Schindelin:
> The pthread_exit() function is not expected to return. Ever. On Windows,
> we call ExitThread() whose documentation claims: "This function does not
> return a value.":
Does this really mean that ExitThread() does not return ?
Just wondering...
As each constant is used in only one place, they are not
helping us avoid duplication. And they may be actively
misleading, as a version check is now much more complicated
than a simple integer comparison. The logic is in
verify_repository_format, and if you are thinking about
bumping the version,
Once upon a time, check_repository_format_gently would parse
the config with a single callback, and that callback would
set up a bunch of global variables. But now that we have
separate workdirs, we have to be more careful. Commit
31e26eb (setup.c: support multi-checkout repo setup,
2014-11-30) int
We check our templates to make sure they are from a
version of git we understand (otherwise we would init a
repository we cannot ourselves run in!). But our simple
integer check has fallen behind the times. Let's use the
helpers that setup.c provides to do it right.
Signed-off-by: Jeff King
---
I
When we want to know if we're in a git repository of
reasonable vintage, we can call check_repository_format_gently(),
which does three things:
1. Reads the config from the .git/config file.
2. Verifies that the version info we read is sane.
3. Writes some global variables based on this.
There's a chicken-and-egg problem with using the regular
git_config during the repository setup process. We get
around it here by using a special interface that lets us
specify the per-repo config, and avoid calling
git_pathdup().
But this interface doesn't actually make sense. It will look
in the
There are no more callers, and it's a rather confusing
interface. This could just be folded into
git_config_with_options(), but for the sake of readability,
we'll leave it as a separate (static) helper function.
Signed-off-by: Jeff King
---
Documentation/technical/api-config.txt | 7 ---
ca
The "shared_repository" config is loaded as part of
check_repository_format_version, but it's not quite like the
other values we check there. Something like
core.repositoryformatversion only makes sense in per-repo
config, but core.sharedrepository can be set in a per-user
config (e.g., to make all
It would be useful to control access to the global
shared_repository, so that we can lazily load its config.
The first step to doing so is to make sure all access
goes through a set of functions.
This step is purely mechanical, and should result in no
change of behavior.
Signed-off-by: Jeff King
This function's interface is rather enigmatic, so let's
document it further.
While we're here, let's also drop the return value. It will
always either be "0" or the function will die (consequently,
neither of its two callers bothered to check the return).
Signed-off-by: Jeff King
---
cache.h |
After the discussion in:
http://thread.gmane.org/gmane.comp.version-control.git/287949/focus=288002
I came up with this series to try to address some of the warts in
check_repository_format_gently().
I had hoped to come up with something very small that could go at the
front of the refs-backen
The pthread_exit() function is not expected to return. Ever. On Windows,
we call ExitThread() whose documentation claims: "This function does not
return a value.":
https://msdn.microsoft.com/en-us/library/windows/desktop/ms682659
Pointed out by Jeff King.
Signed-off-by: Johannes Schindel
Hi Peff,
On Tue, 1 Mar 2016, Jeff King wrote:
> On Tue, Mar 01, 2016 at 02:53:04PM +0100, Johannes Schindelin wrote:
>
> > The pthread_exit() function is not expected to return. Ever.
> >
> > Pointed out by Jeff King.
> >
> > Signed-off-by: Johannes Schindelin
> > ---
> > compat/win32/pthrea
On Tue, Mar 01, 2016 at 02:53:04PM +0100, Johannes Schindelin wrote:
> The pthread_exit() function is not expected to return. Ever.
>
> Pointed out by Jeff King.
>
> Signed-off-by: Johannes Schindelin
> ---
> compat/win32/pthread.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> d
The pthread_exit() function is not expected to return. Ever.
Pointed out by Jeff King.
Signed-off-by: Johannes Schindelin
---
compat/win32/pthread.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/win32/pthread.h b/compat/win32/pthread.h
index 20b35a2..148db60 100644
Hi Peff,
On Tue, 1 Mar 2016, Jeff King wrote:
> On Tue, Mar 01, 2016 at 06:49:43AM +0100, Torsten Bögershausen wrote:
>
> > However, suspecting jk/epipe-in-async, I don't know if we can do
> > something against this warning:
> >
> > CC run-command.o run-command.c: In function 'async_exit':
> >
On 03/01, Sidhant Sharma wrote:
>
> > If you use PARSE_OPT_HIDDEN, I think you don't need to specify a message.
> > Otherwise, the documentation only has value if it contains more than just
> > the option name, but that is the hard part if you're not familiar with the
> > code. The best place to
> If you use PARSE_OPT_HIDDEN, I think you don't need to specify a message.
> Otherwise, the documentation only has value if it contains more than just the
> option name, but that is the hard part if you're not familiar with the code.
> The best place to find documentation is in the history (gi
Hello,
using git 2.1.4 here, and it seems there is no option to bypass
pre-commit hooks while cherry-picking, while git commit provides a
--no-verify option. I ended up doing this to disable hooks while cherry
picking :
test -f "$GIT_DIR"/CHERRY_PICK_HEAD && exit 0
Wouldn't it be best t
From: Lars Schneider
Noticed-by: Eric Sunshine
Signed-off-by: Lars Schneider
---
Documentation/git-p4.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 738cfde..140fc12 100644
--- a/Documentation/git-p4.txt
+++ b/D
On 01 Mar 2016, at 11:49, larsxschnei...@gmail.com wrote:
> From: Lars Schneider
oops ... this should be "larsxschnei...@gmail.com"... sorry
- Lars
>
> Map a P4 user to a specific name and email address in Git with the
> "git-p4.mapUser" config. The config value must be a string adhering
> to
From: Lars Schneider
Map a P4 user to a specific name and email address in Git with the
"git-p4.mapUser" config. The config value must be a string adhering
to the format "p4user = First Lastname ".
Signed-off-by: Lars Schneider
---
diff to v1:
* use '=' instead of '->' to mimic SVN user mappi
On Tue, Mar 1, 2016 at 1:43 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>
> I'd really prefer to avoid any code churn on this file before the
> dust settles for David's and Michael's series (the former is in
> 'pu', the latter is not
On Tue, Mar 01, 2016 at 04:53:30PM +0700, Duy Nguyen wrote:
> > The basic strategy was to adapt the
> > existing "struct startup_info" to be available everywhere, and have
> > relevant bits of code assert() on it, or even behave differently (e.g.,
> > if some library code should do different thing
On Tue, Mar 1, 2016 at 3:35 PM, Jeff King wrote:
> On Mon, Feb 29, 2016 at 07:52:34PM -0500, David Turner wrote:
>
>> Usually, git calls some form of setup_git_directory at startup. But
>> sometimes, it doesn't. Usually, that's OK because it's not really
>> using the repository. But in some cas
On Mon, Feb 29, 2016 at 07:53:02PM -0500, David Turner wrote:
> diff --git a/setup.c b/setup.c
> index bd3a2cf..e2e1220 100644
> --- a/setup.c
> +++ b/setup.c
> @@ -457,6 +457,10 @@ static int check_repository_format_gently(const char
> *gitdir, int *nongit_ok)
> ret = -1;
> }
1 - 100 of 101 matches
Mail list logo
