On Sun, Nov 26, 2017 at 12:46:12PM +0900, Junio C Hamano wrote:
> Max Kirillov writes:
> > +ssize_t git_env_ssize_t(const char *k, ssize_t val)
> > +{
> > + const char *v = getenv(k);
> > + if (v && !git_parse_ssize_t(v, &val))
> > + die("failed to parse %s", k);
> > + return val;
Thanks you very much:
I have QNAP NAS,
Finally I have installed QGit (from forum QNAP because you can't find
in app center) from here:
https://forum.qnap.com/viewtopic.php?f=320&t=109649
I used SSH for create a bare repository in the server side.
Once it was created i went to the local machine and
Junio C Hamano writes:
> Jeff King writes:
>
>> What I was trying to get at is that naming it "status --no-lock-index"
>> would not be the same thing (even though with the current implementation
>> it would behave the same). IOW, can we improve the documentation of
>> "status" to point to make i
Max Kirillov writes:
> I'm afraid I did not get the reasonsing and not fully the
> desired change. Is this http-backend code change (compared
> to the last patch) what you mean?
Exactly.
The fact that the parsed string happens to come from CONTENT_LENGTH
environment variable is http's busines
On 11/26, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > Of course that assumes that it's used directly, not in scripts, and
> > that users will actually read the output of the command when they
> > invoke it. Maybe these are not safe assumptions to make though, and
> > we'd rather not ha
US$25 Million Has Been Granted To You As A Donation Visit
www.bbc.co.uk/news/uk-england- 19254228 For Details Send Us Your Name, Home
Address And Phone Numbers,
text us at ( adrian.payment2...@yahoo.com ) For More Information.
Best Regard:
Mr. Adrian and Gillian Bayford
FUND DONATION US$25MILL
Hi Johannes,
On 25/11/2017 23:16, Johannes Schindelin wrote:
>
> > [ +Cc: Git for Windows mailing list ]
>
> I have no idea why it claimed that that group does not exist, the
> email address looks correct to me.
I suspected the culprit was me not being a member of the group, where
the group r
From: Torsten Bögershausen
When a text file had been commited with CRLF and the file is commited
again, the CRLF are kept if .gitattributs has "text=auto".
This is done by analyzing the content of the blob stored in the index:
If a '\r' is found, Git assumes that the blob was commited with CRLF.
On Sun, Nov 26, 2017 at 4:53 AM, Junio C Hamano wrote:
> Christian Couder writes:
>
>> On Mon, Nov 20, 2017 at 6:15 PM, Christian Couder
>> wrote:
>>> By default running `make install` in the root directory of the
>>> project will set TCLTK_PATH to `wish` and then go into the "git-gui"
>>> and "
On 26/11/17 14:00, Christian Couder wrote:
> On Sun, Nov 26, 2017 at 4:53 AM, Junio C Hamano wrote:
>> Christian Couder writes:
>>
>>> On Mon, Nov 20, 2017 at 6:15 PM, Christian Couder
>>> wrote:
By default running `make install` in the root directory of the
project will set TCLTK_PA
On Sun, Nov 26, 2017 at 6:43 PM, Ramsay Jones
wrote:
>
>
> On 26/11/17 14:00, Christian Couder wrote:
>> On Sun, Nov 26, 2017 at 4:53 AM, Junio C Hamano wrote:
>>> Christian Couder writes:
>>>
On Mon, Nov 20, 2017 at 6:15 PM, Christian Couder
wrote:
> By default running `make inst
On Tue, Nov 21, 2017 at 12:58:17AM +0100, Christian Couder wrote:
> > Can you say more about where this comes up?
>
> The original discussion is:
>
> https://public-inbox.org/git/b6b12040-100f-5965-6dfd-344c84ddd...@teddy.ch/
>
> and here are discussions related to version 1 of this patch:
>
>
On Sat, Nov 25, 2017 at 10:55:25PM +0100, Johannes Schindelin wrote:
> > Right, I went a little off track of your original point.
> >
> > What I was trying to get at is that naming it "status --no-lock-index"
> > would not be the same thing (even though with the current implementation
> > it woul
On Sun, Nov 26, 2017 at 12:32:13PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > What I was trying to get at is that naming it "status --no-lock-index"
> > would not be the same thing (even though with the current implementation
> > it would behave the same). IOW, can we improve the doc
v6:
Do not implement generic git_env_ssize_t(), instead export git_parse_ssize_t()
from config.c
and hardcode the rest.
Florian Manschwetus (1):
http-backend: respect CONTENT_LENGTH as specified by rfc3875
Max Kirillov (1):
t5560-http-backend-noserver.sh: add CONTENT_LENGTH cases
Makefile
From: Florian Manschwetus
From: Florian Manschwetus
Date: Wed, 30 Mar 2016 10:54:21 +0200
http-backend reads whole input until EOF. However, the RFC 3875 specifies
that a script must read only as many bytes as specified by CONTENT_LENGTH
environment variable. Web server may exercise the specifi
Add tests for cases:
* CONTENT_LENGTH is set, script's stdin has more data.
(Failure would make it read GIT_HTTP_MAX_REQUEST_BUFFER bytes from /dev/zero
and fail. It does not seem to cause any performance issues with the default
value of GIT_HTTP_MAX_REQUEST_BUFFER.)
* CONTENT_LENGTH is spec
On Sun, Nov 26, 2017 at 06:38:06PM +0900, Junio C Hamano wrote:
> Max Kirillov writes:
>> +static ssize_t env_content_length()
>
> We need s/length()/length(void)/; though.
thanks, fixed it
The previous rounds can be found at
https://public-inbox.org/git/20171112134305.3949-1-t.gumme...@gmail.com/,
https://public-inbox.org/git/20171118181103.28354-1-t.gumme...@gmail.com/,
https://public-inbox.org/git/20171118224706.13810-1-t.gumme...@gmail.com/ and
https://public-inbox.org/git/2017112
Some users might want to have the --guess-remote option introduced in
the previous commit on by default, so they don't have to type it out
every time they create a new worktree.
Add a config option worktree.guessRemote that allows users to configure
the default behaviour for themselves.
Signed-of
Currently 'git worktree add ', errors out when 'branch'
is not a local branch. It has no additional dwim'ing features that one
might expect.
Make it behave more like 'git checkout ' when the branch doesn't
exist locally, but a remote tracking branch uniquely matches the desired
branch name, i.e.
Currently 'git worktree add' is documented to take an optional
argument, which is checked out in the new worktree. However it is more
generally possible to use a commit-ish as the optional argument, and
check that out into the new worktree.
Document that this is a possibility, as new users of gi
Factor the functions out, so they can be re-used from other places. In
particular these functions will be re-used in builtin/worktree.c to make
git worktree add dwim more.
While there add some docs to the function.
Signed-off-by: Thomas Gummerer
---
Makefile | 1 +
builtin/checkout.
Currently 'git worktree add' sets up tracking branches if '' is
a remote tracking branch, and doesn't set them up otherwise, as is the
default for 'git branch'.
This may or may not be what the user wants. Allow overriding this
behaviour with a --[no-]track flag that gets passed through to 'git
br
Currently 'git worktree add ' creates a new branch named after the
basename of the , that matches the HEAD of whichever worktree we
were on when calling "git worktree add ".
It's sometimes useful to have 'git worktree add behave more like
the dwim machinery in 'git checkout ', i.e. check if the n
From: Gennady Kupava
- Do the check if the trace key is enabled sooner in call chain.
- Move just enough code from trace.c into trace.h header so all code
necessary to determine that trace is disabled could be inlined to
calling functions.
Signed-off-by: Gennady Kupava
---
trace.c | 3 +--
From: Gennady Kupava
Trace key normalization is not used, not strictly necessary,
complicates the code and would negatively affect compilation speed if
moved to header.
New trace_default_key key or existing separate marco could be used
instead of passing NULL as a key.
Signed-off-by: Gennady Ku
We generally no longer include copyright notices in new test scripts.
However t/README still mentions it as something to include at the top of
every new script.
Remove that mention as it's outdated.
Signed-off-by: Thomas Gummerer
---
I read through some parts of t/README, while working on the t
test_cmp_rev is a useful function that's used in quite a few test
scripts. It is however not documented in t/README. Document it.
Signed-off-by: Thomas Gummerer
---
t/README | 5 +
1 file changed, 5 insertions(+)
diff --git a/t/README b/t/README
index 448569b60e..e867d1f8bd 100644
--- a/t
On Sun, Nov 26, 2017 at 8:15 PM, Jeff King wrote:
> On Tue, Nov 21, 2017 at 12:58:17AM +0100, Christian Couder wrote:
>
>> > Can you say more about where this comes up?
>>
>> The original discussion is:
>>
>> https://public-inbox.org/git/b6b12040-100f-5965-6dfd-344c84ddd...@teddy.ch/
>>
>> and her
FROM: ANDREW LAWSON.
Dear Sir,
My name is Mr. Andrew Lawson. I work as a procurement assistant. I got your
contact details during my search for a reliable and neutral company or
individual to partner with in the area of investment.
I need your assistance to manage an investment fund in a pro
Hi Peff,
On Sun, 26 Nov 2017, Jeff King wrote:
> On Sat, Nov 25, 2017 at 10:55:25PM +0100, Johannes Schindelin wrote:
>
> > > Right, I went a little off track of your original point.
> > >
> > > What I was trying to get at is that naming it "status --no-lock-index"
> > > would not be the same t
On Sun, Nov 26, 2017 at 2:38 PM, Max Kirillov wrote:
> [...]
> Make http-backend read only CONTENT_LENGTH bytes, if it's defined, rather than
> the whole input until EOF. If the variable is not defined, keep older behavior
> of reading until EOF because it is used to support chunked transfer-encod
On Sun, Nov 26, 2017 at 2:38 PM, Max Kirillov wrote:
> Add tests for cases:
>
> * CONTENT_LENGTH is set, script's stdin has more data.
> (Failure would make it read GIT_HTTP_MAX_REQUEST_BUFFER bytes from /dev/zero
> and fail. It does not seem to cause any performance issues with the default
>
On Sun, Nov 26, 2017 at 05:18:55PM -0500, Eric Sunshine wrote:
> On Sun, Nov 26, 2017 at 2:38 PM, Max Kirillov wrote:
>> +int cmd_main(int argc, const char **argv)
>> +{
>> + if (argc == 2 && strcmp(argv[1], "(size_t)(-20)") == 0)
>> + printf("%zu", (ssize_t)(-20));
>> +
>> +
Schönen Tag,
Ich bin Herr Yuehan Pan, Direktor der Bank of China
Ich suche einen Manager / Investitionspartner, der mit mir für ein
gegenseitiges Geschäftsunternehmen arbeiten wird.
Bitte kontaktieren Sie mich in meiner privaten E-Mail für weitere Details.
E-Mail (yuehanpa...@gmail.com)
Ich w
Hi to all,
Here`s my humble attempt on (once more) scratching a use case which
seems to be desired occasionally through the years, obviously not
enough to be actually implemented yet, but might be worth some more
attention... :)
For the reference, some past mentions of (more or less) similar i
Finally, "git-commit--onto-parent.sh"[*1*] shows an initial script
version for you to examine, test out and hopefully comment on :)
Especially interesting part might be index-only three-way file merge,
through usage of "git-merge-one-file--cached" script. Of course, this
still only works for so
Original "git-merge-one-file" script is slightly tweaked here into
"git-merge-one-file--cached"[*1*] to allow (still trivial) _index-only_
three-way file merge, not touching files inside working tree.
Proof of concept, not thoroughly tested, original content left in,
commented out. Feel free to
On 26/11/2017 23:35, Igor Djordjevic wrote:
>
> This is what we end up with once "master" and topic branches are
> merged in merge commit M1 inside temporary "test" branch for further
> integration testing:
>
> (2)o---o---A (topicA)
> / \
> / M1 (tes
Max Kirillov writes:
> Add tests for cases:
>
> * CONTENT_LENGTH is set, script's stdin has more data.
> (Failure would make it read GIT_HTTP_MAX_REQUEST_BUFFER bytes from /dev/zero
> and fail. It does not seem to cause any performance issues with the default
> value of GIT_HTTP_MAX_REQUEST
Jeff King writes:
> I'm not sure I agree. Lockless writes are actually fine for the original
> use case of --no-optional-locks (which is a process for the same user
> that just happens to run in the background).
The phrase "lockless write" scares me---it sounds as if you
overwrite the index file
Jeff King writes:
> ...
> I think your patch does say "consider setting NO_TCLTK" in that case,
> which is an improvement. But it might be nicer still if it Just Worked
> (either because we don't do tcl/tk by default, or because we respect
> NO_GETTEXT in the gitk/git-gui Makefiles, or because ou
Michael Sloan writes:
> So what's the problem with this choice of environment variables?
> Well, the problem is that if PWD is changed during the execution of
> the script, then GIT_WORK_TREE and GIT_DIR will no longer work
> properly. For example, if the pre-commit hook is
>
> #!/bin/sh
>
gennady.kup...@gmail.com writes:
> From: Gennady Kupava
>
> - Do the check if the trace key is enabled sooner in call chain.
> - Move just enough code from trace.c into trace.h header so all code
> necessary to determine that trace is disabled could be inlined to
> calling functions.
Makes s
Junio C Hamano writes:
> gennady.kup...@gmail.com writes:
>
>> From: Gennady Kupava
>>
>> - Do the check if the trace key is enabled sooner in call chain.
>> - Move just enough code from trace.c into trace.h header so all code
>> necessary to determine that trace is disabled could be inlined t
mwnx writes:
> diff --git a/pretty.c b/pretty.c
> index 2f6b0ae6c..4c70bad45 100644
> --- a/pretty.c
> +++ b/pretty.c
> @@ -1021,7 +1021,7 @@ static size_t parse_padding_placeholder(struct strbuf
> *sb,
> const char *end = start + strcspn(start, ",)");
> char *next;
>
On Sun, Nov 26, 2017 at 5:16 PM, Junio C Hamano wrote:
> Michael Sloan writes:
>
>> So what's the problem with this choice of environment variables?
>> Well, the problem is that if PWD is changed during the execution of
>> the script, then GIT_WORK_TREE and GIT_DIR will no longer work
>> properly
[second try, now with text format]
Thanks a lot for the reviews. Replying to both.
If I send a follow up, I'll fix the commit description and the help
string, remove the shorthand -M, write a more sensible test.
2017-11-23 14:24 GMT-05:00 Eric Sunshine :
>> diff --git a/Documentation/git-grep.t
Marc-Antoine Ruel writes:
> [second try, now with text format]
>
> Thanks a lot for the reviews. Replying to both.
>
> If I send a follow up, I'll fix the commit description and the help
> string, remove the shorthand -M, write a more sensible test.
>
> ...
>
> Thanks for the thoughtful analysis.
Junio C Hamano writes:
> Just in case others notice style and whitespace issues, I've applied
> the following to fix them, so there is no need to reroll only to fix
> these.
> ...
> -inline int trace_pass_fl(struct trace_key *key) {
> +inline int trace_pass_fl(struct trace_key *key)
> +{
>
Elijah Newren writes:
> In commit ae352c7f3 (merge-recursive.c: fix case-changing merge bug,
> 2014-05-01), it was observed that removing files could be problematic on
> case insensitive file systems, because we could end up removing files
> that differed in case only rather than deleting the int
To recap (other than the typofix in the proposed log message), here
is what I would have as SQUASH??? on top of (or interspersed with)
v6.
Thanks.
diff --git a/http-backend.c b/http-backend.c
index 69570d16e7..2268d65731 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -324,10 +324,9 @@ static
Do not call prepare_packed_git for every refs.
In fetch-pack, git list ups entries in .git/objects/pack
directory for each refs.
Such behavior makes git fetch-pack slow for the repository having the
large number of refs, especially for windows.
For chromium repository, having more than 30 remo
Junio C Hamano writes:
> Perhaps the "else" part of the above should become a bit more
> careful, something along the lines of...
>
> else
> MSGFMT ?= msgfmt
> - ifneq ($(shell $(MSGFMT) --tcl -l C -d . /dev/null 2>/dev/null;
> echo $$?),0)
> - MSGFMT
Takuto Ikuta writes:
> diff --git a/fetch-pack.c b/fetch-pack.c
> index 008b25d3db087..0184584e80599 100644
> --- a/fetch-pack.c
> +++ b/fetch-pack.c
> @@ -716,7 +716,7 @@ static int everything_local(struct fetch_pack_args *args,
> for (ref = *refs; ref; ref = ref->next) {
> s
On Mon, Nov 27, 2017 at 01:31:13PM +0900, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > Perhaps the "else" part of the above should become a bit more
> > careful, something along the lines of...
> >
> > else
> > MSGFMT ?= msgfmt
> > - ifneq ($(shell $(MSGFMT) --t
On Mon, Nov 27, 2017 at 01:35:35PM +0900, Junio C Hamano wrote:
> Takuto Ikuta writes:
>
> > diff --git a/fetch-pack.c b/fetch-pack.c
> > index 008b25d3db087..0184584e80599 100644
> > --- a/fetch-pack.c
> > +++ b/fetch-pack.c
> > @@ -716,7 +716,7 @@ static int everything_local(struct fetch_pack_
On Sun, Nov 26, 2017 at 06:35:56PM +0900, Junio C Hamano wrote:
> Having a large picture option like "--read-only" instead of ending
> up with dozens of "we implemented a knob to tweak only this little
> piece, and here is an option to trigger it" would help users in the
> long run, but we traditi
Jeff King writes:
>> cf.
>> https://public-inbox.org/git/20171120202920.7ppcwmzkxifyw...@sigill.intra.peff.net/
>
> It's funny that we'd get two patches so close together. AFAIK the
> slowness here has been with us for years, and I just happened to
> investigate it recently.
>
>> The 5-patch ser
Make sure the todo list ends up using single-letter command
abbreviations when the rebase.abbreviateCommands is enabled.
This configuration options should not change anything else.
Signed-off-by: Liam Beguin
---
t/t3404-rebase-interactive.sh | 32
1 file changed,
Move all rebase.* configuration variables to a separate file in order to
remove duplicates, and include it in config.txt and git-rebase.txt. The
new descriptions are mostly taken from config.txt as they are more
verbose.
Signed-off-by: Liam Beguin
---
Documentation/config.txt| 31 +-
Use "todo list" instead of "instruction list" or "todo-list" to
reduce further confusion regarding the name of this script.
Signed-off-by: Liam Beguin
---
Documentation/rebase-config.txt | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/Documentation/rebase-config.txt b/Doc
Recent work on `git-rebase--interactive` aim to convert shell code to C.
Even if this is most likely not a big performance enhacement, let's
convert it too since a comming change to abbreviate command names requires
it to be updated.
Signed-off-by: Liam Beguin
---
builtin/rebase--helper.c | 7
`git rebase -i` already know how to interpret single-letter command
names. Teach it to generate the todo list with these same abbreviated
names.
Based-on-patch-by: Johannes Schindelin
Signed-off-by: Liam Beguin
---
Documentation/rebase-config.txt | 19 +++
builtin/rebase--helper.c
Hi everyone,
This series is a respin of something [1] I sent a few months ago. This
time, instead of shell, It's based on top of the C implementation of the
interactive rebase. I've also tried to address the comments that were
left in the last thread.
This series will add the 'rebase.abbreviateCo
Jeff King writes:
> I actually consider "--no-optional-locks" to be such an aspirational
> feature. I didn't go digging for other cases (though I'm fairly certain
> that "diff" has one), but hoped to leave it for further bug reports ("I
> used the option, ran command X, and saw lock contention").
On Mon, Nov 27, 2017 at 01:56:41PM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I actually consider "--no-optional-locks" to be such an aspirational
> > feature. I didn't go digging for other cases (though I'm fairly certain
> > that "diff" has one), but hoped to leave it for further b
2017-11-27 13:53 GMT+09:00 Junio C Hamano :
> Jeff King writes:
>
>>> cf.
>>> https://public-inbox.org/git/20171120202920.7ppcwmzkxifyw...@sigill.intra.peff.net/
>>
>> It's funny that we'd get two patches so close together. AFAIK the
>> slowness here has been with us for years, and I just happene
On Mon, Nov 27, 2017 at 01:53:34PM +0900, Junio C Hamano wrote:
> > I'd be curious if the 5th patch there provides an additional speedup for
> > Takuto's case.
>
> Indeed, it is a very good point.
>
> IIUC, the 5th one is about fetching tons of refs that you have never
> seen, right? If a repos
Liam Beguin writes:
> diff --git a/sequencer.c b/sequencer.c
> index fa94ed652d2c..810b7850748e 100644
> --- a/sequencer.c
> +++ b/sequencer.c
> @@ -2492,6 +2492,52 @@ int sequencer_make_script(int keep_empty, FILE *out,
> return 0;
> }
>
> +int add_exec_commands(const char *command)
> +
Liam Beguin writes:
> if (command == MAKE_SCRIPT && argc > 1)
> - return !!sequencer_make_script(keep_empty, stdout, argc, argv);
> + return !!sequencer_make_script(keep_empty, abbreviate_commands,
> +stdout, argc, argv);
Liam Beguin writes:
> Liam Beguin (5):
> Documentation: move rebase.* configs to new file
> Documentation: use preferred name for the 'todo list' script
> rebase -i: add exec commands via the rebase--helper
> rebase -i: learn to abbreviate command names
> t3404: add test case for abbrev
Jeff King wrote:
Yeah, this side-steps the "other half" of the issue that Christian's
patch addresses, which seems like the more controversial part (I don't
have a strong opinion myself, though).
I don't either. The general motivation there, as far as I understand,
is that it's undesirable t
On Sun, Nov 26, 2017 at 10:55:01PM +0100, Johannes Schindelin wrote:
> > I remain unconvinced that we have actually uncovered a serious problem.
>
> You did not. A colleague of mine did. And it was a problem in Git for
> Windows only, caused by the changes necessitated by yours (which even used
>
Liam Beguin writes:
> Make sure the todo list ends up using single-letter command
> abbreviations when the rebase.abbreviateCommands is enabled.
> This configuration options should not change anything else.
>
> Signed-off-by: Liam Beguin
> ---
> t/t3404-rebase-interactive.sh | 32 ++
Jeff King writes:
> Again, maybe the bit above explains my viewpoint a bit more. I'm
> certainly sympathetic to the pain of upstreaming.
>
> I do disagree with the "no good reason" for this particular patch.
>
> Certainly you should feel free to present your hunches. I'd expect you
> to as part o
Jeff King writes:
> On Mon, Nov 27, 2017 at 12:24:43AM -0500, Jeff King wrote:
>
>> > If people have to ask on the mailing list even after reading the man
>> > pages, that's a strong indicator that we could do better.
>>
>> Sure. That's why I suggested improving the documentation in my last
>> e
On Mon, Nov 27, 2017 at 12:24:43AM -0500, Jeff King wrote:
> > If people have to ask on the mailing list even after reading the man
> > pages, that's a strong indicator that we could do better.
>
> Sure. That's why I suggested improving the documentation in my last
> email. But in all the discuss
On Mon, Nov 27, 2017 at 09:47:20AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > I'm not sure I agree. Lockless writes are actually fine for the original
> > use case of --no-optional-locks (which is a process for the same user
> > that just happens to run in the background).
>
> The p
Thomas Gummerer writes:
> Currently 'git worktree add ' creates a new branch named after the
> basename of the , that matches the HEAD of whichever worktree we
> were on when calling "git worktree add ".
>
> It's sometimes useful to have 'git worktree add behave more like
> the dwim machinery in
Thomas Gummerer writes:
> +worktree.guessRemote::
> + With `add`, if no branch argument, and neither of `-b` nor
> + `-B` nor `--detach` are given, the command defaults to
> + creating a new branch from HEAD. If `worktree.guessRemote` is
> + set to true, `worktree add` tries to f
82 matches
Mail list logo
