William Chargin wrote:
> Jonathan Nieder wrote:
>> 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
Hi,
Junio C Hamano wrote:
> Jonathan Nieder writes:
>> but $'' is too recent of a shell feature to count on (e.g., dash doesn't
>> support it). See t/t3600-rm.sh for an example of a portable way to do
>
> Is that "too recent"? I thought it was bashism, not even in POSIX,
> but I may be mistake
Stefan Beller writes:
>> You are the second one who were negatively affected by Stefan's
>> "summary" that reads a lot more in what I said than what actually
>> was said by me. Stop paying attention to that message, but do go to
>> the original if you want to hear what I actually said.
>
> Pleas
Hi,
Alexander Mills wrote:
> Yeah as long as git shouldnt fumble wrt concurrent access across repos, it
> was most likely the same repo being accessed concurrently and that's what
> was causing the issue.
>
> that being said, it would be really nice if git itself could handle
> concurrent request
"Johannes Schindelin via GitGitGadget"
writes:
> 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
> mu
Johannes Schindelin writes:
> 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
Jonathan Nieder writes:
> but $'' is too recent of a shell feature to count on (e.g., dash doesn't
> support it). See t/t3600-rm.sh for an example of a portable way to do
Is that "too recent"? I thought it was bashism, not even in POSIX,
but I may be mistaken.
Quite honestly, our tests are st
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 sugge
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 includ
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? C
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 f
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
test_dir_is_emp
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 ad
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
encounteri
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 **' dis
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 a
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? Are
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 (eit
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
> ~/.gitconfig
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" machinery
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):
$ ca
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 a/t/t4
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 traverse
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 co
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 b/lin
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
b
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 design
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 introd
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 introduced
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 expected
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 it.
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): "
>>> + "%" PRIuMAX
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 of
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 adju
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
thi
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
ma
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 interactively
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 everythi
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 | 311
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,
interactively,
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 GIT_HTTP_MAX_
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 did
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)
>> 384b32c09
52 matches
Mail list logo
