[PATCH] clone: pass --progress decision to recursive submodules

When cloning with "--recursive", we'd generally expect submodules to show progress reports if the main clone did, too. In older versions of git, this mostly worked out of the box. Since we show progress by default when stderr is a tty, and since the child clones inherit the parent stderr, then

Re: [PATCH tg/add-chmod+x-fix 2/2] t3700-add: protect one --chmod=+x test with POSIXPERM

Am 21.09.2016 um 23:12 schrieb Junio C Hamano: Johannes Sixt writes: But I came to a different conclusion as I said in a message that crossed yours. I hope Thomas can pick up the baton again. Yeah, our mails crossed, apparently, and I do agree with your reasoning. How about

Re: [PATCH 1/2] ls-files: adding support for submodules

On Wed, Sep 21, 2016 at 04:13:22PM -0700, Junio C Hamano wrote: > Brandon Williams writes: > > > yes you mentioned this and I meant to change that before sending it out. > > Looks like it slipped through have slipped through. > > I already fixed it up locally when I sent the

Re: [PATCH] verify_packfile: check pack validity before accessing data

On Wed, Sep 21, 2016 at 11:49:05PM -0400, Jeff King wrote: > The verify_packfile() does not explicitly open the packfile; > instead, it starts with a sha1 checksum over the whole pack, > and relies on use_pack() to open the packfile as a side > effect. > > If the pack cannot be opened for

[PATCH] verify_packfile: check pack validity before accessing data

The verify_packfile() does not explicitly open the packfile; instead, it starts with a sha1 checksum over the whole pack, and relies on use_pack() to open the packfile as a side effect. If the pack cannot be opened for whatever reason (either because its header information is corrupted, or

What's cooking in git.git (Sep 2016, #06; Wed, 21)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. Quite a lot of topics have

[PATCH 2/2 v2] ls-files: add pathspec matching for submodules

Pathspecs can be a bit tricky when trying to apply them to submodules. The main challenge is that the pathspecs will be with respect to the superproject and not with respect to paths in the submodule. The approach this patch takes is to pass in the identical pathspec from the superproject to the

Re: [PATCH 2/2] ls-files: add pathspec matching for submodules

On Wed, Sep 21, 2016 at 3:53 PM, Junio C Hamano wrote: > > Sounds sensible. Just a minor nit in terminology, but I think we > fairly consistently say "a superproject contains submodules" (run > "git grep -E 'super *(module|project)'"). > > I'd suggest s/super

Re: [PATCH 1/2] ls-files: adding support for submodules

Brandon Williams writes: > yes you mentioned this and I meant to change that before sending it out. > Looks like it slipped through have slipped through. I already fixed it up locally when I sent the reply, but thanks for resending (which assures me that your local copy is

Re: [PATCH 2/2] ls-files: add pathspec matching for submodules

Brandon Williams writes: > Pathspecs can be a bit tricky when trying to apply them to submodules. > The main challenge is that the pathspecs will be with respect to the > super module and not with respect to paths in the submodule. The > approach this patch takes is to pass

Re: v2.10.0: ls-tree exit status is always 0, this differs from ls(1)

Junio C Hamano wrote: |Steffen Nurpmeso writes: ... |Sorry, but I did not notice that there was an attached patch when I |was reading your response for the first time. Risk of using an |attachment to e-mail ;-) | |I think this issue does not need a

[PATCH 1/2] ls-files: optionally recurse into submodules

Allow ls-files to recognize submodules in order to retrieve a list of files from a repository's submodules. This is done by forking off a process to recursively call ls-files on all submodules. Also added a submodule-prefix command in order to prepend paths to child processes. Signed-off-by:

Re: [PATCH 1/2] ls-files: adding support for submodules

yes you mentioned this and I meant to change that before sending it out. Looks like it slipped through have slipped through.

Re: [PATCH 4/3] http: check curl_multi_remove_handle error code

On Wed, Sep 21, 2016 at 10:29:59PM +, Eric Wong wrote: > Jeff King wrote: > > On Wed, Sep 21, 2016 at 09:46:23PM +, Eric Wong wrote: > > > > > ---8<--- > > > Subject: [PATCH] http: check curl_multi_remove_handle error code > > > > > > This should help

Re: [PATCH 4/3] http: check curl_multi_remove_handle error code

Jeff King wrote: > On Wed, Sep 21, 2016 at 09:46:23PM +, Eric Wong wrote: > > > ---8<--- > > Subject: [PATCH] http: check curl_multi_remove_handle error code > > > > This should help detect bugs in future changes. While we're at > > it, fix a (probably

Re: [PATCH 1/2] ls-files: adding support for submodules

Brandon Williams writes: > This is another version of the first ls-files patch i sent out in > order. In this version I fixed the option > name to be '--submodule-prefix'. I understand that many internal changes in your work environment are titled like "DOing X", but our

Re: [PATCH] gitweb: use highlight's shebang detection

fyi: I mistakenly did not include v2 in the subject of the last message.

Re: [PATCH 4/3] http: check curl_multi_remove_handle error code

On Wed, Sep 21, 2016 at 09:46:23PM +, Eric Wong wrote: > ---8<--- > Subject: [PATCH] http: check curl_multi_remove_handle error code > > This should help detect bugs in future changes. While we're at > it, fix a (probably innocuous) bug in our http_cleanup function > for

[PATCH] gitweb: use highlight's shebang detection

The highlight binary can detect language by shebang when we can't tell the syntax type by the name of the file. In that case, pass the blob to "highlight --force" and the resulting html will have markup for highlighting if the language was detected. Document the feature and improve syntax

Re: [PATCH] gitweb: use highlight's shebang detection

On Tue, Sep 20, 2016, at 01:22 PM, Jakub Narębski wrote: > W dniu 06.09.2016 o 21:00, Ian Kelling pisze: > > > The highlight binary can detect language by shebang when we can't tell > > the syntax type by the name of the file. > > Was it something always present among highlight[1] binary

Re: [PATCH v4 3/3] regex: use regexec_buf()

On Wed, Sep 21, 2016 at 08:24:14PM +0200, Johannes Schindelin wrote: > The new regexec_buf() function operates on buffers with an explicitly > specified length, rather than NUL-terminated strings. > > We need to use this function whenever the buffer we want to pass to > regexec() may have been

Re: [PATCH 1/2] ls-files: adding support for submodules

This is another version of the first ls-files patch i sent out in order. In this version I fixed the option name to be '--submodule-prefix'.

[PATCH 1/2] ls-files: adding support for submodules

Allow ls-files to recognize submodules in order to retrieve a list of files from a repository's submodules. This is done by forking off a process to recursively call ls-files on all submodules. Also added a submodule-prefix command in order to prepend paths to child processes. Signed-off-by:

[PATCH 2/2] ls-files: add pathspec matching for submodules

Pathspecs can be a bit tricky when trying to apply them to submodules. The main challenge is that the pathspecs will be with respect to the super module and not with respect to paths in the submodule. The approach this patch takes is to pass in the identical pathspec from the super module to the

Re: [PATCH v4 0/3] Fix a segfault caused by regexec() being called on mmap()ed data

On Wed, Sep 21, 2016 at 08:23:11PM +0200, Johannes Schindelin wrote: > We solve this by introducing a helper, regexec_buf(), that takes a > pointer and a length instead of a NUL-terminated string. > > This helper then uses REG_STARTEND where available, and falls back to > allocating and

[PATCH 4/3] http: check curl_multi_remove_handle error code

Junio C Hamano wrote: > Eric Wong writes: > > The key patch here is 3/3 which seems like an obvious fix to > > adding the problem of adding a curl easy handle to a curl multi > > handle repeatedly. > > Yeah, sounds like the right thing to do and 2/3 makes it

Re: [PATCH tg/add-chmod+x-fix 2/2] t3700-add: protect one --chmod=+x test with POSIXPERM

Johannes Sixt writes: > But I came to a different conclusion as I said in a message that > crossed yours. I hope Thomas can pick up the baton again. Yeah, our mails crossed, apparently, and I do agree with your reasoning. How about this, then? -- >8 -- From: Johannes Sixt

RE: [PATCH v3] checkout: eliminate unnecessary merge for trivial checkout

I understand the reluctance to change the existing behavior of the "git checkout -b " command. I see this as a tradeoff between taking advantage of the muscle memory for the existing command and coming up with a new shortcut command and training people to use it instead. The fact that all the

Re: [PATCH tg/add-chmod+x-fix 2/2] t3700-add: protect one --chmod=+x test with POSIXPERM

Am 21.09.2016 um 22:47 schrieb Junio C Hamano: -test_expect_success 'file status is changed after git add --chmod=+x' ' - echo "AM foo4" >expected && +test_expect_success 'git add --chmod=[+-]x changes index with newly added file' ' echo foo >foo4 && git add foo4 &&

Re: [PATCH tg/add-chmod+x-fix 2/2] t3700-add: protect one --chmod=+x test with POSIXPERM

Am 21.09.2016 um 20:12 schrieb Junio C Hamano: Thomas Gummerer writes: I am surprised that add --chmod=+x changes only the index, but not the file on disk!?! I *think* --chmod is mainly thought of as a convenience for git users on a filesystem that doesn't have an

Re: [PATCH tg/add-chmod+x-fix 2/2] t3700-add: protect one --chmod=+x test with POSIXPERM

Junio C Hamano writes: > ... Comparing the index with the working tree using "status" > is probably not how you would want to do so. A future breakage may > cause the indexed blob name to change by mistake, and status would > happily report difference but you would not

Re: v2.10.0: ls-tree exit status is always 0, this differs from ls(1)

Steffen Nurpmeso writes: > diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt > index dbc91f9..8ebeced 100644 > --- a/Documentation/git-ls-tree.txt > +++ b/Documentation/git-ls-tree.txt > @@ -33,6 +33,10 @@ in the current working directory. Note that:

Re: [PATCH 2/3] gitweb: Link to 7-character SHA1SUMS in commit messages

On Wed, Sep 21, 2016 at 8:28 PM, Jakub Narębski wrote: > W dniu 21.09.2016 o 20:04, Ævar Arnfjörð Bjarmason pisze: >> It would make some code like git_print_log() a bit more complex / >> fragile, since it would have to work on multi-line strings, but >> anything that needed to

Re: [PATCH v4 3/3] regex: use regexec_buf()

Junio C Hamano writes: > Johannes Schindelin writes: > >> The new regexec_buf() function operates on buffers with an explicitly >> specified length, rather than NUL-terminated strings. >> >> We need to use this function whenever the buffer we want

Re: v2.10.0: ls-tree exit status is always 0, this differs from ls(1)

Hello. Junio C Hamano wrote: |Steffen Nurpmeso writes: |> I think this behaviour contradicts the manual which strongly links |> ls-tree to ls(1): | |Patches to the documentation is very much welcomed. The below could serve this purpose. |Somewhere

Re: [PATCH v4 3/3] regex: use regexec_buf()

Johannes Schindelin writes: > The new regexec_buf() function operates on buffers with an explicitly > specified length, rather than NUL-terminated strings. > > We need to use this function whenever the buffer we want to pass to > regexec() may have been mmap()ed (and

Re: [PATCH v4 2/3] regex: add regexec_buf() that can work on a non NUL-terminated string

Johannes Schindelin writes: > ... > Happily, there is an extension to regexec() introduced by the NetBSD > project and present in all major regex implementation including > Linux', MacOSX' and the one Git includes in compat/regex/: by using > the (non-POSIX)

Re: [PATCH 3/3] gitweb: Link to "git describe"'d commits in log messages

W dniu 21.09.2016 o 19:58, Ævar Arnfjörð Bjarmason pisze: > On Wed, Sep 21, 2016 at 7:09 PM, Jakub Narębski wrote: >> W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał: >>> +(?>> +[A-Za-z0-9.-]+ >>> +(?!\.) # refs can't end with ".",

Re: [PATCH v2 2/3] init: do not set core.worktree more often than necessary

Nguyễn Thái Ngọc Duy writes: > When "git init" is called with GIT_WORK_TREE environment set, we want to > keep this worktree's location in core.worktree so the user does not have > to set the environment again and again. See ef6f0af (git-init: set > core.worktree if

[PATCH v4 1.5/3] fixup! regex: -G feeds a non NUL-terminated string to regexec() and fails

Sorry, I should have squashed that in, but I *just* noticed the conflict with 433860f (diff: improve positioning of add/delete blocks in diffs, 2016-09-05). --- t/{t4061-diff-pickaxe.sh => t4062-diff-pickaxe.sh} | 0 1 file changed, 0 insertions(+), 0 deletions(-) rename

Re: [PATCH 2/3] gitweb: Link to 7-character SHA1SUMS in commit messages

W dniu 21.09.2016 o 20:04, Ævar Arnfjörð Bjarmason pisze: > On Wed, Sep 21, 2016 at 6:26 PM, Jakub Narębski wrote: > >> P.S. I have reworking of commit message parsing and enhancement in my >> long, long and dated gitweb TODO list :-( > > Anything specific you could share?

[PATCH v4 2/3] regex: add regexec_buf() that can work on a non NUL-terminated string

We just introduced a test that demonstrates that our sloppy use of regexec() on a mmap()ed area can result in incorrect results or even hard crashes. So what we need to fix this is a function that calls regexec() on a length-delimited, rather than a NUL-terminated, string. Happily, there is an

[PATCH v4 3/3] regex: use regexec_buf()

The new regexec_buf() function operates on buffers with an explicitly specified length, rather than NUL-terminated strings. We need to use this function whenever the buffer we want to pass to regexec() may have been mmap()ed (and is hence not NUL-terminated). Note: the original motivation for

[PATCH v4 1/3] regex: -G feeds a non NUL-terminated string to regexec() and fails

When our pickaxe code feeds file contents to regexec(), it implicitly assumes that the file contents are read into implicitly NUL-terminated buffers (i.e. that we overallocate by 1, appending a single '\0'). This is not so. In particular when the file contents are simply mmap()ed, we can be

[PATCH v4 0/3] Fix a segfault caused by regexec() being called on mmap()ed data

[Cc:ing Benjamin Kramer & René Scharfe because they both worked on the REG_STARTEND code in grep.c that I replace in this iteration of the patch series] This patch series addresses a problem where `git diff` is called using `-G` or `-S --pickaxe-regex` on new-born files that are configured

Re: What's cooking in git.git (Sep 2016, #05; Mon, 19)

Hi Junio, On Wed, 21 Sep 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > >> * jk/rebase-i-drop-ident-check (2016-07-29) 1 commit > >> (merged to 'next' on 2016-08-14 at 6891bcd) > >> + rebase-interactive: drop early check for valid ident > >> > >>

Re: [PATCH v2 0/3] Fix git-init in linked worktrees

Nguyễn Thái Ngọc Duy writes: > v2 requires jk/setup-sequence-update so I could kill my workaround > patch and avoid conflicts in t0001. And: > > - 1/3 has a few missing words back in its commit message > - 2/3, which was 3/3 in v1, no longer has the ugly hacky >

Re: git-gui, was Re: [PATCH v2 6/6] git-gui: Update Japanese information

Vasco Almeida writes: > I have sent some git-gui patches on May this year and I think it will > add value to accepted them at some point: Yeah, they may be of value, but the thing is, I am not really in the position to review or apply them (I don't do git-gui). If Pat is

Re: [PATCH] git-check-ref-format.txt: fixup documentation

Elia Pinto writes: > die is not a standard shell function. Use > a different shell code for the example. Thanks.

Re: [PATCH tg/add-chmod+x-fix 2/2] t3700-add: protect one --chmod=+x test with POSIXPERM

Thomas Gummerer writes: >> I am surprised that add --chmod=+x changes only the index, but not >> the file on disk!?! > > I *think* --chmod is mainly thought of as a convenience for git users > on a filesystem that doesn't have an executable flag. So it was > introduced

Re: [PATCH 2/3] gitweb: Link to 7-character SHA1SUMS in commit messages

On Wed, Sep 21, 2016 at 6:26 PM, Jakub Narębski wrote: > P.S. I have reworking of commit message parsing and enhancement in my > long, long and dated gitweb TODO list :-( Anything specific you could share? One thing that would be a lot faster in Perl is if we didn't have to

Re: [PATCH 3/3] gitweb: Link to "git describe"'d commits in log messages

Jakub Narębski writes: >> When I saw 2/3 I wondered about one thing and 3/3 shares the same, >> which is that we only use regex match and do not validate for a >> false match. Would it be too expensive... > > It's a matter of balance between false positives (and unresolving >

Re: v2.9.3 and v2.10.0: `name-ref' HEAD gives wrong branch name

W dniu 21.09.2016 o 18:37, Junio C Hamano pisze: > Jakub Narębski writes: >>> Have you tried "git symbolic-ref HEAD"? >>> >>> $ git symbolic-ref HEAD >>> refs/heads/master >>> >>> If you don't want the fully-qualified ref, you can add --short: >>> >>> $ git symbolic-ref --short

Re: [PATCH 3/3] gitweb: Link to "git describe"'d commits in log messages

just plain 867ad08. > > All right, that is a good plan. > >> >> This also fixes a micro-regression in my change of the minimum SHA1 >> length from 8 to 7, which is that dated tags like >> hadoop-20160921-113441-20-g094fb7d would start thinking the "20160921&q

Re: [PATCH] gitweb: use highlight's shebang detection

W dniu 21.09.2016 o 18:38, Junio C Hamano pisze: > Jakub Narębski writes: >> W dniu 06.09.2016 o 21:00, Ian Kelling pisze: >> >>> The highlight binary can detect language by shebang when we can't tell >>> the syntax type by the name of the file. >> >> Was it something always

Re: [PATCH v2] ls-files: add pathspec matching for submodules

Junio C Hamano writes: > Brandon Williams writes: > >> On a similar but slightly different note. In general do we want >> the pathspec '??b' to match against the sib/ directory and >> subsequently have ls-files print all entries inside of the sib/ >>

Re: [PATCH 3/3] gitweb: Link to "git describe"'d commits in log messages

W dniu 21.09.2016 o 18:50, Junio C Hamano pisze: > Ævar Arnfjörð Bjarmason writes: > >> There's surely room for improvement here, but I just wanted to address >> the very common case of sticking "git describe" output into commit >> messages without trying to link to all

Re: What's cooking in git.git (Sep 2016, #05; Mon, 19)

On Wed, Sep 21, 2016 at 10:36:57AM -0700, Junio C Hamano wrote: > Kevin Daudt writes: > > > On Mon, Sep 19, 2016 at 04:30:34PM -0700, Junio C Hamano wrote: > >> > >> * kd/mailinfo-quoted-string (2016-09-19) 2 commits > >> - mailinfo: unescape quoted-pair in header fields > >>

Re: What's cooking in git.git (Sep 2016, #05; Mon, 19)

Kevin Daudt writes: > On Mon, Sep 19, 2016 at 04:30:34PM -0700, Junio C Hamano wrote: >> >> * kd/mailinfo-quoted-string (2016-09-19) 2 commits >> - mailinfo: unescape quoted-pair in header fields >> - t5100-mailinfo: replace common path prefix with variable > > Is this good

Re: [PATCH v3 0/3] handle multiline in-body headers

Jonathan Tan writes: > With the above change, it is actually no longer necessary to make > is_scissors_line take plain char * (the second patch) - I think that > that patch still improves the code, but let me know if you want me to > remove it from this patch set. I

Re: [PATCH 1/6] i18n: commit: mark message for translation

Jean-Noël AVILA writes: > Signed-off-by: Vasco Almeida > Signed-off-by: Jean-Noel Avila > --- > > Instead of distillating change requests, I'd better do it by > myself. Here is the reworked version of the patch. > It would have helped

Re: [PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786

On Wed, Sep 21, 2016 at 7:14 PM, Jakub Narębski wrote: > W dniu 21.09.2016 o 16:17, Ævar Arnfjörð Bjarmason napisał: >> On Wed, Sep 21, 2016 at 3:33 PM, Jakub Narębski wrote: >>> W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał: > [...] > -#

Re: [PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786

W dniu 21.09.2016 o 16:17, Ævar Arnfjörð Bjarmason napisał: > On Wed, Sep 21, 2016 at 3:33 PM, Jakub Narębski wrote: >> W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał: [...] >>> -# Sanitize for use in XHTML + application/xml+xhtm (valid XML 1.0) >>> +# Sanitize for

Re: [PATCH v2] ls-files: add pathspec matching for submodules

Brandon Williams writes: > On a similar but slightly different note. In general do we want > the pathspec '??b' to match against the sib/ directory and > subsequently have ls-files print all entries inside of the sib/ > directory? (this is in the non-recursive case) I'd

Re: [PATCH 3/3] gitweb: Link to "git describe"'d commits in log messages

change of the minimum SHA1 > length from 8 to 7, which is that dated tags like > hadoop-20160921-113441-20-g094fb7d would start thinking the "20160921" > part was a commit. Actually 20160921 is 8 characters, so assuming that '-' is treated as word boundary by Perl, it

Re: v2.10.0: ls-tree exit status is always 0, this differs from ls(1)

Steffen Nurpmeso writes: > I think this behaviour contradicts the manual which strongly links > ls-tree to ls(1): Patches to the documentation is very much welcomed. Somewhere the similarity must end, and actually it ends a lot earlier, as "/bin/ls" takes exact paths while

Re: [PATCH 3/3] gitweb: Link to "git describe"'d commits in log messages

line = shift; > > $line = esc_html($line, -nbsp=>1); > - $line =~ s{\b([0-9a-fA-F]{7,40})\b}{ > + $line =~ s{ > +\b > +( > + # The output of "git describe", e.g. v2.10.0-297-gf6727b0 > +# or hadoop-2

Re: [PATCH v1] travis-ci: ask homebrew for the its path instead of hardcoding it

Lars Schneider writes: >> On 21 Sep 2016, at 11:31, stefan.na...@atlas-elektronik.com wrote: >> >> In the Subject: s/the // >> >> Am 21.09.2016 um 10:45 schrieb larsxschnei...@gmail.com: >>> From: Lars Schneider >>> >>> The TravisCI macOS

Re: [PATCH] gitweb: use highlight's shebang detection

Jakub Narębski writes: > W dniu 06.09.2016 o 21:00, Ian Kelling pisze: > >> The highlight binary can detect language by shebang when we can't tell >> the syntax type by the name of the file. > > Was it something always present among highlight[1] binary capabilities, > or is it

Re: v2.9.3 and v2.10.0: `name-ref' HEAD gives wrong branch name

Jakub Narębski writes: >> Have you tried "git symbolic-ref HEAD"? >> >> $ git symbolic-ref HEAD >> refs/heads/master >> >> If you don't want the fully-qualified ref, you can add --short: >> >> $ git symbolic-ref --short HEAD >> master > > This does not work for detached

Re: [PATCH 2/3] gitweb: Link to 7-character SHA1SUMS in commit messages

W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał: > Subject: [PATCH 2/3] gitweb: Link to 7-character SHA1SUMS in commit messages This is modification of a feature, not a new feature it sounds like. I think the following title / subject would be better: Subject: [PATCH 2/3] gitweb:

Re: What's cooking in git.git (Sep 2016, #05; Mon, 19)

On Mon, Sep 19, 2016 at 04:30:34PM -0700, Junio C Hamano wrote: > > * kd/mailinfo-quoted-string (2016-09-19) 2 commits > - mailinfo: unescape quoted-pair in header fields > - t5100-mailinfo: replace common path prefix with variable Is this good enough, or do you want me to look into the

Re: 2.10.0: git log --oneline prints gpg signatures in 4 lines

Jeff King writes: > I don't think anything has changed here in 2.10. Running "git log > --oneline --show-signature" has _always_ been horribly ugly. However, > 2.10 did introduce the "log.showsignature" config, which makes "git log > --oneline" pretty unusable when it is enabled.

Re: 2.10.0: git log --oneline prints gpg signatures in 4 lines

Leandro Lucarella writes: > Hi, starting from 2.10.0 I noticed that when using git log --oneline, > if commits are signed with GPG, now the signatures are printed too, and > it takes 3 lines for the signature information + 1 line for the title > of the commit,

Re: clarification of `rev-list --no-walk ^`?

Michael J Gruber writes: > I think you answered to e-mail (in-reply-to) and to Philip's actual text > (quotes), but just in case: Yes, my mistake. Sorry for the noise.

Re: Bug: pager. doesn't work well with editors

Jeff King writes: > And this isn't really limited to the editor. It's more _annoying_ with > the editor, but really "pager.tag" does not make any sense to set right > now, because it is handled outside of the "tag" command entirely, and > doesn't know what mode the tag command

Re: [PATCH] mailinfo: unescape quoted-pair in header fields

Jeff King writes: > So if that's the case, do we actually need to care if we see any > parenthesized comments? I think we should just leave comments in place > either way, so syntactically they are only interesting insofar as we > replace quoted pairs or not. > > IOW, I wonder if:

Re: [PATCH v3] format-patch: Add --rfc for the common case of [RFC PATCH]

Josh Triplett writes: > This provides a shorter and more convenient alias for > --subject-prefix='RFC PATCH'. Shorter and more convenient is quite subjective but more important as a justification is that we believe [RFC PATCH] is used fairly commonly (at least in certain

Re: What's cooking in git.git (Sep 2016, #05; Mon, 19)

Duy Nguyen writes: > On Tue, Sep 20, 2016 at 6:30 AM, Junio C Hamano wrote: >> * nd/checkout-disambiguation (2016-09-09) 4 commits >> - fixup! checkout.txt: document a common case that ignores ambiguation rules >> - checkout: fix ambiguity check in subdir

Re: What's cooking in git.git (Sep 2016, #05; Mon, 19)

Johannes Schindelin writes: >> * jk/rebase-i-drop-ident-check (2016-07-29) 1 commit >> (merged to 'next' on 2016-08-14 at 6891bcd) >> + rebase-interactive: drop early check for valid ident >> >> Even when "git pull --rebase=preserve" (and the underlying "git >>

Re: 2.10.0: git log --oneline prints gpg signatures in 4 lines

Leandro Lucarella venit, vidit, dixit 21.09.2016 15:53: > On Tue, 20 Sep 2016 19:15:33 -0400 > Jeff King wrote: > >> On Tue, Sep 20, 2016 at 05:09:54PM +0200, Leandro Lucarella wrote: >> >>> Hi, starting from 2.10.0 I noticed that when using git log >>> --oneline, if commits are

Re: clarification of `rev-list --no-walk ^`?

Junio C Hamano venit, vidit, dixit 19.09.2016 18:12: > Michael J Gruber writes: > >>> It can be read that >>> >>> $ git cherry-pick maint next >>> >>> would pick two single commits, while >>> >>> $ git cherry-pick maint next ^master >>> >>> could implicitly be read as

Re: clarification of `rev-list --no-walk ^`?

[So many typos, sorry] Michael J Gruber venit, vidit, dixit 21.09.2016 16:46: > Junio C Hamano venit, vidit, dixit 19.09.2016 18:12: >> Michael J Gruber writes: >> It can be read that $ git cherry-pick maint next would pick two single commits,

Re: 2.10.0: git log --oneline prints gpg signatures in 4 lines

On Tue, 20 Sep 2016 19:15:33 -0400 Jeff King wrote: > On Tue, Sep 20, 2016 at 05:09:54PM +0200, Leandro Lucarella wrote: > > > Hi, starting from 2.10.0 I noticed that when using git log > > --oneline, if commits are signed with GPG, now the signatures are > > printed too, and it

Re: v2.9.3 and v2.10.0: `name-ref' HEAD gives wrong branch name

Hello. Jakub Narębski wrote: |W dniu 20.09.2016 o 20:54, Bryan Turner pisze: |> On Tue, Sep 20, 2016 at 9:23 AM, Steffen Nurpmeso \ |> wrote: |>> Hello again, |>> |>> yah, sorry, i'm back again.. |>> I try to find a way to find the name of the

Re: [PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786

On Wed, Sep 21, 2016 at 3:33 PM, Jakub Narębski wrote: > W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał: > >> Subject: [PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786 > > It is more "ancient typo from v1.7.7-rc1-1-g0866786", but perhaps more >

FROM MRS LINAH MOHOHLO

Hollow dear, I have initially sent you this message before, kindly get back to me FROM Mrs Rosemary Linah Mohohlo55.docx Description: MS-Word 2007 document

Re: v2.9.3 and v2.10.0: `name-ref' HEAD gives wrong branch name

W dniu 20.09.2016 o 20:54, Bryan Turner pisze: > On Tue, Sep 20, 2016 at 9:23 AM, Steffen Nurpmeso wrote: >> Hello again, >> >> yah, sorry, i'm back again.. >> I try to find a way to find the name of the current branch in an >> automated way, because i need to ensure that a

Re: [PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786

W dniu 21.09.2016 o 13:44, Ævar Arnfjörð Bjarmason napisał: > Subject: [PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786 It is more "ancient typo from v1.7.7-rc1-1-g0866786", but perhaps more important is "ancient typo in a comment" > > The Content-Type is application/xhtml+xml,

Re: [PATCH v1] travis-ci: ask homebrew for the its path instead of hardcoding it

> On 21 Sep 2016, at 11:31, stefan.na...@atlas-elektronik.com wrote: > > In the Subject: s/the // > > Am 21.09.2016 um 10:45 schrieb larsxschnei...@gmail.com: >> From: Lars Schneider >> >> The TravisCI macOS build is broken because homebrew (a macOS depedency > >

v2.10.0: ls-tree exit status is always 0, this differs from ls(1)

I think this behaviour contradicts the manual which strongly links ls-tree to ls(1): ?0[steffen@wales ]$ ls NEWSS ls: cannot access 'NEWSS': No such file or directory ?2[steffen@wales ]$ git ls-tree --name-only master NEWSS

Re: Git garden shears, was Re: [PATCH 13/22] sequencer: remember the onelines when parsing the todo file

Hello Dscho, W dniu 11.09.2016 o 10:33, Johannes Schindelin napisał: > On Fri, 9 Sep 2016, Jakub Narębski wrote: [...] >> When preserving merges, there are (as far as I understand it), two >> problems: >> - what it means to preserve changes (which change to pick, >>that is what is the

Hello!!!!!

DEAR FRIEND, How are you together with your family and business hope all is well. I know that this message will come to you as a surprise. I Hope that you will not expose or betray this trust and confident that I am about to repose on you for our mutual benefit of our both families. I need

Re: 2.10.0: git log --oneline prints gpg signatures in 4 lines

On Tue, 20 Sep 2016 19:15:33 -0400 Jeff King wrote: > On Tue, Sep 20, 2016 at 05:09:54PM +0200, Leandro Lucarella wrote: > > > Hi, starting from 2.10.0 I noticed that when using git log > > --oneline, if commits are signed with GPG, now the signatures are > > printed too, and it

[PATCH 3/3] gitweb: Link to "git describe"'d commits in log messages

Change the log formatting function to know about "git describe" output like v2.8.0-4-g867ad08 in addition to just plain 867ad08. This also fixes a micro-regression in my change of the minimum SHA1 length from 8 to 7, which is that dated tags like hadoop-20160921-113441-20-g094fb7d w

[PATCH 2/3] gitweb: Link to 7-character SHA1SUMS in commit messages

Change the minimum length of a commit we'll link to from 8 to 7. This arbitrary minimum length of 8 was introduced in v1.4.4.2-151-gbfe2191, but as seen in e.g. v1.7.4-1-gdce9648 the default abbreviation length is 7. It's still possible to reference SHA1s down to 4 characters in length, see

[PATCH 1/3] gitweb: Fix an ancient typo in v1.7.7-rc1-1-g0866786

The Content-Type is application/xhtml+xml, not application/xhtm+xml. --- gitweb/gitweb.perl | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl index 33d701d..9473daf 100755 --- a/gitweb/gitweb.perl +++ b/gitweb/gitweb.perl @@ -1616,7

[PATCH v2 1/3] init: correct re-initialization from a linked worktree

When 'git init' is called from a linked worktree, we treat '.git' dir (which is $GIT_COMMON_DIR/worktrees/something) as the main '.git' (i.e. $GIT_COMMON_DIR) and populate the whole repository skeleton in there. It does not harm anything (*) but it is still wrong. Since 'git init' calls

[PATCH v2 2/3] init: do not set core.worktree more often than necessary

When "git init" is called with GIT_WORK_TREE environment set, we want to keep this worktree's location in core.worktree so the user does not have to set the environment again and again. See ef6f0af (git-init: set core.worktree if GIT_WORK_TREE is specified - 2007-07-04) We detect that by this

[PATCH v2 3/3] init: reuse original_git_dir in set_git_dir_init()

Since original_git_dir is a copy of real_path(git_dir), let's reuse it and avoid calling real_path() more than necessary. The xstrdup() is removed too because original_git_dir is already a copy, and we're not going to free git_link in this code probably forever. Signed-off-by: Nguyễn Thái Ngọc

  1   2   >