Re: Draft of Git Rev News edition 18

On Mon, Aug 15, 2016 at 1:10 AM, Eric Wong wrote: > Philip Oakley wrote: >> From: "Christian Couder" >> >You can also reply to this email. >> >> I see you mention in passing (weel in the small headings near the bottom) >> that

Re: Draft of Git Rev News edition 18

On Sun, Aug 14, 2016 at 10:58 PM, Junio C Hamano wrote: > Christian Couder writes: > >> You can also reply to this email. > > I am not sure that is to be recommended, as that ends up going to > the list, but anyway, these > > - Michael's "finding

Re: storing cover letter of a patch series?

On Sun, Aug 14, 2016 at 12:15 AM, Jacob Keller wrote: > On Sat, Aug 13, 2016 at 1:49 AM, Duy Nguyen wrote: >> On Tue, Aug 9, 2016 at 12:27 AM, Stefan Beller wrote: >>> is what you want. Maybe we want to see a patch that adds the

Re: storing cover letter of a patch series?

On Sun, Aug 14, 2016 at 11:28 PM, Stefan Beller wrote: > I would imagine this is similar to the pull requests on the linux > mailing list, i.e. > how it is with merges. Back in the time we did not open the editor for you to > talk about the merge you just did, and then we

Re: storing cover letter of a patch series?

On Sun, Aug 14, 2016 at 11:49 PM, Stefan Beller wrote: > On Sun, Aug 14, 2016 at 11:38 PM, Jacob Keller wrote: >> On Sun, Aug 14, 2016 at 11:28 PM, Stefan Beller wrote: >>> I would imagine this is similar to the pull requests on

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

> Is there a case where the compaction heuristic produces a better result > than this indent heuristic? AFAICT, you have not found one, and I'd be > surprised if there is one, because this _seems_ like a superset > generally. I suppose there is always the possibility that the empirical > knobs

[PATCH 1/1] do not add common-main to lib

From: Christian Hesse Commit 08aade70 (mingw: declare main()'s argv as const) changed declaration of main function. This breaks linking external projects (e.g. cgit) to libgit.a with: error: Multiple definition of `main' So do not add common-main to lib and let projects have

Re: storing cover letter of a patch series?

On Sun, Aug 14, 2016 at 11:38 PM, Jacob Keller wrote: > On Sun, Aug 14, 2016 at 11:28 PM, Stefan Beller wrote: >> I would imagine this is similar to the pull requests on the linux >> mailing list, i.e. >> how it is with merges. Back in the time we did

Re: storing cover letter of a patch series?

On Mon, Aug 15, 2016 at 1:28 PM, Stefan Beller wrote: > On Sun, Aug 14, 2016 at 12:15 AM, Jacob Keller wrote: >> On Sat, Aug 13, 2016 at 1:49 AM, Duy Nguyen wrote: >>> On Tue, Aug 9, 2016 at 12:27 AM, Stefan Beller

Re: [PATCH] difftool: always honor "command not found" exit code

Would it be possible to also treat signals (128 and above) as 'special' values as well (as I've seen some merge tools self destruct like that from time to time) - Original Message - From: gits...@pobox.com To: j...@keeping.me.uk Cc: Tom Tanner (BLOOMBERG/ LONDON), dav...@gmail.com,

Git shallow clone branch doesn't work with recursive submodules cloning

Hi, I am trying clone repository by tag with recursive submodules init, but for one submodule it doesn't work. What I'm doing wrong? >git clone https://github.com/grpc/grpc.git --recursive --depth 1 dsad5 Cloning into 'dsad5'... remote: Counting objects: 7475, done. remote: Compressing objects:

Re: [PATCH v2] help: make option --help open man pages only for Git commands

From: "Ralf Thielow" If option --help is passed to a Git command, we try to open the man page of that command. However, we do it even for commands we don't know. Make sure the command is known to Git before try to open the man page. If we don't know the command, give

Re: [PATCH 1/1] do not add common-main to lib

On Mon, Aug 15, 2016 at 09:52:07AM +0200, Christian Hesse wrote: > From: Christian Hesse > > Commit 08aade70 (mingw: declare main()'s argv as const) changed > declaration of main function. This breaks linking external projects > (e.g. cgit) to libgit.a with: > > error: Multiple

Re: Git shallow clone branch doesn't work with recursive submodules cloning

On Mon, Aug 15, 2016 at 02:20:27PM +0300, Arkady Shapkin wrote: > I am trying clone repository by tag with recursive submodules init, > but for one submodule it doesn't work. > What I'm doing wrong? Nothing. See 18a74a0 (clone: do not let --depth imply --shallow-submodules, 2016-06-19). > >git

Re: Minor bug: git config ignores empty sections

On Sun, Aug 14, 2016 at 09:29:27PM -0400, Eli Barzilay wrote: > Looks like there's a problem with setting a config with an empty > section, making it create a new section. The result is: > > $ git --version > git version 2.9.2 > $ git init > Initialized empty Git repository in

Re: [PATCH] make rebase respect core.hooksPath if set

Hi ryenus, On Sun, 14 Aug 2016, ryenus wrote: > when looking for pre-rebase and post-rewrite hooks, git-rebase > only looks for hooks dir using `git rev-parse --git-path hooks`, > which didn't consider the path overridden by core.hooksPath. Would it not be more appropriate to teach --git-path

Re: storing cover letter of a patch series?

From: "Duy Nguyen" On Mon, Aug 15, 2016 at 1:28 PM, Stefan Beller wrote: On Sun, Aug 14, 2016 at 12:15 AM, Jacob Keller wrote: On Sat, Aug 13, 2016 at 1:49 AM, Duy Nguyen wrote: On Tue, Aug 9, 2016 at 12:27

Re: [PATCH] rev-parse: respect core.hooksPath in --git-path

On Mon, Aug 15, 2016 at 02:43:18PM +0200, Johannes Schindelin wrote: > The idea of the --git-path option is not only to avoid having to > prefix paths with the output of --git-dir all the time, but also to > respect overrides for specific common paths inside the .git directory > (e.g. `git

Re: Getting the "message" given a branch designation and conversely

On Sun, Aug 14, 2016 at 07:58:14AM -0700, n...@dad.org wrote: > I am learning how to use git. I would like to know how: > > Given a branch's designation, such as "master~4", how can I see the message I > furnished when I created the branch using "git commit"? Somebody already pointed you at

Re: Git shallow clone branch doesn't work with recursive submodules cloning

Thank you, after updating to "2.9.3.windows.1" options "--recursive --depth 1" now works. But "--recursive --shallow-submodules" and "--recursive --shallow-submodules --depth 1" still doesn't work. 2016-08-15 15:04 GMT+03:00 Jeff King : > On Mon, Aug 15, 2016 at 02:20:27PM +0300,

Re: storing cover letter of a patch series?

On Mon, Aug 15, 2016 at 7:37 PM, Philip Oakley wrote: > I appreciate there has been a lot of discussion, but it mainly appears to be > about an upstream / integration viewpoint. > > I'd hate it if there was a one size fits all solution that was only focused > on one

Re: [ANNOUNCE] Git v2.10.0-rc0

On 15.08.16 00:47, Junio C Hamano wrote: > Torsten Bögershausen (1): > convert: unify the "auto" handling of CRLF Should we mention this change in the release notes? The handling of "*.text = auto" was changed, and now $ echo "* text=auto eol=crlf" >.gitattributes has the same

Re: Git shallow clone branch doesn't work with recursive submodules cloning

On Mon, Aug 15, 2016 at 03:29:14PM +0300, Arkady Shapkin wrote: > Thank you, after updating to "2.9.3.windows.1" options "--recursive > --depth 1" now works. > > But "--recursive --shallow-submodules" and "--recursive > --shallow-submodules --depth 1" still doesn't work. It does "work", but the

Re: Git shallow clone branch doesn't work with recursive submodules cloning

So it will work only if github update their server configuration (boringssl submodule on github)? 2016-08-15 15:47 GMT+03:00 Jeff King : > On Mon, Aug 15, 2016 at 03:29:14PM +0300, Arkady Shapkin wrote: > >> Thank you, after updating to "2.9.3.windows.1" options "--recursive >>

Re: Git shallow clone branch doesn't work with recursive submodules cloning

On Mon, Aug 15, 2016 at 03:53:48PM +0300, Arkady Shapkin wrote: > So it will work only if github update their server configuration > (boringssl submodule on github)? Correct. -Peff -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to

Re: [PATCH v6 00/12] Update git revisions

On 2016-08-12 07:45 PM, Philip Oakley wrote: These are the quick fixes to Marc's comments to patches 5,6,11, and a consequential change to 12. Only the changed patches are included. Looks good to me -- no further comments! However, I still don't understand why git says 11/12 has "indent with

Re: [PATCH v6 00/12] Update git revisions

From: "Marc Branchaud" On 2016-08-12 07:45 PM, Philip Oakley wrote: These are the quick fixes to Marc's comments to patches 5,6,11, and a consequential change to 12. Only the changed patches are included. Looks good to me -- no further comments! However, I still don't

[PATCH] rev-parse: respect core.hooksPath in --git-path

The idea of the --git-path option is not only to avoid having to prefix paths with the output of --git-dir all the time, but also to respect overrides for specific common paths inside the .git directory (e.g. `git rev-parse --git-path objects` will report the value of the environment variable

[PATCH] t/Makefile: make sure that file names are truly platform-independent

Some file names that are okay on ext4 and on HFS+ are illegal in Windows. In order to stay truly platform-independent, Git's source code must not contain such illegal file names, even if things just happen to work on Linux. One such file name was recently introduced into Git's `pu` branch:

Re: [PATCH 1/1] do not add common-main to lib

Hi Christian, On Mon, 15 Aug 2016, Christian Hesse wrote: > From: Christian Hesse > > Commit 08aade70 (mingw: declare main()'s argv as const) changed > declaration of main function. This breaks linking external projects > (e.g. cgit) to libgit.a with: > > error: Multiple

Re: [PATCH] squash! diff: add --diff-line-prefix option for passing in a prefix

Hi Junio, On Sun, 14 Aug 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > - test=$(echo "$cmd" | sed -e 's|[/ ][/ ]*|_|g') > > + test=$(echo "$cmd" | sed -e 's|[/ ][/ ]*|_|g' -e 'y/>/_/') > > The existing sed scriptlet says "we cannot have slash

[L10N] Kickoff of translation for Git 2.10.0 round 1

Hi, Git v2.10.0-rc0 has been released, and it's time to start new round of git l10n. This time there are 248 updated messages need to be translated since last update: l10n: git.pot: v2.10.0 round 1 (248 new, 56 removed) Generate po/git.pot from v2.10.0-rc0 for git v2.10.0 l10n round 1.

Re: [PATCH 1/1] do not add common-main to lib

Johannes Schindelin on Mon, 2016/08/15 14:20: > Hi Christian, > > On Mon, 15 Aug 2016, Christian Hesse wrote: > > > From: Christian Hesse > > > > Commit 08aade70 (mingw: declare main()'s argv as const) changed > > declaration of main function. This

Re: [PATCH] make rebase respect core.hooksPath if set

On Mon, Aug 15, 2016 at 02:24:59PM +0200, Johannes Schindelin wrote: > > when looking for pre-rebase and post-rewrite hooks, git-rebase > > only looks for hooks dir using `git rev-parse --git-path hooks`, > > which didn't consider the path overridden by core.hooksPath. > > Would it not be more

Re: [PATCH 1/1] do not add common-main to lib

Jeff King on Mon, 2016/08/15 08:02: > On Mon, Aug 15, 2016 at 09:52:07AM +0200, Christian Hesse wrote: > > > From: Christian Hesse > > > > Commit 08aade70 (mingw: declare main()'s argv as const) changed > > declaration of main function. This breaks linking

Re: storing cover letter of a patch series?

On Mon, Aug 15, 2016 at 08:30:03PM +0700, Duy Nguyen wrote: > On Mon, Aug 15, 2016 at 7:37 PM, Philip Oakley wrote: > > I appreciate there has been a lot of discussion, but it mainly appears to be > > about an upstream / integration viewpoint. > > > > I'd hate it if there

Re: storing cover letter of a patch series?

On Mon, Aug 15, 2016 at 8:45 PM, Duy Nguyen wrote: > On Tue, Aug 16, 2016 at 3:46 AM, Philip Oakley wrote: >> From: "Jacob Keller" >> [nip] I've no problem with more extensive methods for those preparing very big

Re: storing cover letter of a patch series?

On Tue, Aug 16, 2016 at 3:46 AM, Philip Oakley wrote: > From: "Jacob Keller" > [nip] >>> >>> >>> I've no problem with more extensive methods for those preparing very big >>> patch series, or with those needing to merge together a lot of series and

Re: Minor bug: git config ignores empty sections

On Mon, Aug 15, 2016 at 2:55 PM, Jeff King wrote: > On Mon, Aug 15, 2016 at 11:28:20AM -0700, Junio C Hamano wrote: > >> I notice that we have thought about all the issues when we last >> discussed it in 2013. Refining a message from the earlier thread, >> as it illustrates tricky

Re: [PATCH v5 2/3] diff: add --diff-line-prefix option for passing in a prefix

Jacob Keller writes: > I will look more into how to do the log version tomorrow, if I am > still stuck I will re-work the patches as you suggest here. > > I am hoping I can find a good solution for how to handle it though. Thanks, I am hoping the same, too ;-) -- To

Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

Johannes Schindelin writes: > Some file names that are okay on ext4 and on HFS+ are illegal in > Windows. In order to stay truly platform-independent, Git's source code > must not contain such illegal file names, even if things just happen to > work on Linux. Good

Re: [PATCH] squash! diff: add --diff-line-prefix option for passing in a prefix

Johannes Schindelin writes: > On Sun, 14 Aug 2016, Junio C Hamano wrote: > >> Johannes Schindelin writes: >> >> > - test=$(echo "$cmd" | sed -e 's|[/ ][/ ]*|_|g') >> > + test=$(echo "$cmd" | sed -e 's|[/ ][/ ]*|_|g' -e 'y/>/_/') >> ...

BUG: indent-with-non-tab always on (was: Re: [PATCH v6 00/12] Update git revisions)

On 2016-08-15 11:00 AM, Philip Oakley wrote: From: "Marc Branchaud" On 2016-08-12 07:45 PM, Philip Oakley wrote: These are the quick fixes to Marc's comments to patches 5,6,11, and a consequential change to 12. Only the changed patches are included. Looks good to me

Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

Junio C Hamano writes: > Johannes Schindelin writes: > >> Some file names that are okay on ext4 and on HFS+ are illegal in >> Windows. In order to stay truly platform-independent, Git's source code >> must not contain such illegal file names, even

Re: [PATCH 1/3] diff-highlight: add some tests.

Brian Henderson writes: > On Wed, Aug 10, 2016 at 08:56:35AM +, Eric Wong wrote: > > > >> Typically, we expect a reroll in a few days, and I guess there's >> no rush (so you can squash your comment patch in addressing >> Junio's concern into 3/3). >> >> Thanks. > >

Re: [PATCH 1/3] diff-highlight: add some tests.

On Wed, Aug 10, 2016 at 08:56:35AM +, Eric Wong wrote: > Typically, we expect a reroll in a few days, and I guess there's > no rush (so you can squash your comment patch in addressing > Junio's concern into 3/3). > > Thanks. thanks, (slowly) working on an update. -- To unsubscribe from

Re: [PATCH 1/3] diff-highlight: add some tests.

> On 30 Jul 2016, at 17:11, Brian Henderson wrote: > > --- > contrib/diff-highlight/Makefile | 5 ++ > contrib/diff-highlight/t/Makefile| 19 +++ > contrib/diff-highlight/t/t9400-diff-highlight.sh | 63 ++ >

Re: [ANNOUNCE] Git v2.10.0-rc0

Torsten Bögershausen writes: > On 15.08.16 00:47, Junio C Hamano wrote: >> Torsten Bögershausen (1): >> convert: unify the "auto" handling of CRLF > > Should we mention this change in the release notes? > > The handling of "*.text = auto" was changed, and now > > $ echo

Re: [PATCH v6 00/12] Update git revisions

Marc Branchaud writes: > On 2016-08-12 07:45 PM, Philip Oakley wrote: >> These are the quick fixes to Marc's comments to patches 5,6,11, >> and a consequential change to 12. >> >> Only the changed patches are included. > > Looks good to me -- no further comments! > >

Re: [PATCH v1 3/3] doc: rebase: clarify fixup! fixup! constraint

"Philip Oakley" writes: >> I think this is about > > Yes, but the original wording didn't make me think that. Yeah, it is very plausible that it is not limited to you, and I agree that it is worthwhile to update the description around here. >>> Also, does 'earliest commit

Re: Minor bug: git config ignores empty sections

On Aug 15 2016, Jeff King wrote: > And implicit in your test is the other bug, which is that deleting the > last key in a section leaves the empty header. I think it's related to > the same issue. Indiscriminately removing empty section headers may break comments that have been

Re: Draft of Git Rev News edition 18

W dniu 14.08.2016 o 23:10, Philip Oakley pisze: > From: "Christian Couder" >> >> A draft of a new Git Rev News edition is available here: >> >> >> https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-18.md >> >> Everyone is welcome to contribute in

Re: Minor bug: git config ignores empty sections

On Mon, Aug 15, 2016 at 07:34:50PM +0200, Andreas Schwab wrote: > On Aug 15 2016, Jeff King wrote: > > > And implicit in your test is the other bug, which is that deleting the > > last key in a section leaves the empty header. I think it's related to > > the same issue. > >

Re: Draft of Git Rev News edition 18

W dniu 15.08.2016 o 20:08, Jakub Narębski pisze: [...] > Additional references / information: > > * "Alternatives to mid.gmane.org?" thread, starting with > Message-Id: <481d1ee2-6a66-418f-ab28-95947bbf3...@gmail.com> > > Mentions a few alternatives besides public-inbox: > >

[PATCH 1/2] advice: preset advice preferences to -1

In the next patch we want to make a distinction if a the advice was requested explicitly or is set implicit. To do that we need to have different values for the default and a value that is set explicitly. Signed-off-by: Stefan Beller --- advice.c | 30

[PATCH 2/2] checkout: do not mention detach advice for explicit --detach option

When a user asked for a detached HEAD specifically with `--detach`, we do not need to give advice on what a detached HEAD state entails as we can assume they know what they're getting into as they asked for it. Signed-off-by: Stefan Beller --- Junio writes: > It might be

Re: [PATCH 2/2] checkout: do not mention detach advice for explicit --detach option

On Mon, Aug 15, 2016 at 11:40:21AM -0700, Stefan Beller wrote: > When a user asked for a detached HEAD specifically with `--detach`, > we do not need to give advice on what a detached HEAD state entails as > we can assume they know what they're getting into as they asked for it. > >

Re: [PATCHv4 5/8] clone: factor out checking for an alternate path

On Fri, Aug 12, 2016 at 3:25 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> + struct strbuf sb = STRBUF_INIT; >> + char *ref_git = compute_alternate_path(item->string, ); > > Who owns the memory for ref_git? The caller of

Re: [PATCH 2/2] checkout: do not mention detach advice for explicit --detach option

On Mon, Aug 15, 2016 at 11:54:53AM -0700, Stefan Beller wrote: > > SoI guess. But has anybody in the history of git ever explicitly > > configured advice.* to true? > > An admin/teacher of a university that wants to teach Git to students > in a class? Better be safe than sorry and explicitly

Re: [PATCH v2] help: make option --help open man pages only for Git commands

"Philip Oakley" writes: > I'm still not sure this is enough. One of the problems back when I > introduced the --guides option (65f9835 (builtin/help.c: add --guide > option, 2013-04-02)) was that we had no easy way of determining what > guides were available, especially

Re: [ANNOUNCE] git-series: track changes to a patch series over time

Hi Josh, On 1 August 2016 at 12:37, Josh Triplett wrote: > On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote: >> On 07/29/2016 12:40 AM, Josh Triplett wrote: >> > I'd like to announce a project I've been working on for a while: >> > >> > git-series provides a

Re: [PATCH 2/2] checkout: do not mention detach advice for explicit --detach option

On Mon, Aug 15, 2016 at 11:47 AM, Jeff King wrote: > On Mon, Aug 15, 2016 at 11:40:21AM -0700, Stefan Beller wrote: > >> When a user asked for a detached HEAD specifically with `--detach`, >> we do not need to give advice on what a detached HEAD state entails as >> we can assume

Re: Minor bug: git config ignores empty sections

On Mon, Aug 15, 2016 at 11:28:20AM -0700, Junio C Hamano wrote: > Jeff King writes: > > > On Mon, Aug 15, 2016 at 07:34:50PM +0200, Andreas Schwab wrote: > > > >> On Aug 15 2016, Jeff King wrote: > >> > >> > And implicit in your test is the other bug, which is

Re: Minor bug: git config ignores empty sections

On Aug 15 2016, Junio C Hamano wrote: > If we were to remove the section header at this point, we should > be removing the comment two out of three cases. > > - if it is about section.key, it should go when section.key goes. > - if it is about section, it should go when

Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

On Mon, Aug 15, 2016 at 09:57:52AM -0700, Junio C Hamano wrote: > I wonder if we already have a good mechanism to allow a project and > its participants (say, "me") to declare "in this project, pathnames > must conform to this rule" and help them avoid creating a tree that > violates the rule

Re: Minor bug: git config ignores empty sections

Eli Barzilay writes: > Looks like there's a problem with setting a config with an empty > section, making it create a new section. The result is: Thanks; this unfortunately is a well-known issue, that once was even (supposed to be) a part of GSoC project but hasn't been

Re: BUG: indent-with-non-tab always on

On 2016-08-15 12:55 PM, Marc Branchaud wrote: On 2016-08-15 11:00 AM, Philip Oakley wrote: From: "Marc Branchaud" On 2016-08-12 07:45 PM, Philip Oakley wrote: These are the quick fixes to Marc's comments to patches 5,6,11, and a consequential change to 12. Only the

Re: Minor bug: git config ignores empty sections

Jeff King writes: > On Mon, Aug 15, 2016 at 07:34:50PM +0200, Andreas Schwab wrote: > >> On Aug 15 2016, Jeff King wrote: >> >> > And implicit in your test is the other bug, which is that deleting the >> > last key in a section leaves the empty header. I think

Re: [PATCH] submodule: mark a file-local symbol as static

On Sat, Aug 13, 2016 at 7:31 AM, Ramsay Jones wrote: > > Signed-off-by: Ramsay Jones > --- > > Hi Stefan, > > If you need to re-roll your 'sb/submodule-clone-rr' branch, could > you please squash this into the relevant patch (commit

[RFC/PATCH 3/3] receive-pack: allow a maximum input size to be specified

From: Jeff King Receive-pack feeds its input to either index-pack or unpack-objects, which will happily accept as many bytes as a sender is willing to provide. Let's allow an arbitrary cutoff point where we will stop writing bytes to disk. What has already been written to disk

[RFC/PATCH 2/3] unpack-objects: add --max-input-size= option

When receiving a pack-file, it can be useful to abort the `git unpack-objects`, if the pack-file is too big. Signed-off-by: Christian Couder --- builtin/unpack-objects.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/builtin/unpack-objects.c

[RFC/PATCH 1/3] index-pack: add --max-input-size= option

From: Jeff King When receiving a pack-file, it can be useful to abort the `git index-pack`, if the pack-file is too big. Signed-off-by: Jeff King Signed-off-by: Christian Couder --- builtin/index-pack.c | 5 + 1 file changed, 5

Re: [PATCH 2/2] checkout: do not mention detach advice for explicit --detach option

Jeff King writes: > I don't think doing it this way is _wrong_. It just feels sort of > pointlessly over-engineered. It's also a little weird that all of the: > > if (advice_foo) > > will trigger because "advice_foo" is set to -1. I think it does the > right thing, but it feels

[RFC/PATCH 0/3] limit the size of the packs we receive

In https://public-inbox.org/git/20150612182045.GA23698%40peff.net/, Peff sent a patch that is used by GitHub to abort `git receive-pack` when the size of the pack we receive is bigger than a configured limit. GitLab is interested in using the same approach and in standardizing the error messages

Re: storing cover letter of a patch series?

On Mon, Aug 15, 2016 at 5:37 AM, Philip Oakley wrote: > [sorry if this is not the right place to 'drop in'..] > I appreciate there has been a lot of discussion, but it mainly appears to be > about an upstream / integration viewpoint. > > I'd hate it if there was a one size

Re: git-mergetool reverse file ordering

> Thoughts? Would you be interested in helping work up a patch > for this idea? At a minimum we should also write a test case in > t/t7610-mergetool.sh to verify that it works as advertised. > Why not reuse the existing diff.orderFile config variable? (Also > supported by the -O option to

Re: [GSOC Update] Week 15

From: Pranit Bauva Subject: [GSOC Update] Week 15 === SUMMARY == My public git.git is available here[1]. I regularly keep pushing my work so anyone interested can track me there. Feel free to participate in the discussions going on PRs with my

Re: storing cover letter of a patch series?

Jacob Keller writes: > Some people have suggested this simple idea, and I like it, but they > did mention that modifying the cover letter now requires a rebase over > a potentially large series of patches, which can get annoying. That can be simply solved by keeping the

Re: [PATCHv4 5/8] clone: factor out checking for an alternate path

Stefan Beller writes: > On Fri, Aug 12, 2016 at 3:25 PM, Junio C Hamano wrote: >> Stefan Beller writes: >> >>> + struct strbuf sb = STRBUF_INIT; >>> + char *ref_git = compute_alternate_path(item->string, ); >> >> Who owns the

Re: [PATCH 2/2] checkout: do not mention detach advice for explicit --detach option

On Mon, Aug 15, 2016 at 02:10:36PM -0700, Junio C Hamano wrote: > > Guilty as charged. I do agree that this is over-engineered. > > Let's discard 1/2 and amend 2/2 with this incremental. Looks good (though I really am OK the other way if people feel strongly). > diff --git

Re: [PATCH 2/2] checkout: do not mention detach advice for explicit --detach option

On Mon, Aug 15, 2016 at 2:10 PM, Junio C Hamano wrote: > Junio C Hamano writes: > >> Jeff King writes: >> >>> I don't think doing it this way is _wrong_. It just feels sort of >>> pointlessly over-engineered. It's also a little weird that all

Re: [PATCH] difftool: always honor "command not found" exit code

On Mon, Aug 15, 2016 at 01:21:22PM -0700, Junio C Hamano wrote: > "Tom Tanner (BLOOMBERG/ LONDON)" writes: > > > From: gits...@pobox.com > > To: j...@keeping.me.uk > > Cc: Tom Tanner (BLOOMBERG/ LONDON), dav...@gmail.com, git@vger.kernel.org > > At: 08/14/16 04:21:18 > >

Re: [PATCH] difftool: always honor "command not found" exit code

"Tom Tanner (BLOOMBERG/ LONDON)" writes: > From: gits...@pobox.com > To: j...@keeping.me.uk > Cc: Tom Tanner (BLOOMBERG/ LONDON), dav...@gmail.com, git@vger.kernel.org > At: 08/14/16 04:21:18 > > John Keeping writes: > ... >> POSIX specifies 127 as

Re: [PATCH 8/8] diff: improve positioning of add/delete blocks in diffs

Stefan Beller writes: > Maybe we can enable Michaels heuristic with the same > config/command line flag, i.e. "the flag changes its algorithm"? I think that is a very sensible proposal. After all, the name diff.compactionHeuristic only tells us what part of the diff process

Re: Minor bug: git config ignores empty sections

Jeff King writes: >> So a comment outside [section "name"] is tricky; it needs some >> mechanism (or convention) to tell us if it is about the particular >> section, or it is about the location in the configuration file. > > Keep in mind that even "outside" is hard, because

Re: [PATCHv4 5/8] clone: factor out checking for an alternate path

On Mon, Aug 15, 2016 at 1:36 PM, Junio C Hamano wrote: > >>> Why do you need "err_buf", instead of directly writing the error to >>> "err", especially if "err" is not optional? >>> + ... +out: + if (err_buf.len) { >> >> If we were directly writing to err, we

[PATCH v2] difftool: always honor fatal error exit codes

At the moment difftool's "trust exit code" logic always suppresses the exit status of the diff utility we invoke. This is useful because we don't want to exit just because diff returned "1" because the files differ, but it's confusing if the shell returns an error because the selected diff

[PATCH v6 3/3] diff: add SUBMODULE_DIFF format to display submodule diff

From: Jacob Keller Teach git-diff and friends a new format for displaying the difference of a submodule using git-diff inside the submodule project. This allows users to easily see exactly what source changed in a given commit that updates the submodule pointer. To do

[PATCH v6 1/3] diff.c: remove output_prefix_length field

From: Junio C Hamano "diff/log --stat" has a logic that determines the display columns available for the diffstat part of the output and apportions it for pathnames and diffstat graph automatically. 5e71a84a (Add output_prefix_length to diff_options, 2012-04-16) added the

[PATCH v6 2/3] graph: add support for --line-prefix on all graph-aware output

From: Jacob Keller Add an extension to git-diff and git-log (and any other graph-aware displayable output) such that "--line-prefix=" will print the additional line-prefix on every line of output. To make this work, we have to fix a few bugs in the graph API that force

[PATCH v6 0/3] Add support for displaying submodules as a proper diff

From: Jacob Keller This patch series adds support for displaying a submodule as a difference between the pre and post commits. This allows projects who frequently update submodule contents to view the submodule in the log as if it were just one squashed commit that

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Mon, Aug 15, 2016 at 12:17:11PM -0600, Simon Glass wrote: > On 1 August 2016 at 12:37, Josh Triplett wrote: > > On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote: > >> On 07/29/2016 12:40 AM, Josh Triplett wrote: > >> > I'd like to announce a project I've

Re: [RFC/PATCH 1/3] index-pack: add --max-input-size= option

On Mon, Aug 15, 2016 at 09:57:27PM +0200, Christian Couder wrote: > From: Jeff King > > When receiving a pack-file, it can be useful to abort the > `git index-pack`, if the pack-file is too big. Not much rationale here. I guess because it is all in the 3rd patch, which ties it

Re: [RFC/PATCH 2/3] unpack-objects: add --max-input-size= option

On Mon, Aug 15, 2016 at 09:57:28PM +0200, Christian Couder wrote: > When receiving a pack-file, it can be useful to abort the > `git unpack-objects`, if the pack-file is too big. > > Signed-off-by: Christian Couder Same remarks here as on the last patch, including

Re: [PATCH v2] help: make option --help open man pages only for Git commands

From: "Junio C Hamano" "Philip Oakley" writes: I'm still not sure this is enough. One of the problems back when I introduced the --guides option (65f9835 (builtin/help.c: add --guide option, 2013-04-02)) was that we had no easy way of determining what

Re: [RFC/PATCH 3/3] receive-pack: allow a maximum input size to be specified

On Mon, Aug 15, 2016 at 09:57:29PM +0200, Christian Couder wrote: > From: Jeff King > > Receive-pack feeds its input to either index-pack or > unpack-objects, which will happily accept as many bytes as > a sender is willing to provide. Let's allow an arbitrary > cutoff point

Re: storing cover letter of a patch series?

From: "Jacob Keller" [nip] I've no problem with more extensive methods for those preparing very big patch series, or with those needing to merge together a lot of series and want to keep the cover letters, but ensuring that a simple flow is possible should still be

Re: [PATCH] t/Makefile: make sure that file names are truly platform-independent

Junio C Hamano writes: > Good thinking. > > Some tests may have to be skipped on platforms that cannot express > certain paths, but even then they shouldn't ship a file with > pathname that cannot even be checked out (they should instead create > and use such a path, protected

Re: [PATCH 2/2] checkout: do not mention detach advice for explicit --detach option

Junio C Hamano writes: > Jeff King writes: > >> I don't think doing it this way is _wrong_. It just feels sort of >> pointlessly over-engineered. It's also a little weird that all of the: >> >> if (advice_foo) >> >> will trigger because "advice_foo" is set to

Re: [PATCH v2] difftool: always honor fatal error exit codes

John Keeping writes: > Here's what that looks like. Sounds good. It feels a bit funny to see that new mentions of $status are unquoted (which is totally valid because we know it has $? that cannot be anything other than a short decimal integer), while the one in the

  1   2   >