Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path

On Fri, Jan 13, 2017 at 06:52:46PM +, Eric Wong wrote: > > If something we _use_ from a third-party is not warnings-clean, > > there is no easy way to squelch them if we use "-w", which is a > > potential downside, isn't it? I do not know how serious a problem > > it is in practice. I

merge maintaining history

History git cloned a remote repository and made many changes pushing them all to said repository over many months. The powers that be then required me to move project to new repository server did so by pushing local version to new remote saving all history! Now have to merge back to original

Re: [PATCH] submodule update: run custom update script for initial populating as well

On Fri, Jan 13, 2017 at 3:58 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> + if test "$update_module" = "merge" || >> +test "$update_module" = "rebase" || >> +test "$update_module"

Re: [PATCH] submodule update: run custom update script for initial populating as well

Stefan Beller writes: > + if test "$update_module" = "merge" || > +test "$update_module" = "rebase" || > +test "$update_module" = "none" > + then > +

Re: [PATCH 2/3] xdiff: -W: include immediately preceding non-empty lines in context

Vegard Nossum writes: > The patch will work as intended and as expected for 95% of the users out > there (javadoc, Doxygen, kerneldoc, etc. all have the comment > immediately preceding the function) and fixes a very real problem for me > (and I expect many others)

[PATCH] transport submodules: correct error message

When push.recurseSubmodules is set to "check" or "on-demand", the transport layer tries to determine if a submodule needs pushing. This check is done by walking all remote refs that are known. For remotes we only store the refs/heads/* (and tags), which doesn't include all commits. In e.g. Gerrit

Re: [PATCH] submodule update: run custom update script for initial populating as well

On Fri, Jan 13, 2017 at 3:42 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> In 1b4735d9f3 (submodule: no [--merge|--rebase] when newly cloned, >> 2011-02-17), all actions were defaulted to checkout for populating >> a submodule initially, because

Re: [PATCH] submodule update: run custom update script for initial populating as well

Stefan Beller writes: > In 1b4735d9f3 (submodule: no [--merge|--rebase] when newly cloned, > 2011-02-17), all actions were defaulted to checkout for populating > a submodule initially, because merging or rebasing makes no sense > in that situation. > > Other commands however

Re: [PATCH v2 1/2] diff --no-index: follow symlinks

Dennis Kaarsemaker writes: > Git's diff machinery does not follow symlinks, which makes sense as git > itself also does not, but stores the symlink destination. > > In --no-index mode however, it is useful for diff to to follow symlinks, > matching the behaviour of

Re: [PATCH v2 2/2] diff --no-index: support reading from pipes

Dennis Kaarsemaker writes: > + /* > + * In --no-index mode, we support reading from pipes. canon_mode, > called by > + * fill_filespec, gets confused by this and thinks we now have > subprojects. > + * Detect this and tell the rest of the diff

Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path

Junio C Hamano wrote: > Eric Wong writes: > > Junio C Hamano wrote: > >> Eric Wong writes: > >> > Pat Pannuto wrote: > >> >> You may still want the 1/2 patch in this series, just to make things > >>

Re: [PATCH 5/5] describe: teach describe negative pattern matches

Am 13.01.2017 um 07:57 schrieb Jacob Keller: On Thu, Jan 12, 2017 at 10:43 PM, Johannes Sixt wrote: When you write git log --branches --exclude=origin/* --remotes --exclude=origin/* applies only to --remotes, but not to --branches. Well for describe I don't think the

Re: [PATCH 25/27] attr: store attribute stacks in hashmap

Brandon Williams writes: > The last big hurdle towards a thread-safe API for the attribute system > is the reliance on a global attribute stack that is modified during each > call into the attribute system. > > This patch removes this global stack and instead a stack is

Re: [RFC] Add support for downloading blobs on demand

On Fri, Jan 13, 2017 at 7:52 AM, Ben Peart wrote: > > Goal > > > To be able to better handle repos with many files that any individual > developer doesn’t need it would be nice if clone/fetch only brought down > those files that were actually needed. > > To enable that,

Re: [PATCH 0/5] extend git-describe pattern matching

On Fri, Jan 13, 2017 at 10:48 AM, Junio C Hamano wrote: > Jacob Keller writes: > >> From: Jacob Keller >> >> Teach git describe and git name-rev the ability to match multiple >> patterns inclusively. Additionally, teach these

Re: [PATCH 2/3] xdiff: -W: include immediately preceding non-empty lines in context

On 13/01/2017 20:51, Junio C Hamano wrote: René Scharfe writes: That's true, but I'm not sure "non-empty line before function line" is good enough a definition for desirable lines. It wouldn't work for people who don't believe in empty lines. Or for those that put a blank line

Re: [PATCH] lib-submodule-update.sh: drop unneeded shell

Stefan Beller writes: > On Fri, Jan 13, 2017 at 11:55 AM, Junio C Hamano wrote: >> Junio C Hamano writes: >> >>> Stefan Beller writes: >>> In modern Git we prefer "git -C

Re: [PATCH] lib-submodule-update.sh: drop unneeded shell

On Fri, Jan 13, 2017 at 11:55 AM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Stefan Beller writes: >> >>> In modern Git we prefer "git -C >> as it doesn't need an extra shell. >> >> There is a matching '>'

Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path

Eric Wong writes: > Junio C Hamano wrote: >> Eric Wong writes: >> > Pat Pannuto wrote: >> >> You may still want the 1/2 patch in this series, just to make things >> >> internally consistent with "-w" vs "use warnings;"

Re: [PATCH 0/3] updates to gitk & git-gui doc now gitview has gone

Johannes Schindelin writes: >> Lets remove the reference in the gitk man page, and do some other >> fixups while in the area. > > These changes all look sensible to me. To me, too. Thanks, both.

Re: [PATCH] lib-submodule-update.sh: drop unneeded shell

Junio C Hamano writes: > Stefan Beller writes: > >> In modern Git we prefer "git -C > as it doesn't need an extra shell. > > There is a matching '>' missing. The description is correct (I am > not sure if there actually is

Re: [PATCH 2/3] xdiff: -W: include immediately preceding non-empty lines in context

René Scharfe writes: > Am 13.01.2017 um 17:15 schrieb Vegard Nossum: >> When using -W to include the whole function in the diff context, you >> are typically doing this to be able to review the change in its entirety >> within the context of the function. It is therefore almost

[PATCH] submodule update: run custom update script for initial populating as well

In 1b4735d9f3 (submodule: no [--merge|--rebase] when newly cloned, 2011-02-17), all actions were defaulted to checkout for populating a submodule initially, because merging or rebasing makes no sense in that situation. Other commands however do make sense, such as the custom command that was

Re: [PATCH] Documentation/bisect: improve on (bad|new) and (good|bad)

Christian Couder writes: > The following part of the description: > > git bisect (bad|new) [] > git bisect (good|old) [...] > > may be a bit confusing, as a reader may wonder if instead it should be: > > git bisect (bad|good) [] > git bisect (old|new) [...] > > Of

[PATCH] lib-submodule-update.sh: reduce use of subshell by using git -C

In modern Git we prefer "git -C " over "(cd )" as it doesn't need an extra shell. Signed-off-by: Stefan Beller --- t/lib-submodule-update.sh | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh

Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path

Junio C Hamano wrote: > Eric Wong writes: > > Pat Pannuto wrote: > >> You may still want the 1/2 patch in this series, just to make things > >> internally consistent with "-w" vs "use warnings;" inside git's perl > >> scripts. > > > >

Re: [PATCH 0/5] extend git-describe pattern matching

Jacob Keller writes: > From: Jacob Keller > > Teach git describe and git name-rev the ability to match multiple > patterns inclusively. Additionally, teach these commands to also accept > negative patterns to discard any refs which match. You

Re: [PATCH 2/3] xdiff: -W: include immediately preceding non-empty lines in context

On Fri, Jan 13, 2017 at 10:19 AM, René Scharfe wrote: > Am 13.01.2017 um 17:15 schrieb Vegard Nossum: >> >> When using -W to include the whole function in the diff context, you >> are typically doing this to be able to review the change in its entirety >> within the context of the

Re: [PATCH] lib-submodule-update.sh: drop unneeded shell

Stefan Beller writes: > In modern Git we prefer "git -C as it doesn't need an extra shell. There is a matching '>' missing. The description is correct (I am not sure if there actually is "preference", though), but I found the title a bit misleading.

Re: [PATCHv3 2/2] builtin/commit.c: switch to xstrfmt(), instead of snprintf,

On 01/13, Elia Pinto wrote: > In this patch, instead of using xnprintf instead of snprintf, which asserts > that we don't truncate, we are switching to dynamic allocation with > xstrfmt(), > , so we can avoid dealing with magic numbers in the code and reduce the > cognitive burden from > the

Re: [PATCH 1/2] asciidoctor: fix user-manual to be built by `asciidoctor`

Junio C Hamano writes: > ... Perhaps 1/2 posted as-is > is the best we could do within that constraint. > > Let's queue it on 'pu' and see if somebody else comes up with an > update that is more visually pleasing with both backends. ... and I noticed that I didn't get to

submodule network operations [WAS: Re: [RFC/PATCH 0/4] working tree operations: support superprefix]

This question is about networking; the patch you originally replied to was strictly about local operations in the filesystem, which is quite a difference, so let's discuss it separately. On Fri, Jan 13, 2017 at 9:56 AM, Brian J. Davis wrote: > > In response to a post at: > >

Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path

Eric Wong writes: > Pat Pannuto wrote: >> You may still want the 1/2 patch in this series, just to make things >> internally consistent with "-w" vs "use warnings;" inside git's perl >> scripts. > > No, that is a step back. "-w" affects the entire

Re: [PATCH 2/3] xdiff: -W: include immediately preceding non-empty lines in context

Am 13.01.2017 um 17:15 schrieb Vegard Nossum: When using -W to include the whole function in the diff context, you are typically doing this to be able to review the change in its entirety within the context of the function. It is therefore almost always desirable to include any comments that

[PATCH 6/6] fsck: detect trailing garbage in all object types

When a loose tree or commit is read by fsck (or any git program), unpack_sha1_rest() checks whether there is extra cruft at the end of the object file, after the zlib data. Blobs that are streamed, however, do not have this check. For normal git operations, it's not a big deal. We know the sha1

[PATCH 5/6] fsck: parse loose object paths directly

When we iterate over the list of loose objects to check, we get the actual path of each object. But we then throw it away and pass just the sha1 to fsck_sha1(), which will do a fresh lookup. Usually it would find the same object, but it may not if an object exists both as a loose and a packed

[PATCH 4/6] sha1_file: add read_loose_object() function

It's surprisingly hard to ask the sha1_file code to open a _specific_ incarnation of a loose object. Most of the functions take a sha1, and loop over the various object types (packed versus loose) and locations (local versus alternates) at a low level. However, some tools like fsck need to look

[PATCHv3 2/2] builtin/commit.c: switch to xstrfmt(), instead of snprintf,

In this patch, instead of using xnprintf instead of snprintf, which asserts that we don't truncate, we are switching to dynamic allocation with xstrfmt(), , so we can avoid dealing with magic numbers in the code and reduce the cognitive burden from the programmers, because they no longer have to

[PATCHv3 1/2] builtin/commit.c: removes the PATH_MAX limitation via dynamic allocation

This patch removes the PATH_MAX limitation from the environment setting that points to a filename, we'd want to handle larger paths anyway, so we switch to dynamic allocation. As a side effect of this patch we have also reduced the snprintf() calls, that may silently truncate results if the

Re: [PATCH 1/3] xdiff: -W: relax end-of-file function detection

Am 13.01.2017 um 17:15 schrieb Vegard Nossum: When adding a new function to the end of a file, it's enough to know that 1) the addition is at the end of the file; and 2) there is a function _somewhere_ in there. If we had simply been changing the end of an existing function, then we would also

[PATCH 3/6] t1450: test fsck of packed objects

The code paths in fsck for packed and loose objects are quite different, and it is not immediately obvious that the packed case behaves well. In particular: 1. The fsck_loose() function always returns "0" to tell the iterator to keep checking more objects. Whereas fsck_obj_buffer()

[PATCH 2/6] sha1_file: fix error message for alternate objects

When we fail to open a corrupt loose object, we report an error and mention the filename via sha1_file_name(). However, that function will always give us a path in the local repository, whereas the corrupt object may have come from an alternate. The result is a very misleading error message.

[PATCH 1/6] t1450: refactor loose-object removal

Commit 90cf590f5 (fsck: optionally show more helpful info for broken links, 2016-07-17) added a remove_loose_object() helper, but we already had a remove_object() helper that did the same thing. Let's combine these into one. The implementations had a few subtle differences, so I've tried to take

[PATCH 0/6] loose-object fsck fixes/tightening

On Fri, Jan 13, 2017 at 04:15:42AM -0500, John Szakmeister wrote: > > I did notice another interesting case when looking at this. Fsck ends up > > in fsck_loose(), which has the sha1 and path of the loose object. It > > passes the sha1 to fsck_sha1(), and ignores the path entirely! > > > > So if

Re: [RFC/PATCH 0/4] working tree operations: support superprefix

Resending original as plain text as g...@verger.kernel.org rejected HTML encoding as potential virus. Apologies for dupes in inbox. Hopefully this works. In response to a post at: https://groups.google.com/forum/#!topic/git-users/BVLcKHhSUKo I was asked to post here to explain a potential

Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path

Hi Eric, On Fri, 13 Jan 2017, Eric Wong wrote: > Johannes Schindelin wrote: > > I guess I do not understand, still, what the difference is between using > > -w and adding `use warnings` *very early* in the script... Could you give > > an example where it makes a

Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path

Johannes Schindelin wrote: > I guess I do not understand, still, what the difference is between using > -w and adding `use warnings` *very early* in the script... Could you give > an example where it makes a difference? "use warnings" won't leak across files/modules.

[PATCH 3/3] t/t4051-diff-function-context: improve tests for new diff -W behaviour

We now include non-empty lines immediately before (and after) a function as belonging to the function. We can test this new functionality by moving the "// Begin" markers on each function to the previous line. This commit is intentionally not part of the previous commits in order to show that

[PATCH 2/3] xdiff: -W: include immediately preceding non-empty lines in context

When using -W to include the whole function in the diff context, you are typically doing this to be able to review the change in its entirety within the context of the function. It is therefore almost always desirable to include any comments that immediately precede the function. This also the

[PATCH 1/3] xdiff: -W: relax end-of-file function detection

When adding a new function to the end of a file, it's enough to know that 1) the addition is at the end of the file; and 2) there is a function _somewhere_ in there. If we had simply been changing the end of an existing function, then we would also be deleting something from the old version.

[RFC] Add support for downloading blobs on demand

Goal To be able to better handle repos with many files that any individual developer doesn’t need it would be nice if clone/fetch only brought down those files that were actually needed. To enable that, we are proposing adding a flag to clone/fetch that will instruct the server to limit

[ANNOUNCE] Git for Windows 2.11.0(2)

MIME-Version: 1.0 Fcc: Sent Dear Git users, It is my pleasure to announce that Git for Windows 2.11.0(2) is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.11.0 (December 1st 2016) New Features • Reading a large index has been speeded up using

Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path

Hi Eric, On Fri, 13 Jan 2017, Eric Wong wrote: > Pat Pannuto wrote: > > You may still want the 1/2 patch in this series, just to make things > > internally consistent with "-w" vs "use warnings;" inside git's perl > > scripts. > > No, that is a step back. "-w" affects

Re: [PATCH 0/3] updates to gitk & git-gui doc now gitview has gone

Hi Philip, On Thu, 12 Jan 2017, Philip Oakley wrote: > gitview was removed recently. > > > Sent: Tuesday, January 10, 2017 11:48 PM > > Subject: What's cooking in git.git (Jan 2017, #01; Tue, 10) > > > * sb/remove-gitview (2017-01-07) 1 commit > > (merged to 'next' on 2017-01-10 at

Re: [PATCH 2/2] Use 'env' to find perl instead of fixed path

Hi Pat, On Thu, 12 Jan 2017, Pat Pannuto wrote: > You may still want the 1/2 patch in this series, just to make things > internally consistent with "-w" vs "use warnings;" inside git's perl > scripts. Yes, I like that patch. Ciao, Johannes

Re: [PATCH] Remove dependency on deprecated Net::SMTP::SSL

> On 20 Nov 2016, at 19:53, brian m. carlson > wrote: > > On Sun, Nov 20, 2016 at 04:18:16PM -0500, Mike Fisher wrote: >> Refactor send_message() to remove dependency on deprecated >> Net::SMTP::SSL: >> >>

[PATCH] Documentation/bisect: improve on (bad|new) and (good|bad)

The following part of the description: git bisect (bad|new) [] git bisect (good|old) [...] may be a bit confusing, as a reader may wonder if instead it should be: git bisect (bad|good) [] git bisect (old|new) [...] Of course the difference between "[]" and "[...]" should hint that there is a

http://www.shaperich.com/diabazole/

wrongdoing which our profoundly created society can confer against mankind? In the event that you are somebody experiencing Diabetes, then there is nobody superior to anything you who know how troublesome the life is with different confinements and diabazole

Re: gitk: "lime" color incompatible with older Tk versions

On Mon, May 02, 2016 at 09:20:43AM -0700, Stefan Beller wrote: > + Paul Mackerras, who maintains gitk > > On Sun, May 1, 2016 at 10:03 AM, Andrew Janke wrote: > > Hi, git folks, > > > > I'm having trouble running gitk on Mac OS X 10.9.5. The gitk program uses > > the color

[PATCH v2 2/2] diff --no-index: support reading from pipes

diff <(command1) <(command2) provides useful output, let's make it possible for git to do the same. Signed-off-by: Dennis Kaarsemaker --- diff-no-index.c | 8 diff.c | 13 +++-- t/t4053-diff-no-index.sh | 10 ++

[PATCH v2 0/2] diff --no-index: support symlinks and pipes

git diff <(command1) <(command2) is less useful than it could be, all it outputs is: diff --git a/dev/fd/63 b/dev/fd/62 index 9e6542b297..9f7b2c291b 12 --- a/dev/fd/63 +++ b/dev/fd/62 @@ -1 +1 @@ -pipe:[464811685] \ No newline at end of file +pipe:[464811687] \ No newline at end of file

[PATCH v2 1/2] diff --no-index: follow symlinks

Git's diff machinery does not follow symlinks, which makes sense as git itself also does not, but stores the symlink destination. In --no-index mode however, it is useful for diff to to follow symlinks, matching the behaviour of ordinary diff. A new --no-dereference (name copied from diff) option

Re: "git fsck" not detecting garbage at the end of blob object files...

On Sat, Jan 7, 2017 at 4:47 PM, Dennis Kaarsemaker wrote: > On Sat, 2017-01-07 at 07:50 -0500, John Szakmeister wrote: >> I was perusing StackOverflow this morning and ran across this >> question: >>

Re: "git fsck" not detecting garbage at the end of blob object files...

On Sun, Jan 8, 2017 at 12:26 AM, Jeff King wrote: > On Sat, Jan 07, 2017 at 10:47:03PM +0100, Dennis Kaarsemaker wrote: >> On Sat, 2017-01-07 at 07:50 -0500, John Szakmeister wrote: >> > I was perusing StackOverflow this morning and ran across this >> > question: >> >