Hi,
> This subject line will appear out of context in "git shortlog" output,
> so it's useful to pack in enough information to briefly summarize what
> the change does.
I'm happy to do so. I think that "simplify" is misleading, because this
is a bug fix, not a refactoring. I like your first
On Sun, Aug 5, 2018 at 12:20 AM Jonathan Nieder wrote:
> William Chargin wrote:
> > test_dir_is_empty () {
> > test_path_is_dir "$1" &&
> > - if test -n "$(ls -a1 "$1" | egrep -v '^\.\.?$')"
> > + if test "$(ls -A1 "$1" | wc -c)" != 0
>
> Another portability gotcha: wc output
On Sat, Aug 4, 2018 at 11:33 PM Eric Sunshine wrote:
> On Sat, Aug 4, 2018 at 11:17 PM Jonathan Nieder wrote:
> > So it looks like FreeBSD has modernized and we need to make that
> > conditional in config.mak.uname on $(uname_R). Do you know which
> > version of FreeBSD changed the signature?
While the `test_dir_is_empty` function appears correct in most normal
use cases, it can fail when filenames contain newlines. This patch
changes the implementation to use `ls -A`, which is specified by POSIX.
The output should be empty exactly if the directory is empty.
The newly added unit test
Hi,
William Chargin wrote:
> Subject: t/test-lib: make `test_dir_is_empty` more robust
This subject line will appear out of context in "git shortlog" output,
so it's useful to pack in enough information to briefly summarize what
the change does. How about something like
Hi Jonathan,
> This information belongs in the commit message
Agreed: I included it at the start of the commit message, though I
suppose that the wording in the cover letter is clearer, so I've amended
the commit to use that wording instead.
> Continuing the note about
Hi,
William Chargin wrote:
> While the `test_dir_is_empty` function appears correct in most normal
> use cases, it can fail when filenames contain newlines.
This information belongs in the commit message, since it's useful
context for understanding the motivation behind the patch when
On Sat, Aug 4, 2018 at 11:17 PM Jonathan Nieder wrote:
> > utf8.c:486:28: warning: passing 'iconv_ibp *' (aka 'const char **') to
> > parameter
> > of type 'char **' discards qualifiers in nested pointer types
> > [-Wincompatible-pointer-types-discards-qualifiers]
>
> Oh, good catch!
Jeffrey Walton wrote:
> On Sat, Aug 4, 2018 at 9:26 PM, Jonathan Nieder wrote:
>> Jeffrey Walton wrote:
>>> I'm having trouble setting up my ~/.gitconfig to push using SSH and
>>> pull using HTTPS for all repos on GitHub. The idea is, no passwords on
>>> pulls and only use the password for push.
Eric Sunshine wrote:
> And, compilation warnings are not limited to old compilers. Even my
> fully up-to-date FreeBSD 11.2 installation is not warning-free[1].
>
> [1]: For instance:
> utf8.c:486:28: warning: passing 'iconv_ibp *' (aka 'const char **') to
> parameter
> of type 'char **'
On Sat, Aug 4, 2018 at 2:38 AM Duy Nguyen wrote:
> On Sat, Aug 4, 2018 at 8:11 AM Jonathan Nieder wrote:
> > My main concern is not about them but about other
> > people building from source in order to run (instead of to develop)
> > Git, and by extension, the people they go to for help when it
The previous behavior could incorrectly pass given a directory with a
filename containing a newline. This patch changes the implementation to
use `ls -A`, which is specified by POSIX. The output should be empty
exactly if the directory is empty.
The newly added unit test fails before this change
While the `test_dir_is_empty` function appears correct in most normal
use cases, it can fail when filenames contain newlines. I originally
wrote this patch for the standalone Sharness library, but that library
advises that such patches be sent to the Git mailing list first.
William Chargin (1):
On Sat, Aug 4, 2018 at 9:26 PM, Jonathan Nieder wrote:
> Hi,
>
> Jeffrey Walton wrote:
>
>> I'm having trouble setting up my ~/.gitconfig to push using SSH and
>> pull using HTTPS for all repos on GitHub. The idea is, no passwords on
>> pulls and only use the password for push.
>>
>> I've got the
Hi,
Johannes Schindelin wrote:
> Currently, this test case throws an assertion:
>
> Assertion failed!
>
> Program: git.exe
> File: line-log.c, Line 71
>
> Signed-off-by: Johannes Schindelin
> ---
> t/t4211-line-log.sh | 17 +
> 1 file changed, 17 insertions(+)
Hi Alexander,
Alexander Mills wrote:
> On Sat, Aug 4, 2018 at 2:47 PM, Alexander Mills
> wrote:
>> I assume that access more than 1 git repo concurrently on a local
>> machine is not without errors. However this seems like a huge
>> limitation or design flaw.
>>
>> Is my observation correct?
Hi,
Edward Thomson wrote:
> I created a simple shell script a while back to help people recover
> files that they deleted from their working directory (but had been added
> to the repository), which looks for unreachable blobs in the object
> database and places them in the working directory
Hi,
Jeffrey Walton wrote:
> I'm having trouble setting up my ~/.gitconfig to push using SSH and
> pull using HTTPS for all repos on GitHub. The idea is, no passwords on
> pulls and only use the password for push.
>
> I've got the first part of the equation using the following in my
>
Hi Junio,
On Thu, 2 Aug 2018, Junio C Hamano wrote:
> * pk/rebase-in-c (2018-07-30) 3 commits
> - builtin/rebase: support running "git rebase "
> - rebase: refactor common shell functions into their own file
> - rebase: start implementing it as a builtin
>
> Rewrite of the "rebase"
I'm having trouble setting up my ~/.gitconfig to push using SSH and
pull using HTTPS for all repos on GitHub. The idea is, no passwords on
pulls and only use the password for push.
I've got the first part of the equation using the following in my
~/.gitconfig (the ellipses are user info):
$
From: Johannes Schindelin
Currently, this test case throws an assertion:
Assertion failed!
Program: git.exe
File: line-log.c, Line 71
Signed-off-by: Johannes Schindelin
---
t/t4211-line-log.sh | 17 +
1 file changed, 17 insertions(+)
diff --git
I am a heavy user of git log -L In fact, I use the feature where
multiple ranges can be specified extensively, via a not-exactly-trivial
shell script function that takes the currently staged changes (or if none
are staged, the current unstanged changes) and turns them into the
corresponding
From: Johannes Schindelin
The assertion in question really indicates a bug, when triggered, so we
might just as well use the sanctioned method to report it.
Signed-off-by: Johannes Schindelin
---
line-log.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/line-log.c
From: Johannes Schindelin
Technically, it is okay to have line ranges that touch (i.e. the end of
the first range ends just before the next range begins). However, it is
inefficient, and when the user provides such touching ranges via
multiple `-L` options, we already join them.
When we
From: Johannes Schindelin
When traversing commits and adjusting the ranges, things can get really
tricky. For example, when the line range of interest encloses several
hunks of a commit, the line range can actually shrink.
Currently, range_set_shift_diff() does not anticipate that scenario and
Note, in my first paragraph, I should have said "If I have multiple
local git repos, and I run `git status -v` on them *concurrently*"...
-alex
On Sat, Aug 4, 2018 at 2:47 PM, Alexander Mills
wrote:
> If I have multiple local git repos, and I run `git status -v` on them,
> sometimes I don't get
If I have multiple local git repos, and I run `git status -v` on them,
sometimes I don't get any stdout for the command. This is highly
reproducible.
I assume that access more than 1 git repo concurrently on a local
machine is not without errors. However this seems like a huge
limitation or
The patch [https://github.com/git-for-windows/git/commit/4aa8b8c82] that
introduced support for pull --rebase= into the Git for Windows project
still allowed the very convenient abbreviation
git pull --rebase=i
which was later lost when it was ported to the builtin git pull, and it was
not
From: Johannes Schindelin
Git for Windows' original 4aa8b8c8283 (Teach 'git pull' to handle
--rebase=interactive, 2011-10-21) had support for the very convenient
abbreviation
git pull --rebase=i
which was later lost when it was ported to the builtin `git pull`, and
it was not
Tests for "git am --[no-]scissors" [1] work in the following way:
1. Create files with commit messages
2. Use these files to create expected commits
3. Generate eml file with patch from expected commits
4. Create commits using git am with these eml files
5. Compare these commits with
Hi,
Robert P. J. Day wrote:
> On Sat, 4 Aug 2018, Junio C Hamano wrote:
>> In other words, I think this patch can be a fine addition to
>> somebody else's project (i.e. random collection of scripts that may
>> help Git users), so let's see how I can offer comments/inputs to
>> help you improve
Max Kirillov writes:
> On Sat, Aug 04, 2018 at 08:34:08AM +0200, Duy Nguyen wrote:
>> On Fri, Jul 27, 2018 at 5:50 AM Max Kirillov wrote:
>>> + if (max_request_buffer < req_len) {
>>> + die("request was larger than our maximum size (%lu): "
>>> + "%"
Duy Nguyen writes:
> On Sat, Aug 4, 2018 at 8:11 AM Jonathan Nieder wrote:
>> My main concern is not about them but about other
>> people building from source in order to run (instead of to develop)
>> Git, and by extension, the people they go to for help when it doesn't
>> work. I have lots
Stefan Beller writes:
> Try it out via
> ./git-format-patch --mark-moved 15ef69314d^..15ef69314d
> to see if you like it.
>
> This separates the coloring decision from the detection of moved lines.
> When giving --mark-moved, move detection is still performed and the output
> markers are
Stefan Beller writes:
> This builds on top of sb/range-diff-colors, which builds on js/range-diff.
As another round of js/range-diff is expected, according to
I will refrain from queuing this right now. Possible conflict
resolution that won't be reusable when the base one is rerolled and
Edward Thomson writes:
> In any case, it sounds like you're not particularly interested in
> this, although I certainly appreciate you taking the time to suggest
> improvements despite that. There's some good feedback there.
Not in its current shape. But do not take this in a wrong way. It
On Sat, 4 Aug 2018, Junio C Hamano wrote:
> Edward Thomson writes:
>
> > Introduce git-recover, a simple script to aide in restoration of
> > deleted worktree files. This will look for unreachable blobs in
> > the object database and prompt users to restore them to disk,
> > either
On Sat, Aug 04, 2018 at 08:54:49AM -0700, Junio C Hamano wrote:
>
> My first reaction was to say that I am not going to take a new
> command written only for bash with full bashism, even if it came
> with docs, tests nor Makefile integration, for Git itself. Then I
> reconsidered, as not
Edward Thomson writes:
> Introduce git-recover, a simple script to aide in restoration of deleted
> worktree files. This will look for unreachable blobs in the object
> database and prompt users to restore them to disk, either interactively
> or on the command-line.
> ---
> git-recover.sh |
Introduce git-recover, a simple script to aide in restoration of deleted
worktree files. This will look for unreachable blobs in the object
database and prompt users to restore them to disk, either interactively
or on the command-line.
---
git-recover.sh | 311
Hello-
I created a simple shell script a while back to help people recover
files that they deleted from their working directory (but had been added
to the repository), which looks for unreachable blobs in the object
database and places them in the working directory (either en masse,
On Sat, Aug 04, 2018 at 08:34:08AM +0200, Duy Nguyen wrote:
> On Fri, Jul 27, 2018 at 5:50 AM Max Kirillov wrote:
>> + if (max_request_buffer < req_len) {
>> + die("request was larger than our maximum size (%lu): "
>> + "%" PRIuMAX "; try setting
Subject: doc hash-function-transition: pick SHA-256 as NewHash
>From a security perspective, it seems that SHA-256, BLAKE2, SHA3-256,
K12, and so on are all believed to have similar security properties.
All are good options from a security point of view.
SHA-256 has a number of advantages:
* It
On Fri, Aug 03, 2018 at 12:06:34PM -0400, Jeff King wrote:
> On Fri, Aug 03, 2018 at 11:43:44AM -0400, Santiago Torres wrote:
>
> > > This is not a deviation. GPG correctly recognizes difference between
> > > trusted,
> > > untrusted and unknown levels. git on the other hand does not. Well it
Jeff King wrote:
> On Sun, Jul 29, 2018 at 05:36:05PM +0200, Nguyễn Thái Ngọc Duy wrote:
>> These extra comments should be make it easier to understand how to use
>> locks in pack-objects delta search code. For reference, see
>>
>> 8ecce684a3 (basic threaded delta search - 2007-09-06)
>>
On Sat, Aug 4, 2018 at 8:11 AM Jonathan Nieder wrote:
> My main concern is not about them but about other
> people building from source in order to run (instead of to develop)
> Git, and by extension, the people they go to for help when it doesn't
> work. I have lots of bitter experience of
On Fri, Jul 27, 2018 at 5:50 AM Max Kirillov wrote:
> -static void inflate_request(const char *prog_name, int out, int buffer_input)
> +static ssize_t read_request_fixed_len(int fd, ssize_t req_len, unsigned char
> **out)
> +{
> + unsigned char *buf = NULL;
> + ssize_t cnt = 0;
> +
>
The color group in config.txt is actually sorted but changes in
sb/blame-color broke this. Reorder color.blame.* and move
blame.coloring back to the rest of blame.* (and reorder that group too
while we're there)
Signed-off-by: Nguyễn Thái Ngọc Duy
---
Documentation/config.txt | 68
Hi,
Stefan Beller wrote:
> Reviewer bandwidth is limited, so let's have the machine of the
> (potentially new) contributor warn about issues with the code by default.
>
> As setting DEVELOPER, the compiler is stricter and we may run into problems
> on some architectures. But packagers of said
49 matches
Mail list logo
