hello!
i am a chinese.
i have some question for you ,i want to know how 'git clone'work,
it likes downloader? or other things. i think it'sdown speed is
heigher,so i email to you .
thanks ,and my english is so poor.:P
On Sat, Mar 31, 2018 at 11:17 AM, Thomas Gummerer wrote:
> This round should fix all the UI issues Eric found in the last round.
> The changes I made in a bit more detail:
>
> - added a new commit introducing a new hidden --show-new-head-line
> flag in 'git reset'. This is used to suppress the
On Sat, Mar 31, 2018 at 11:18 AM, Thomas Gummerer wrote:
> [...]
> Fix these inconsistencies, and no longer show the identifier by making
> the 'git reset --hard' call not print the "HEAD is now at ..." line
> using the newly introduced flag from the previous commit, and printing
> the message dir
The new bisect_regression script can be used to automatically bisect
performance regressions. It will pass the new bisect_run_script to
`git bisect run`.
Signed-off-by: Christian Couder
---
t/perf/bisect_regression | 73
t/perf/bisect_run_script | 47
This new option makes it possible to run perf tests as defined
in only one subsection of a config file.
Signed-off-by: Christian Couder
---
t/perf/run | 56 --
1 file changed, 46 insertions(+), 10 deletions(-)
diff --git a/t/perf/run b/t/perf/
This is a small patch series on top of cc/perf-aggregate-sort, which
is next, to add scripts that make it much easier to bisect performance
regressions.
For example if you ran perf test using the perf.conf config file that
contains a "with libpcre", then using:
$ ./aggregate.perl --subsection "wi
On Sun, Apr 8, 2018 at 5:35 AM, Christian Couder
wrote:
> This new option makes it possible to run perf tests as defined
> in only one subsection of a config file.
>
> Signed-off-by: Christian Couder
> ---
> diff --git a/t/perf/run b/t/perf/run
> @@ -1,21 +1,34 @@
> +while [ $# -gt 0 ]; do
I was
On Sat, Mar 31, 2018 at 11:18 AM, Thomas Gummerer wrote:
> [...]
> However we can do a little better than that, and check the branch out if
> it is not checked out anywhere else. This will help users who just want
> to check an existing branch out into a new worktree, and save a few
> keystrokes.
Hello,
is there a way to get remote url for the current branch? That is the
url that will be used when I call `git pull`. It doesn't seem to be a
particularly easy task.
Thank you!
clime
Derrick Stolee writes:
> From: Derrick Stolee
>
> Add Documentation/technical/commit-graph.txt with details of the planned
> commit graph feature, including future plans.
That's in my opinion a very good idea. It would help anyone trying to
add to and extend this feature.
> Signed-off-by: Der
On Sun, Apr 08 2018, Michal Novotny wrote:
> is there a way to get remote url for the current branch? That is the
> url that will be used when I call `git pull`. It doesn't seem to be a
> particularly easy task.
You'd do something like this (sans error checking):
git remote get-url $(git c
On Sun, Apr 08 2018, jiangwei zhao wrote:
> hello!
> i am a chinese.
> i have some question for you ,i want to know how 'git clone'work,
> it likes downloader? or other things. i think it'sdown speed is
> heigher,so i email to you .
> thanks ,and my english is so poor.:P
You will not get the
Derrick Stolee writes:
> +# Current graph structure:
> +#
> +# __M3___
> +# / | \
> +# 3 M1 5 M2 7
> +# |/ \|/ \|
> +# 246
> +# |___//
> +# 1
Good, so we are testing EDGE chunk, because the commit graph has octopus
merge in it (with more than two parents).
Do we need to tes
From: Jeff King
In preparation for callers constructing their own ref_array
structs, let's move our own internal push operation into its
own function.
While we're at it, we can replace REALLOC_ARRAY() with
ALLOC_GROW(), which should give the growth operation
amortized linear complexity (as oppos
Thanks for your very thorough review Eric! I think I address all the
points, but if I missed something please let me know.
On Sun, Apr 8, 2018 at 3:06 AM, Eric Sunshine wrote:
>
> You incorrectly dropped Peff's sign-off[1] when re-sending the patches
> he authored in the series. And, your sign-
From: Jeff King
Internally we store a "struct object_id", and all of our
callers have one to pass us. But we insist that they peel it
to its bare-sha1 hash, which we then hashcpy() into place.
Let's pass it around as an object_id, which future-proofs us
for a post-sha1 world.
Signed-off-by: Jeff
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.
Signed-off-by: Harald Nordgren
---
Notes:
Changes according to Eric Sunshine's code review
Documentation/git-ls-rem
From: Jeff King
We have a helper function to allocate ref_array_item
structs, but it only takes a subset of the possible fields
in the struct as initializers. We could have it accept an
argument for _every_ field, but that becomes a pain for the
fields which some callers don't want to set initial
Derrick Stolee writes:
[...]
> EXAMPLES
>
> @@ -45,6 +51,12 @@ EXAMPLES
> $ git commit-graph write
>
>
> +* Read basic information from the commit-graph file.
> ++
> +
> +$ git commit-g
Derrick Stolee writes:
> From: Derrick Stolee
>
> The commit graph feature is controlled by the new core.commitGraph config
> setting. This defaults to 0, so the feature is opt-in.
Nice. That's how bitmaps feature was introduced, I think. I guess that
in the future reading would be opt-out, i
Derrick Stolee writes:
> @@ -96,10 +101,12 @@ static int graph_write(int argc, const char **argv)
>builtin_commit_graph_write_options,
>builtin_commit_graph_write_usage, 0);
>
> + if (opts.stdin_packs && opts.stdin_commits)
> +
Hello,
Konstantin Ryabitsev writes:
> This is an entirely idle pondering kind of question, but I wanted to
> ask. I recently discovered that some edge providers are starting to
> offer systems with GPU cards in them -- primarily for clients that need
> to provide streaming video content, I guess
On 04/08, Eric Sunshine wrote:
> On Sat, Mar 31, 2018 at 11:17 AM, Thomas Gummerer
> wrote:
> > This round should fix all the UI issues Eric found in the last round.
> > The changes I made in a bit more detail:
> >
> > - added a new commit introducing a new hidden --show-new-head-line
> > flag
On 04/08, Eric Sunshine wrote:
> On Sat, Mar 31, 2018 at 11:18 AM, Thomas Gummerer
> wrote:
> > [...]
> > However we can do a little better than that, and check the branch out if
> > it is not checked out anywhere else. This will help users who just want
> > to check an existing branch out into
Adding external subcommands to Git is as easy as to put an executable
file git-foo into PATH. Packaging such subcommands for a Linux
distribution can be achieved by unpacking the executable into /usr/bin
of the user's system. Adding system-wide completion scripts for new
subcommands, however, can b
Adding external subcommands to Git is as easy as to put an executable
file git-foo into PATH. Packaging such subcommands for a Linux
distribution can be achieved by unpacking the executable into /usr/bin
of the user's system. Adding system-wide completion scripts for new
subcommands, however, can b
In this small patch I want to introduce a way to dynamically load completion
scripts for external subcommands.
A few years ago, you would put a completion script (which defines a Bash
function _git_foo for a custom git subcommand foo) into
/etc/bash_completion.d, or save it somewhere in your $H
Ah, sorry, please ignore this one.
Avarab,
I enabled GIT_TRACE, packet, etc. I could not make much sense of the
output. I downloaded git source and started looking at the code.
Yeah, kernel compilation with failovers worked on our filesystem. We
tried xfs test suite with failovers, it worked. Since it's failing
with open source NFS
Hi,
Immediately after a finished rebase, is it true that ORIG_HEAD points
to the previous tip of the branch?
So that `git reset --hard ORIG_HEAD` will cancel the rebase?
P.S. I'm asking because most of time that is so, but there is at least
one case when ORIG_HEAD breaks that assumption. Not sur
Hi, Eric,
First of, I already have Xcode installed along with the Developer Tools.
Second, here is the list of the different dylib files I found on my system:
MyMac:/ igorkorot$ find . -name libSystem.B.dylib
./Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iP
Harald Nordgren writes:
> +--sort=::
> + Sort based on the key given. Prefix `-` to sort in descending order
> + of the value. Supports "version:refname" or "v:refname" (tag names
> + are treated as versions). The "version:refname" sort order can also
> + be affected by the "versi
Eric,
Sorry for multiple e-mails. I'm just trying to go thru with this.
This is what I tried:
[code]
MyMac:git-2.17.0 igorkorot$ make configure
GIT_VERSION = 2.17.0
GEN configure
/bin/sh: autoconf: command not found
make: *** [configure] Error 127
MyMac:git-2.17.0 igorkorot$
[/code]
Does thi
Florian Gamböck writes:
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/completion/git-completion.bash
> index b09c8a236..e6114822c 100644
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -3096,12 +3096,20 @@ __git_main ()
>
Ilya Kantor writes:
> Immediately after a finished rebase, is it true that ORIG_HEAD points
> to the previous tip of the branch?
>
> So that `git reset --hard ORIG_HEAD` will cancel the rebase?
I wouldn't recommend people to depend on it; rather use "@{1}",
perhaps?
Before reflog was invented,
Yuki Kokubun writes:
> References: <1521996898-7052-1-git-send-email-orga.chem@gmail.com>
> Content-Type: text/plain
>
> Sorry, I forgot add a line of "Reviewed-by".
> I'm gonna send the fixed patch again.
Do not worry too much about this. Reviewed-by: added by patch
author is seen rather r
Johannes Schindelin writes:
>> Yes, it is a workaround. Making shell faster on windows would of
>> course be one possible solution to make t/t*.sh scripts go faster
>> ;-) Or update parts of t/t*.sh so that the equivalent test coverage
>> can be kept while running making them go faster on Windo
Stephon Harris writes:
> Fixes issue with seeing `sed: RE error: illegal byte sequence` when running
> git-completion.bash
> ---
> contrib/completion/git-completion.bash | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/contrib/completion/git-completion.bash
> b/contrib/
Jeff King writes:
> On Wed, Apr 04, 2018 at 07:59:12PM -0700, Taylor Blau wrote:
>
>> @@ -286,6 +288,16 @@ static int get_value(const char *key_, const char
>> *regex_)
>> config_with_options(collect_config, &values,
>> &given_config_source, &config_options);
>>
>
Jeff King writes:
> In preparation for callers constructing their own ref_array
> structs, let's move our own internal push operation into its
> own function.
>
> While we're at it, we can replace REALLOC_ARRAY() with
> ALLOC_GROW(), which should give the growth operation
> amortized linear compl
Jeff King writes:
> If I were doing it myself, I probably would have folded patches 1 and 3
> together. They are touching all the same spots, and it would be an error
> for any case converted in patch 1 to not get converted in patch 3. I'm
> assuming you caught them all due to Coccinelle, though
On Sun, Apr 8, 2018 at 6:37 PM, Igor Korot wrote:
> MyMac:git-2.17.0 igorkorot$ make configure
> GIT_VERSION = 2.17.0
> GEN configure
> /bin/sh: autoconf: command not found
> make: *** [configure] Error 127
>
> Does this mean that something is a miss?
That means that you don't have the Autoco
From: Jeff King
We have a helper function to allocate ref_array_item
structs, but it only takes a subset of the possible fields
in the struct as initializers. We could have it accept an
argument for _every_ field, but that becomes a pain for the
fields which some callers don't want to set initial
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.
Signed-off-by: Harald Nordgren
---
Notes:
Changes according to Junio Hamano's code review
Documentation/git-ls-remo
From: Jeff King
In preparation for callers constructing their own ref_array
structs, let's move our own internal push operation into its
own function.
While we're at it, we can replace REALLOC_ARRAY() with
ALLOC_GROW(), which should give the growth operation
amortized linear complexity (as oppos
From: Jeff King
Internally we store a "struct object_id", and all of our
callers have one to pass us. But we insist that they peel it
to its bare-sha1 hash, which we then hashcpy() into place.
Let's pass it around as an object_id, which future-proofs us
for a post-sha1 world.
Signed-off-by: Jeff
On Sun, Apr 8, 2018 at 7:55 PM, Igor Korot wrote:
> On Sun, Apr 8, 2018, 6:23 PM Eric Sunshine wrote:
>> And, as noted earlier, before running "make", you may need to create
>> config.mak to override some settings documented at the top of Makefile
>> (in particular, you may want to set NO_GETTEXT
On Mon, Apr 9, 2018 at 12:16 AM, Junio C Hamano wrote:
>
> I can connect "because it deals only with remotes" and "access to
> the object may fail", but I wonder if we can clarify the former a
> bit better to make it easier to understand for those who are not yet
> familiar with Git.
>
> Keys
On Sun, Apr 1, 2018 at 9:11 AM, Thomas Gummerer wrote:
> So while playing with it a bit more I found one case where the new UI
> is not ideal and a bit confusing. Namely when the new check out dwim
> kicks in, but there is already a file/directory at the path we're
> giving to 'git worktree add'.
On Sun, Apr 8, 2018 at 10:24 AM, Thomas Gummerer wrote:
> On 04/08, Eric Sunshine wrote:
>> On Sat, Mar 31, 2018 at 11:17 AM, Thomas Gummerer
>> wrote:
> Let me think through some of the cases here, of 'git worktre add
> ' with various flags and what the UI would be with
> that added:
>
> - n
Harald Nordgren writes:
>> It is not too big a deal, but I find that liberal sprinkling of
>> UNLEAK() is somewhat unsightly. From the code we leave with this
>> change, it is clear what we'd need to do when we make the code fully
>> leak-proof (i.e. we'd have a several lines to free resources h
Harald Nordgren writes:
> Create a '--sort' option for ls-remote, based on the one from
> for-each-ref. This e.g. allows ref names to be sorted by version
> semantics, so that v1.2 is sorted before v1.10.
>
> Signed-off-by: Harald Nordgren
> ---
Thanks.
> +--sort=::
> + Sort based on the k
From: Jeff King
Internally we store a "struct object_id", and all of our
callers have one to pass us. But we insist that they peel it
to its bare-sha1 hash, which we then hashcpy() into place.
Let's pass it around as an object_id, which future-proofs us
for a post-sha1 world.
Signed-off-by: Jeff
From: Jeff King
In preparation for callers constructing their own ref_array
structs, let's move our own internal push operation into its
own function.
While we're at it, we can replace REALLOC_ARRAY() with
ALLOC_GROW(), which should give the growth operation
amortized linear complexity (as oppos
From: Jeff King
We have a helper function to allocate ref_array_item
structs, but it only takes a subset of the possible fields
in the struct as initializers. We could have it accept an
argument for _every_ field, but that becomes a pain for the
fields which some callers don't want to set initial
Create a '--sort' option for ls-remote, based on the one from
for-each-ref. This e.g. allows ref names to be sorted by version
semantics, so that v1.2 is sorted before v1.10.
Signed-off-by: Harald Nordgren
---
Notes:
Changes according to Junio Hamano's code review (2)
Documentation/git-ls-
On Mon, Apr 9, 2018 at 2:56 AM, Junio C Hamano wrote:
>
> With the update since v12, I think "because `ls-remote` deals only
> with remotes," can be dropped entirely, and still convey what needs
> to be told: "Be aware some keys that needs access to objects that
> are not here won't work".
>
> Ins
Jeff King writes:
> To be honest, I don't know. Most of dir.c predates me, and I've tried to
> avoid looking at it too hard. But I had a vague recollection of it being
> "best effort", and this bit from cf424f5fd89b reinforces that:
>
> However, read_directory does not actually check against ou
Eric Wong writes:
> Ævar Arnfjörð Bjarmason wrote:
>> See https://public-inbox.org/git/86h8oobl36@phe.ftfl.ca/ for the
>> original report.
>
> Thanks for taking a look at this. Also https://bugs.debian.org/894997
>
>> --- a/perl/Git.pm
>> +++ b/perl/Git.pm
>> @@ -554,7 +554,7 @@ sub get_rec
Jeff King writes:
> On Fri, Apr 06, 2018 at 09:31:22PM +0200, Johannes Schindelin wrote:
>
>> In 0b294c0abf0 (make deleting a missing ref more quiet, 2008-07-08), we
>> added a test to verify that deleting an already-deleted ref does not
>> show an error.
>
> Amazing that it took this long to com
Lucas Werkmeister wrote:
> Since the --log-destination option was added in 0c591cacb ("daemon: add
> --log-destination=(stderr|syslog|none)", 2018-02-04) with the explicit
> goal of allowing logging to stderr when running in inetd mode, we should
> not always redirect stderr to /dev/null in inetd m
On Sun, Apr 8, 2018 at 6:16 PM, Junio C Hamano wrote:
> Harald Nordgren writes:
>> +--sort=::
>> + Sort based on the key given. [...]
>
> This is a tangent but I suspect that the description of --sort in
> git-for-each-ref documentation is wrong on the use of multiple
> options, or I am misre
Paul-Sebastian Ungureanu writes:
> Compared to 'test-chmtime -v +0 file' which prints the mtime and
> and the file name, 'test-chmtime --get file' displays only the mtime.
> If it is used in combination with (+|=|=+|=-|-)seconds, it changes
> and prints the new value.
>
> test-chmtime -v +0
Paul-Sebastian Ungureanu writes:
> - find .git/rr-cache/ -type f | xargs test-chmtime -172800 &&
> + test-chmtime -172800 $(find .git/rr-cache/ -type f) &&
You've sneaked this kind of rewrite in, as if you are testing to see
how careful the reviewers are ;-).
We often use "find piped to
On Mon, Mar 26, 2018 at 12:55 PM, Nguyễn Thái Ngọc Duy
wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/help.c b/help.c
> @@ -228,6 +228,21 @@ void list_common_cmds_help(void)
> +void list_all_cmds(void)
> +{
> + struct cmdnames main_cmds, other_cmds;
> + int i;
> +
>
On Mon, Apr 09, 2018 at 08:18:35AM +0900, Junio C Hamano wrote:
> Jeff King writes:
>
> > In preparation for callers constructing their own ref_array
> > structs, let's move our own internal push operation into its
> > own function.
> >
> > While we're at it, we can replace REALLOC_ARRAY() with
Ævar Arnfjörð Bjarmason writes:
>>
>> +perllibdir:
>> +@echo $(perllibdir_SQ)
This use of _SQ variant is fishy, isn't it? Judging from the output
of
$ git grep _SQ Makefile
e.g.
Makefile: $(INSTALL) $^ '$(DESTDIR_SQ)$(gitexec_instdir_SQ)'
Makefile: $(INSTALL) $^ '$(DESTD
On Mon, Mar 26, 2018 at 12:55 PM, Nguyễn Thái Ngọc Duy
wrote:
> common-cmds.h is used to extract the list of common commands (by
> group) and a one-line summary of each command. Some information is
> dropped, for example command category or summary of other commands.
> Update generate-cmdlist.sh t
On Mon, Mar 26, 2018 at 12:55 PM, Nguyễn Thái Ngọc Duy
wrote:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> diff --git a/help.c b/help.c
> @@ -282,6 +282,67 @@ void list_porcelain_cmds(void)
> +static const char *get_category_name(unsigned int category)
> +{
> + switch (category) {
> +
On Mon, Apr 9, 2018 at 12:59 AM, Eric Sunshine wrote:
> However, I'm concerned that this change may be going in the wrong
> direction. A line in "### command list" section looks like this:
>
> command-name category [deprecated] [common]
>
> Although we don't currently have any commands marked
On Mon, Mar 26, 2018 at 12:55 PM, Nguyễn Thái Ngọc Duy
wrote:
> This is pretty rough but I'd like to see how people feel about this
> first.
>
> I notice we have two places for command classification. One in
> command-list.txt, one in __git_list_porcelain_commands() in
> git-completion.bash. Peopl
71 matches
Mail list logo
