> Right now, you have some choices:
> • Volunteer to implement reftable.
> • Since you're on Windows 10, set your Git repository directory as
> case-sensitive.
> • Use Windows Subsystem for Linux, which is case sensitive and creates
> directories with that flag (even on NTFS), to do your i
wuzhouhui writes:
> I want to know how to display logs between a revision range (both
> start and end are inclusive). I searched it and only found[1],
> which doesn't resolve my problem completely, because
>
> git log ..
>
> doesn't contains the log of .
$ git log maint --not v2.20.0^@
gives
On Mon, Mar 4, 2019 at 2:43 PM Junio C Hamano wrote:
>
> Umang Parmar writes:
>
> > I am interested in micro project "Add configuration options for
> > some commonly used command-line”. So can you point me out to
> > implementations of some current commands which have configuration
> > options an
Umang Parmar writes:
> I am interested in micro project "Add configuration options for
> some commonly used command-line”. So can you point me out to
> implementations of some current commands which have configuration
> options and also for which command to add config options.
It is not a homewo
> -Original Messages-
> From: wuzhouhui
> Sent Time: 2019-03-04 15:28:13 (Monday)
> To: git@vger.kernel.org
> Cc:
> Subject: Git log print commits between a revision range (inclusive)
>
> Hi,
>
> I want to know how to display logs between a revision range (both
> start and end are inclu
Hi,
I want to know how to display logs between a revision range (both
start and end are inclusive). I searched it and only found[1],
which doesn't resolve my problem completely, because
git log ..
doesn't contains the log of . So, how to display
logs between a revision range that both start an
Hello everyone,
I am interested in micro project "Add configuration options for some commonly
used command-line”. So can you point me out to implementations of some current
commands which have configuration options and also for which command to add
config options.
Thanks,
Umang
Junio C Hamano writes:
> Jeff King writes:
>
>> I'm not sure I agree. Colors have always been special, and
>> "--type=color" was advertised as a replacement for "--get-color". And
>> "--get-color" never output the newline.
>
> OK, that part of the motivation I completely missed. If end-users
>
Jeff King writes:
> I'm not sure I agree. Colors have always been special, and
> "--type=color" was advertised as a replacement for "--get-color". And
> "--get-color" never output the newline.
OK, that part of the motivation I completely missed. If end-users
and scripters are happy with the beh
Rohit Ashiwal writes:
> Replace leading spaces with tabs
> Place title on the same line as function
>
> The previous code of `t3600-rm.sh` had a mixed use of tabs and spaces with
> instance of `not-so-recommended` way of writing `if-then` statement, also
> `titles` were not on the same line as th
On Sun, Mar 3, 2019 at 10:22 PM Junio C Hamano wrote:
> Eric Sunshine writes:
> > On Sun, Mar 3, 2019 at 9:45 AM Johannes Schindelin via GitGitGadget
> > wrote:
> >> ---stress=::
> >
> > Shouldn't the "--stress=" line be removed?
>
> Eyes can easily be tricked by the patch format, but the above
Jonathan Tan writes:
>> Thanks for fixing it.
>>
>> Is there a particular patch this should be squashed into, or does it
>> stand alone? It the latter, mind writing a commit message for it?
>
> Not sure if I'm using "fixup" correctly in the subject, but this is
> meant to be squashed onto the t
Rohit Ashiwal writes:
> test-lib-functions: add a helper function that checks for a file and that
> the file is not empty. The helper function will provide better error message
> in case of failure and improve readability
Avoid making the log message into an enumerated list, when there
aren't th
Eric Sunshine writes:
> On Sun, Mar 3, 2019 at 9:45 AM Johannes Schindelin via GitGitGadget
> wrote:
>> [...]
>> Let's introduce a separate option for that, whose name makes it more
>> obvious what it is about, and let --stress= error out with a helpful
>> suggestion about the two options tha co
Jeff King writes:
> ... But by dying immediately, we never actually
> read the ERR packet and report its content to the user. This is a (racy)
> problem on all platforms.
Yeah, I do not think of a good solution for it (nor I am not
convinced that it is worth fixing, to be honest. The cable may
Replace `test -(d|f|e|s)` calls in `t3600-rm.sh`.
Previously we were using `test -(d|f|e|s)` to verify the presence of a
directory/file, but we already have helper functions, viz, `test_path_is_dir`,
`test_path_is_file`, `test_path_is_missing` and `test_file_not_empty`
with better functionality.
Replace leading spaces with tabs
Place title on the same line as function
The previous code of `t3600-rm.sh` had a mixed use of tabs and spaces with
instance of `not-so-recommended` way of writing `if-then` statement, also
`titles` were not on the same line as the function `test_expect_success`,
r
test-lib-functions: add a helper function that checks for a file and that
the file is not empty. The helper function will provide better error message
in case of failure and improve readability
The function `test_file_not_empty`, first checks if a file is provided,
if it is not then an error messa
This patch ultimately aims to replace `test -(d|f|e|s)` calls in t3600-rm.sh
Previously we were using these to verify the presence of diretory/file, but
we already have helper functions, viz, `test_path_is_dir`, `test_path_is_file`,
`test_path_is_missing` and `test_file_not_empty` with better funct
The 'hdr-check' target has proved to be costly for some developers and
platforms, depending on the configuration, even when not using this
target. In part, this is due to the use of $(FIND) in the definition
of the $(LIB_H) variable. This effectively reverts commit ebb7baf02f
("Makefile: add a hd
On 03/03/2019 17:19, Jeff King wrote:
> On Sat, Mar 02, 2019 at 09:05:24PM +0100, Johannes Schindelin wrote:
>
>>> That seems reasonable (regardless of whether it is in a script or in the
>>> Makefile). Another option is to use -maxdepth, but that involves
>>> guessing how deep people might act
Hi Christian,
Le 03/03/2019 à 20:33, Christian Couder a écrit :
> On Fri, Mar 1, 2019 at 7:11 PM Alban Gruin wrote:
>>
>> A ref may not be the descendant of all of the commits mentionned in
>> stdin. In this case, we want to avoid naming its parents.
>
> Properly speaking a ref usually just poi
Rather than parse options manually, which is both difficult to
read and error prone, parse options supplied to commit-tree
using the parse-options api.
It was discovered that the --no-gpg-sign option was documented
but not implemented in commit 70ddbd7767 (commit-tree: add missing
--gpg-sign flag,
On Sun, Mar 3, 2019 at 8:33 PM Christian Couder
wrote:
>
> On Fri, Mar 1, 2019 at 7:11 PM Alban Gruin wrote:
> >
> > A ref may not be the descendant of all of the commits mentionned in
> > stdin. In this case, we want to avoid naming its parents.
>
> Properly speaking a ref usually just points t
On Fri, Mar 1, 2019 at 7:11 PM Alban Gruin wrote:
>
> A ref may not be the descendant of all of the commits mentionned in
> stdin. In this case, we want to avoid naming its parents.
Properly speaking a ref usually just points to a commit. It is not a
parent or a descendant of any commit.
Also i
"corentin bompard" wrote:
> Updating the documentation to use monospace on URLs and pathnames because it
> makes more sense
We usually write commit message with an imperative tone, eg. "Update
documentation", not "Updating documentation". Also, the period (.) is
missing at the end of the sentenc
Hi Junio
On 03/03/2019 01:35, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> Thanks for explaining, it all makes sense to me now
>
> It would be necessary to make sure that it all makes sense to all
> future readers. Are they patches good enough as-is for that, or do
> they need some update
On Fri, Feb 22, 2019 at 7:19 AM Jeff King wrote:
>
> On Thu, Feb 21, 2019 at 01:39:46PM -0800, Junio C Hamano wrote:
> > At the end of the bisection session, bisect.c::show_diff_tree() is
> > called on that "culprit" commit. Is it possible that 3a9388ee is a
> > simple and trivial merge that doe
On Sat, Feb 23, 2019 at 2:44 PM Jeff King wrote:
>
> On Fri, Feb 22, 2019 at 09:49:44AM -0800, Junio C Hamano wrote:
>
> > > If we do care about the change in exit code from bisect, then it
> > > probably does make sense to go with an external process. Then it can
> > > happily die on the corrupt
On Fri, Feb 22, 2019 at 7:21 AM Jeff King wrote:
>
> When we run our internal diff-tree to show the bisected commit, we call
> init_revisions(), then load config, then setup_revisions(). But that
> order is wrong: we copy the configured defaults into the rev_info struct
> during the init_revisions
On Sun, Mar 03, 2019 at 06:44:55AM -0800, Johannes Schindelin via GitGitGadget
wrote:
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index ab7f27ec6a..6e557982a2 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -142,10 +142,16 @@ do
> --stress)
> stress=t ;;
> --s
On Sun, Mar 03, 2019 at 10:18:11AM +0900, Junio C Hamano wrote:
> An interesting aspect of the above is that this is *NOT* limited to
> colors. Regardless of the type you are reading, be it an int or a
> bool, VAR=$(git config ...) will strip the trailing LF, and existing
> scripts people have do
On Sat, Mar 02, 2019 at 09:25:28PM +0100, Johannes Schindelin wrote:
> > This bug has survived because there was never a test that would have
> > caught it. The old test used 'test_decode_color', which checks that its
> > input begins with a color, but stops parsing once it has parsed a single
> >
On Sat, Mar 02, 2019 at 09:05:24PM +0100, Johannes Schindelin wrote:
> > That seems reasonable (regardless of whether it is in a script or in the
> > Makefile). Another option is to use -maxdepth, but that involves
> > guessing how deep people might actually put header files.
>
> It would also fa
It was reported by Nazri Ramliy that ORIG_HEAD was set incorrectly again,
this time caused by the shortcut to call git am directly, without detouring
to a Unix shell script.
Patch 2/4 might look like something completely unrelated, but without it,
the update to HEAD might use an incorrect reflog m
From: Johannes Schindelin
By mistake, we used the reflog intended for ORIG_HEAD.
Signed-off-by: Johannes Schindelin
---
builtin/rebase.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/rebase.c b/builtin/rebase.c
index 813ec284ca..aa469ec964 100644
--- a/builtin/reb
From: Johannes Schindelin
The ORIG_HEAD pseudo ref is supposed to refer to the original,
pre-rebase state after a successful rebase. Let's add a regression test
to prove that this regressed: With GIT_TEST_REBASE_USE_BUILTIN=false,
this test case passes, with GIT_TEST_REBASE_USE_BUILTIN=true (or u
From: Johannes Schindelin
Technically, the scripted version set ORIG_HEAD only in two spots (which
really could have been one, because it called `git checkout $onto^0` to
start the rebase and also if it could take a shortcut, and in both cases
it called `git update-ref $orig_head`).
Practically,
From: Johannes Schindelin
In the case that the rebase boils down to a fast-forward, the built-in
rebase reset the working tree twice: once to start the rebase at `onto`,
then realizing that the original (pre-rebase) HEAD was an ancestor and
we basically already fast-forwarded to the post-rebase H
On Sat, Mar 02, 2019 at 08:57:57PM +0100, Johannes Schindelin wrote:
> Hi Peff,
>
> On Fri, 1 Mar 2019, Jeff King wrote:
>
> > On Fri, Mar 01, 2019 at 04:36:19PM -0500, Jeff King wrote:
> >
> > > > This has one notable consequence: we no longer include
> > > > `command-list.h` in `LIB_H`, as it
Hi Junio,
On Sun, 3 Mar 2019, Junio C Hamano wrote:
> Phillip Wood writes:
>
> > Thanks for explaining, it all makes sense to me now
>
> It would be necessary to make sure that it all makes sense to all
> future readers. Are they patches good enough as-is for that, or do
> they need some upda
On Sat, Mar 02, 2019 at 08:54:55PM +0100, Johannes Schindelin wrote:
> On Fri, 1 Mar 2019, Jeff King wrote:
>
> > On Fri, Mar 01, 2019 at 04:54:15PM -0500, Jeff King wrote:
> >
> > > The one thing we do lose, though, is make's parallelization. It would
> > > probably be possible to actually shov
On Sat, Mar 02, 2019 at 05:07:04AM +0100, SZEDER Gábor wrote:
> The completion script used to cache the list of porcelain commands,
> but then Duy came along and removed it in 3301d36b29 (completion: add
> and use --list-cmds=alias, 2018-05-20).
> [...]
Thanks for this summary.
Just for the reco
The default SIGPIPE behavior can be useful for a command that generates
a lot of output: if the receiver of our output goes away, we'll be
notified asynchronously to stop generating it (typically by killing the
program).
But for a command like fetch, which is primarily concerned with
receiving dat
The write_or_die() function has one quirk that a caller might not
expect: when it sees EPIPE from the write() call, it translates that
into a death by SIGPIPE. This doesn't change the overall behavior (the
program exits either way), but it does potentially confuse test scripts
looking for a non-sig
On Sat, Mar 02, 2019 at 10:21:00PM +0100, Johannes Schindelin wrote:
> Do you want to turn these two patches into a proper patch series?
> Otherwise I can take care of it, probably this Monday or Tuesday.
Here they are. The old email sending the first one actually had a typo
(it sent "" inste
On Sun, Mar 3, 2019 at 11:41 AM Corentin BOMPARD
wrote:
> Updating the documentation to use monospace on URLs and pathnames because it
> makes more sense
>
> Signed-off-by: Corentin BOMPARD
> Signed-off-by: Nathan BERBEZIER
> Signed-off-by: Pablo CHABANNE
> ---
> diff --git a/Documentation/git
Updating the documentation to use monospace on URLs and pathnames because it
makes more sense
Signed-off-by: Corentin BOMPARD
Signed-off-by: Nathan BERBEZIER
Signed-off-by: Pablo CHABANNE
---
Changes: Dropped modifications on refs
Documentation/SubmittingPatches| 6 ++--
On 03/03, Rohit Ashiwal wrote:
> On 2019-03-03 13:33 UTC Junio C Hamano wrote:
>
> > test -s makes sure is file; if it is not a file, then
> > it won't yield true.
>
> > On 2019-03-03 13:20 UTC Rohit Ashiwal wrote:
> > > test_path_is_file "$1" &&
> > > if ! test -s "$1"
>
> According to th
On 03/03, Duy Nguyen wrote:
> On Sat, Mar 2, 2019 at 10:09 PM Thomas Gummerer wrote:
> > I'm not very familiar with what's required here, but reading the above
> > makes me think it's likely too much for a GSoC project. I think I'd
> > be happy with a project that declares removing the global var
On Tue, Feb 26, 2019 at 04:01:01PM -0500, Jeff King wrote:
> On Tue, Feb 26, 2019 at 08:39:12PM +0100, SZEDER Gábor wrote:
>
> > > > I didn't find this to be an issue, but because of functions like
> > > > 'test_seq' and 'test_must_fail' I've thought about suppressing '-x'
> > > > output for test
Hi,
On Sun, 3 Mar 2019, Junio C Hamano wrote:
> "Johannes Schindelin via GitGitGadget"
> writes:
>
> > From: Johannes Schindelin
> >
> > This fixes an issue pointed out by clang.
> >
> > Signed-off-by: Johannes Schindelin
> > ---
> > upload-pack.c | 2 +-
> > 1 file changed, 1 insertion(+),
On Sun, Mar 3, 2019 at 9:45 AM Johannes Schindelin via GitGitGadget
wrote:
> [...]
> Let's introduce a separate option for that, whose name makes it more
> obvious what it is about, and let --stress= error out with a helpful
> suggestion about the two options tha could possibly have been meant.
>
Hi Junio,
On Sun, 3 Mar 2019, Junio C Hamano wrote:
> Jeff King writes:
>
> > But for git-fetch, our primary purpose is receiving data and writing it
> > to disk. We should be checking all of our write()s already, and SIGPIPE
> > is just confusing.
>
> Yup, sounds like a very sensible argument
Hi,
On Sun, 3 Mar 2019, SZEDER Gábor wrote:
> On Sat, Mar 02, 2019 at 01:19:44PM -0800, Johannes Schindelin via
> GitGitGadget wrote:
> > The --stress option currently accepts an argument, but it is confusing
> > to at least this user that the argument does not define the maximal
> > number of s
From: Johannes Schindelin
It does not make much sense that running a test with
--stress-limit= seemingly ignores that option because it does not
stress test at all.
Signed-off-by: Johannes Schindelin
---
t/README | 2 +-
t/test-lib.sh | 1 +
2 files changed, 2 insertions(+), 1 deletion(-)
From: Johannes Schindelin
The --stress option currently accepts an argument, but it is confusing
to at least this user that the argument does not define the maximal
number of stress iterations, but instead the number of jobs to run in
parallel per stress iteration.
Let's introduce a separate opt
If my mistake using --stress= instead of --stress-limit= is any indication,
then the current options are very confusing.
This is my attempt at making them less confusing.
Changes since v1:
* Now the patches actually adjust the documentation according to the
changes ;-)
Johannes Schindelin (
On Sat, Mar 02, 2019 at 01:19:44PM -0800, Johannes Schindelin via GitGitGadget
wrote:
> The --stress option currently accepts an argument, but it is confusing
> to at least this user that the argument does not define the maximal
> number of stress iterations, but instead the number of jobs to run
I agree to all the points that you mentioned.
On 2019-03-03 13:30 UTC Junio C Hamano wrote:
> We prefer "test ..." over "[ ... ]" (Documentation/CodingGuidelines).
At first I thought this should go in [PATCH 3/3] but now I think this is
its real place.
Thanks
Rohit
On 2019-03-03 13:33 UTC Junio C Hamano wrote:
> test -s makes sure is file; if it is not a file, then
> it won't yield true.
> On 2019-03-03 13:20 UTC Rohit Ashiwal wrote:
> > test_path_is_file "$1" &&
> > if ! test -s "$1"
According to the conditional if the path is not a file then we w
Rohit Ashiwal writes:
> Just to be clear of what caused the error:
> 1. Path not being file, or
> 2. File not being empty
> I am checking for both.
test -s makes sure is file; if it is not a file, then
it won't yield true.
So why do you need to say test_path_is_file yourself, if y
Rohit Ashiwal writes:
> Subject: Re: [PATCH 3/3] t3600: use helper functions from test-lib-functions
There are tons of helpers in that lib.
> Replace `test -(d|f|e|s)` calls in `t3600-rm.sh`.
This one gives more useful information than the patch title.
Perhaps
Subject: [PATCH 3/3] t3600: use
Rohit Ashiwal writes:
> Subject: Re: [PATCH 2/3] t3600: refactor code according to contemporary
> guidelines
Please do not overuse/abuse the verb "refactor" like this. What the
patch does is only reformat---it does not do common "refactoring"
transformations like factoring out common/duplicate
Hey Junio
On 2019-03-03 13:20 UTC Junio C Hamano wrote:
> s/Add/add/. Strictly speaking, you do not need to say "new", if you
> are already saying "add", then that's redundant.
Oh, my mistake, I will change in coming revisions.
> "test -s " is true if resolves to an existing directory
> entr
Rohit Ashiwal writes:
> Subject: Re: [PATCH 1/3] test functions: Add new function
> `test_file_not_empty`
s/Add/add/. Strictly speaking, you do not need to say "new", if you
are already saying "add", then that's redundant.
> test-lib-functions: add a helper function that checks for a file and
Micha Nelissen writes:
> Modifies the topo-order code to keep track of the first child,
> using a heuristic. The heuristic works by assigning a (depth)
> level to all nodes. The first child is the node of which this
> node is a parent of and has the lowest level. Then it cuts all
> the links that
test-lib-functions: add a helper function that checks for a file and that
the file is not empty. The helper function will provide better error message
in case of failure and improve readability
Signed-off-by: Rohit Ashiwal
---
t/test-lib-functions.sh | 10 ++
1 file changed, 10 insertion
Replace `test -(d|f|e|s)` calls in `t3600-rm.sh`.
Previously we were using `test -(d|f|e|s)` to verify the presence of a
directory/file, but we already have helper functions, viz,
`test_path_is_dir`, `test_path_is_file`, `test_path_is_missing` and
`test_file_not_empty` with better functionality.
Replace leading spaces with tabs
The previous code of `t3600-rm.sh` had a mix use of tabs and spaces with
instance of `not-so-recommended` way of writing `if-then` statement,
replace them so that the current version agrees with the coding guidelines
Signed-off-by: Rohit Ashiwal
---
t/t3600-rm.s
This patch ultimately aims to replace `test -(d|f|e|s)` calls in t3600-rm.sh
Previously we were using these to verify the presence of diretory/file, but
we already have helper functions, viz, `test_path_is_dir`, `test_path_is_file`,
`test_path_is_missing` and `test_file_not_empty` with better funct
Before this commit, graphs with merges have an empty line after a
merge commit to make room for a new branch. But this causes the
child commits (commits merged with the merge commit) to be separated
from the merge commit. Especially with the --tree option this
is confusing, as there is no empty lin
Modifies the topo-order code to keep track of the first child,
using a heuristic. The heuristic works by assigning a (depth)
level to all nodes. The first child is the node of which this
node is a parent of and has the lowest level. Then it cuts all
the links that are not the first child, resulting
On Sun, Mar 3, 2019 at 5:12 PM Duy Nguyen wrote:
> This is a good point. My guess is the pack access consists of two
> parts: deflate zlib, resolve delta objects (which is just another form
s/deflate/inflate/ (i keep making this mistake)
--
Duy
On Sun, Mar 3, 2019 at 2:18 PM Christian Couder
wrote:
> One thing I am still worried about is if we are sure that adding
> parallelism is likely to get us a significant performance improvement
> or not. If the performance of this code is bounded by disk or memory
> access, then adding parallelism
On Sat, Mar 2, 2019 at 10:09 PM Thomas Gummerer wrote:
>
> On 03/01, Duy Nguyen wrote:
> > On Fri, Mar 1, 2019 at 5:20 AM Christian Couder
> > wrote:
> > >
> > > Hi Matheus,
> > >
> > > On Thu, Feb 28, 2019 at 10:46 PM Matheus Tavares Bernardino
> > > wrote:
> > > >
> > > > I've been in the mail
On 03/03, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > As I was advocating for this series to go into 'next' without a large
> > refactor of this series, I'll put my money were my mouth is and try to
> > make the cleanups and fixes required, though without trying to avoid
> > further ext
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> The --stress option currently accepts an argument, but it is confusing
> to at least this user that the argument does not define the maximal
> number of stress iterations, but instead the number of jobs to run in
> pa
"Johannes Schindelin via GitGitGadget"
writes:
> From: Johannes Schindelin
>
> It does not make much sense that running a test with
> --stress-limit= seemingly ignores that option because it does not
> stress test at all.
>
> Signed-off-by: Johannes Schindelin
> ---
> t/test-lib.sh | 1 +
> 1
On Fri, Feb 22, 2019 at 5:07 PM Olga Telezhnaya
wrote:
>
> Get rid of mark_query field in struct expand_data.
> expand_data may be global further as we use it in ref-filter also,
> so we need to remove cat-file specific fields from it.
>
> All globals that I add through this patch will be deleted
80 matches
Mail list logo
