Re: [PATCH v8 0/9] connect: various cleanups

On Sat, May 28, 2016 at 07:02:01AM +0200, Torsten Bögershausen wrote: > On 27.05.16 23:59, Mike Hommey wrote: > > On Fri, May 27, 2016 at 04:24:20PM +0200, Torsten Bögershausen wrote: > >> On 27.05.16 04:27, Mike Hommey wrote: > >>> Changes from v7: > >>> - Fixed comments. > >>> > >>> Mike Hommey

Re: [PATCH v8 0/9] connect: various cleanups

On 27.05.16 23:59, Mike Hommey wrote: > On Fri, May 27, 2016 at 04:24:20PM +0200, Torsten Bögershausen wrote: >> On 27.05.16 04:27, Mike Hommey wrote: >>> Changes from v7: >>> - Fixed comments. >>> >>> Mike Hommey (9): All in all, a great improvement. 2 things left. - The comment about [] is now

Re: [RFC] fast-import: invalidate pack_id references after loosening

Jeff King wrote: > On Thu, May 26, 2016 at 08:02:36AM +, Eric Wong wrote: > > > > That's probably OK in practice, as I think the actual pack-write already > > > does a linear walk of the object table to generate the pack index. So > > > presumably nobody checkpoints often

Re: [PATCH v8 0/9] connect: various cleanups

On Fri, May 27, 2016 at 04:24:20PM +0200, Torsten Bögershausen wrote: > On 27.05.16 04:27, Mike Hommey wrote: > > Changes from v7: > > - Fixed comments. > > > > Mike Hommey (9): > > connect: document why we sometimes call get_port after > > get_host_and_port > > connect: call

Re: [PATCH] Documentation: add instructions to help setup gmail 2FA

On Fri, May 27, 2016 at 5:06 PM, Junio C Hamano wrote: > Michael Rappazzo writes: > >> For those who use two-factor authentication with gmail, git-send-email >> will not work unless it is setup with an app-specific password. The >> example for setting up

Re: [PATCH] Documentation: add instructions to help setup gmail 2FA

Michael Rappazzo writes: > For those who use two-factor authentication with gmail, git-send-email > will not work unless it is setup with an app-specific password. The > example for setting up git-send-email for use with gmail will now > include information on generating and

Re: [PATCH] Require 0 context lines in git-blame algorithm

David Kastrup writes: > Previously, the core part of git blame -M required 1 context line. > There is no rationale to be found in the code (one guess would be that > the old blame algorithm was unable to deal with immediately adjacent > regions), and it causes artifacts like

[PATCH] Documentation: add instructions to help setup gmail 2FA

For those who use two-factor authentication with gmail, git-send-email will not work unless it is setup with an app-specific password. The example for setting up git-send-email for use with gmail will now include information on generating and storing the app-specific password. ---

Re: [PATCH] log: document the --decorate=auto option

Thanks, both. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: [WIP-PATCH 0/2] send-email: refactor the email parser loop

Samuel GROOT wrote: > While working on the new option `quote-email`, we needed to parse an > email file. Since the work is already done, but the parsing and data > processing are in the same loop, we wanted to refactor the parser, to > make the code more

Re: t7610-mergetool.sh test failure

On Fri, May 27, 2016 at 12:58:15PM -0700, Junio C Hamano wrote: > On Fri, May 27, 2016 at 11:24 AM, Jeff King wrote: > > Which perhaps shows that maybe some people would > > see a performance regression if we moved from /tmp to a slower > > filesystem (e.g., especially people

Re: t7610-mergetool.sh test failure

On Fri, May 27, 2016 at 11:24 AM, Jeff King wrote: > Which perhaps shows that maybe some people would > see a performance regression if we moved from /tmp to a slower > filesystem (e.g., especially people whose git clone is on NFS or > something). Yup, but they would be using

Re: [PATCH v2 18/22] tests: use test_i18n* functions to suppress false positives

Vasco Almeida writes: > Às 17:08 de 27-05-2016, Junio C Hamano escreveu: >> Vasco Almeida writes: >> >>> diff --git a/t/t1307-config-blob.sh b/t/t1307-config-blob.sh >>> index 3c6791e..4079fef 100755 >>> --- a/t/t1307-config-blob.sh >>> +++

Re: [PATCH v2 18/22] tests: use test_i18n* functions to suppress false positives

Às 17:08 de 27-05-2016, Junio C Hamano escreveu: > Vasco Almeida writes: > >> diff --git a/t/t1307-config-blob.sh b/t/t1307-config-blob.sh >> index 3c6791e..4079fef 100755 >> --- a/t/t1307-config-blob.sh >> +++ b/t/t1307-config-blob.sh >> @@ -64,7 +64,7 @@

Re: [PATCH] t6030: explicitly test for bisection cleanup

Hey Christian, On Sat, May 28, 2016 at 12:30 AM, Christian Couder wrote: > On Fri, May 27, 2016 at 7:57 PM, Pranit Bauva wrote: >> >> Anyone any comments? > > Maybe you could add this patch to, or squash it into, the patch that > convert

Re: [PATCH] t6030: explicitly test for bisection cleanup

On Fri, May 27, 2016 at 7:57 PM, Pranit Bauva wrote: > > Anyone any comments? Maybe you could add this patch to, or squash it into, the patch that convert bisect_clean_state to C. Thanks, Christian. -- To unsubscribe from this list: send the line "unsubscribe git" in the

Re: [PATCH v4 2/2] rev-parse: fix some options when executed from subpath of main tree

Mike Hommey writes: > On Thu, May 26, 2016 at 07:19:16AM -0400, Michael Rappazzo wrote: >> Executing `git-rev-parse` with `--git-common-dir`, `--git-path `, >> or `--shared-index-path` from the root of the main worktree results in >> a relative path to the git dir. >> >> When

Re: [PATCH] log: document the --decorate=auto option

On 2016-05-27 11:56 AM, Ramsay Jones wrote: Signed-off-by: Ramsay Jones --- Hi Junio, While reading an email from Linus earlier (RFC: dynamic "auto" date formats), I noticed that log.decorate was being set to 'auto'. Since I didn't recall that setting (even if

Re: [PATCH] add: add --chmod=+x / --chmod=-x options

Johannes Schindelin writes: > I wonder, however, whether it would be "cleaner" to simply make this an > OPT_STRING and perform the validation after the option parsing. Yes, I think I touched on this in my comments in a bit more detail. > Hmm. This change uses up 2

Re: [PATCH] add: add --chmod=+x / --chmod=-x options

Junio C Hamano writes: > Edward Thomson writes: > >> However I do not think that this is a common enough action that it needs >> to be made automatic such that when I `git add foo.rb` it is >> automatically made executable. I think that the

Re: t7610-mergetool.sh test failure

On Thu, May 26, 2016 at 11:33:27PM -0700, Junio C Hamano wrote: > Jeff King writes: > > > The only one I can think of is that if something leaves cruft in > > $TMPDIR, it could affect later tests that want to `git add` > > indiscriminately. > > Or "git ls-files -u", "git clean",

Re: [PATCH] worktree: allow "-" short-hand for @{-1} in add command

Jordan DE GEA writes: >>> +test_expect_success '"add" using shorthand - fails when no previous >>> branch' ' >>> + test_must_fail git worktree add existing - >>> +' >> >> Just an observation, but the error message we would see here might >> be interesting. > >

Re: [PATCH] t6030: explicitly test for bisection cleanup

On Fri, May 13, 2016 at 3:44 PM, Pranit Bauva wrote: > This is not an improvement in the test coverage but it helps in making > it explicit as to know what exactly is the error as other tests are > focussed on testing other things but they do indirectly test for this. > >

Re: [PATCH] worktree: allow "-" short-hand for @{-1} in add command

Matthieu Moy writes: > Junio C Hamano writes: > >> Jordan DE GEA writes: >> >>> + branch=$(cd short-hand && git rev-parse --symbolic-full-name HEAD) && >>> + test "$branch" = refs/heads/newbranch && >>> + cd

Re: [RFC/PATCH 2/2] log: add "--no-show-signature" command line option

On Fri, May 27, 2016 at 10:37:16AM -0700, Junio C Hamano wrote: > Mehul Jain writes: > > > On Thu, May 26, 2016 at 10:52 PM, Junio C Hamano wrote: > > > >> The only reason why teaching the "--no-show-signature" option to > >> these commands is a

Re: [RFC/PATCH 2/2] log: add "--no-show-signature" command line option

Mehul Jain writes: > On Thu, May 26, 2016 at 10:52 PM, Junio C Hamano wrote: > >> The only reason why teaching the "--no-show-signature" option to >> these commands is a good idea is because it would help people who >> create an alias with

Re: [Bug?] log -p -W showing the whole file for a patch that adds to the end?

Am 26.05.2016 um 19:05 schrieb Junio C Hamano: I'd say that these patches are fine as they are, and follow-up patch for adding -W tests (instead of rerolling them) is sufficient, though. Patch 3 needs two small updates to address the char signedness issue found by Ramsay and to get rid of an

[RFC-PATCH v2 2/2] send-email: quote-email quotes the message body

Take an email message file, parse it and quote the message body. If `--compose` is set, then it will quote the message in the cover letter. Otherwise, imply `--annotate` option and put the quoted message in the first patch after the triple-dash. Signed-off-by: Tom Russello

[RFC-PATCH v2 1/2] send-email: quote-email populates the fields

Take an email message file, parse it and fill the "To", "Cc" and "In-Reply-To" fields appropriately. If `--compose` option is set, it will also fill the subject field with "Re: ['s subject]". Signed-off-by: Tom Russello Signed-off-by: Samuel Groot

[RFC-PATCH v2 0/2] send-email: new --quote-email option

Hello, With the current send-email command, you can send a series of patches "in reply to" an email. This patch adds a new option to `git send-email`, `--quote-email=` which does two things: - set fields appropriately (To, Cc, Subject, In-Reply-To) - quote the given message In

Re: [PATCH v2 00/22] i18n and test updates

Vasco Almeida writes: > Marks several messages for translation and updates tests to pass under > GETTEXT_POISON. Some tests were updated to fit previous i18n marks, others > were updated to fit marks made by these patches. Patches that only touch > test file refer to marks

Re: [PATCH v2 18/22] tests: use test_i18n* functions to suppress false positives

Vasco Almeida writes: > diff --git a/t/t1307-config-blob.sh b/t/t1307-config-blob.sh > index 3c6791e..4079fef 100755 > --- a/t/t1307-config-blob.sh > +++ b/t/t1307-config-blob.sh > @@ -64,7 +64,7 @@ test_expect_success 'parse errors in blobs are properly > attributed' ' >

Re: [PATCH v4] upload-pack.c: use of parse-options API

On Fri, May 27, 2016 at 10:16 AM, Antoine Queru wrote: > upload-pack.c: use of parse-options API Matthieu already mentioned that this should use imperative mood: upload-pack: use parse-options API > Option parsing now uses the parser API instead of a

Re: [PATCH v2 14/22] i18n: rebase-interactive: mark strings for translation

Vasco Almeida writes: >>> is_empty_commit() { >>> - tree=$(git rev-parse -q --verify "$1"^{tree} 2>/dev/null || >>> - die "$1: not a commit that can be picked") >>> - ptree=$(git rev-parse -q --verify "$1"^^{tree} 2>/dev/null || >>> + sha1=$1 >>> +

Re: RFC: new git-splice subcommand for non-interactive branch splicing

Hi Johannes, Thanks for the quick reply! Responses inline below: On Fri, May 27, 2016 at 05:27:14PM +0200, Johannes Schindelin wrote: > On Fri, 27 May 2016, Adam Spiers wrote: > > > Description > > --- > > > > git-splice(1) non-interactively splices the current branch by removing > >

Re: Small rerere in rebase regression

Am 25.05.2016 um 07:38 schrieb Johannes Schindelin: > In short: yes, the explicit `git rerere` call can be dropped, that is > essentially what I did in the rebase--helper branch. Here's a patch to do that. --- 8< --- Subject: [PATCH] rebase -i: remove an unnecessary 'rerere' invocation

Re: Advanced revision selection?

Nikolaus Rath writes: > In Mercurial, this can be done with a more verbose syntax (e.g. > "last(ancestors(tag("re:release-.*")),3) and descendants(aebeccf)" for > the above example). This has no direct equivalent in Git. A lot can be done passing options to "git rev-list" or

[PATCH] log: document the --decorate=auto option

Signed-off-by: Ramsay Jones --- Hi Junio, While reading an email from Linus earlier (RFC: dynamic "auto" date formats), I noticed that log.decorate was being set to 'auto'. Since I didn't recall that setting (even if it's easy to guess), I went looking for the

Advanced revision selection?

Hello, Is there a way to specify revision ranges that has more power than what's described in gitrevisions(7)? For example, is there a way to show "the three most recent commits preceding a tag that starts with "release-" that are also descendants of commit aebecf."? In Mercurial, this can be

Re: [PATCH] blame.c: don't drop origin blobs as eagerly

Johannes Schindelin writes: > On Fri, 27 May 2016, David Kastrup wrote: > >> pressure particularly when the history contains lots of merges from >> long-diverged branches. In practice, this optimization appears to >> behave quite benignly, > > Why not just stop here?

Re: RFC: new git-splice subcommand for non-interactive branch splicing

Hi Adam, On Fri, 27 May 2016, Adam Spiers wrote: > Description > --- > > git-splice(1) non-interactively splices the current branch by removing > a range of commits from within it and/or cherry-picking a range of > commits into it. It's essentially just a glorified wrapper around >

Re: [PATCH] blame.c: don't drop origin blobs as eagerly

Hi David, it is good practice to Cc: the original author of the code in question, in this case Junio. I guess he sees this anyway, but that is really just an assumption. On Fri, 27 May 2016, David Kastrup wrote: > When a parent blob already has chunks queued up for blaming, dropping > the blob

Re: [PATCH v4] upload-pack.c: use of parse-options API

> Subject: [PATCH v4] upload-pack.c: use of parse-options API I'd drop the "of" and say just "use parse-options API" Antoine Queru writes: > Description for --stateless-rpc and --advertise-refs come from > the commit 42526b4 (Add stateless RPC options to

[PATCH] Require 0 context lines in git-blame algorithm

Previously, the core part of git blame -M required 1 context line. There is no rationale to be found in the code (one guess would be that the old blame algorithm was unable to deal with immediately adjacent regions), and it causes artifacts like discussed in the thread

Re: [PATCH v8 0/9] connect: various cleanups

On 27.05.16 04:27, Mike Hommey wrote: > Changes from v7: > - Fixed comments. > > Mike Hommey (9): > connect: document why we sometimes call get_port after > get_host_and_port > connect: call get_host_and_port() earlier > connect: re-derive a host:port string from the separate host and

[PATCH v4] upload-pack.c: use of parse-options API

Option parsing now uses the parser API instead of a local parser. Code is now more compact. Description for --stateless-rpc and --advertise-refs come from the commit 42526b4 (Add stateless RPC options to upload-pack, receive-pack, 2009-10-30). Signed-off-by: Antoine Queru

RFC: new git-splice subcommand for non-interactive branch splicing

Hi all, I finally got around to implementing a new git subcommand which I've wanted for quite a while. I've called it git-splice. Description --- git-splice(1) non-interactively splices the current branch by removing a range of commits from within it and/or cherry-picking a range of

[WIP-PATCH 0/2] send-email: refactor the email parser loop

While working on the new option `quote-email`, we needed to parse an email file. Since the work is already done, but the parsing and data processing are in the same loop, we wanted to refactor the parser, to make the code more maintainable. This is still WIP, and one of the main issue (and we

[WIP-PATCH 1/2] send-email: create email parser subroutine

Parsing and processing in send-email is done in the same loop. To make the code more maintainable, we create two subroutines: - `parse_email` to separate header and body - `parse_header` to retrieve data from header Signed-off-by: Samuel GROOT Signed-off-by: Tom

[WIP-PATCH 2/2] send-email: use refactored subroutine to parse patches

Use the two subroutines `parse_email` and `parse_header` introduced in previous commit to parse patches. Signed-off-by: Samuel GROOT Signed-off-by: Tom RUSSELLO Signed-off-by: Matthieu MOY ---

[PATCH] blame.c: don't drop origin blobs as eagerly

When a parent blob already has chunks queued up for blaming, dropping the blob at the end of one blame step will cause it to get reloaded right away, doubling the amount of I/O and unpacking when processing a linear history. Keeping such parent blobs in memory seems like a reasonable

Re: [PATCH] mingw: make isatty() recognize MSYS2's pseudo terminals (/dev/pty*)

Hi Junio, On Thu, 26 May 2016, Junio C Hamano wrote: > Johannes Schindelin writes: > > > I do not see this patch in 'pu'... Anything I can do to get this into > > 'master' eventually? > > The reason why I left it in my inbox was because I couldn't tell if > this

[PATCH v2] worktree: allow "-" short-hand for @{-1} in add command

Since `git worktree add` uses `git checkout` when `[]` is used, and `git checkout -` is already supported, it makes sense to allow the same shortcut in `git worktree add`. Signed-off-by: Matthieu Moy Signed-off-by: Jordan DE GEA ---

Re: [PATCH] worktree: allow "-" short-hand for @{-1} in add command

>> +test_expect_success '"add" using shorthand - fails when no previous branch' >> ' >> +test_must_fail git worktree add existing - >> +' > > Just an observation, but the error message we would see here might > be interesting. Of course, that’s useful to be sure of the error, I will do in

Re: [PATCH v2 16/22] i18n: rebase-interactive: mark comments of squash for translation

Às 22:35 de 26-05-2016, Junio C Hamano escreveu: > Vasco Almeida writes: > >> Helper functions this_nth_commit_message and skip_nth_commit_message >> replace the previous method of making the comment messages (such as >> "This is the 2nd commit message:") aided by

Re: [PATCH v2 13/22] i18n: git-sh-setup.sh: mark strings for translation

Às 22:46 de 26-05-2016, Junio C Hamano escreveu: > Vasco Almeida writes: > >> > require_work_tree_exists () { >> > + program_name=$0 >> >if test "z$(git rev-parse --is-bare-repository)" != zfalse >> >then >> > - die "fatal: $0 cannot be used without a

Re: [PATCH v2 14/22] i18n: rebase-interactive: mark strings for translation

Às 22:36 de 26-05-2016, Junio C Hamano escreveu: > Vasco Almeida writes: > >> @@ -222,9 +223,10 @@ has_action () { >> } >> >> is_empty_commit() { >> -tree=$(git rev-parse -q --verify "$1"^{tree} 2>/dev/null || >> -die "$1: not a commit that can be

Re: [PATCH] worktree: allow "-" short-hand for @{-1} in add command

Junio C Hamano writes: > Jordan DE GEA writes: > >> +branch=$(cd short-hand && git rev-parse --symbolic-full-name HEAD) && >> +test "$branch" = refs/heads/newbranch && >> +cd .. > > If any of the command between "cd short-hand" and

Re: [RFC-PATCH 1/2] send-email: new option to quote an email and reply to

Samuel GROOT writes: > On 05/25/2016 08:31 PM, Matthieu Moy wrote: >> So, a possible UI would be: >> >> git send-email --in-reply-to= => just set In-Reply-To: field. >> >> git send-email --in-reply-to= => set In-Reply-To, To and Cc. >> >> git send-email

Re: t7800 test failure

David Aguilar writes: > Another alternative is that we can compile our own > "git-readlink" and "git-mktemp" programs and use those instead, > but that seems like a big maintenance burden compared to the > relative simplicity of the test-suite workarounds. Not _that_ big

Re: [PATCH] userdiff: add built-in pattern for CSS

Junio C Hamano writes: > William Duclot writes: > >> As the CSS pattern >> does not deal with letters at all it seemed sensible to me to follow >> the example of the HTML pattern, which use PATTERNS(). > > Did you notice that HTML

Re: [RFC] Triangular Workflow: user friendly full implementation

From: "Jordan DE GEA" We are working on full implementation of triangular workflow feature. For now, the main options available are: - branch..pushRemote - remote.pushDefault And only setable by hands. As it can be difficult to understand, here is what we want

Re: RFC: dynamic "auto" date formats

On Thu, May 26, 2016 at 11:53 PM, Linus Torvalds wrote: > > So I think what I really would like to see is more like a reverse > "approxidate" that gives the date in human terms. Yeah, "human" was the word I was looking for while composing my response. I am sure

Re: [PATCH] add: add --chmod=+x / --chmod=-x options

Edward Thomson writes: > However I do not think that this is a common enough action that it needs > to be made automatic such that when I `git add foo.rb` it is > automatically made executable. I think that the reduced complexity of > having a single mechanism to

Re: t7610-mergetool.sh test failure

Jeff King writes: > The only one I can think of is that if something leaves cruft in > $TMPDIR, it could affect later tests that want to `git add` > indiscriminately. Or "git ls-files -u", "git clean", etc. I'd mostly worry about a failed test in which a program dies without a

Re: [PATCH] format_commit_message: honor `color=auto` for `%C(auto)`

Jeff King writes: > I suspect Junio can just tweak that while applying, unless there's > another reason to re-roll. > > (Also for anybody watching, Ed did not just make up my signoff; I gave > it to him off-list). Understood. Thanks. -- To unsubscribe from this list: send the

Re: RFC: dynamic "auto" date formats

Linus Torvalds writes: > And no, I'm not at all sure that the 24-hour cut-off is the right > thing, but it didn't seem completely crazy either. I tend to like the > relative date format when it is "19 minutes ago" vs "2 hours ago", at > some point it's long enough

Re: [RFC/PATCH 2/2] log: add "--no-show-signature" command line option

On Thu, May 26, 2016 at 10:52 PM, Junio C Hamano wrote: > Jeff King writes: > >> On Thu, May 26, 2016 at 06:36:47PM +0530, Mehul Jain wrote: >> >>> If "log.showsignature=true", then there is no way to override it using >>> command line switch. >>> >>> Teach "git

Re: [RFC/PATCH 1/2] log: add "log.showsignature" configuration variable

On Thu, May 26, 2016 at 10:29 PM, Jeff King wrote: > On Thu, May 26, 2016 at 06:36:46PM +0530, Mehul Jain wrote: > The documentation here mentions "log" and "show". But I think this will > affect other programs, too, including "whatchanged" and "reflog". Those > ones are probably