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
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
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
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
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
> 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
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
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
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
> >
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
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
+ 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
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
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
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.
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
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);
> -
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
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
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
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
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
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
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
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
---
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
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
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:"
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
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:
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
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
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
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:
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
"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
> 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
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.":
>>
>>
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
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
> >
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
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
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"
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
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
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,
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"
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
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
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
> 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
>
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
>>
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
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
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
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 +
>
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
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
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
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
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
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
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,
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 *,
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
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
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
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
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
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)
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
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
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
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
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
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
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
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
> >
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
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
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
> 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
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
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
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
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
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
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
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.
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