Re: [PATCH v3 2/4] format-patch: add '--base' option to record base tree info

On Fri, Apr 01, 2016 at 09:00:20AM -0700, Junio C Hamano wrote: >Ye Xiaolong writes: > >> On Thu, Mar 31, 2016 at 10:38:04AM -0700, Junio C Hamano wrote: >> >>>The contents of this look OK, but does it format correctly via >>>AsciiDoc? I suspect that only the first

Re: [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues

On Mon, Apr 4, 2016 at 11:00 PM, Eric Sunshine wrote: > On Mon, Apr 4, 2016 at 8:45 AM, Pranit Bauva wrote: >> Okay I will do the change. I was previously unaware about the use of >> '\' before EOF. I googled it now. But I am still confused about

Re: [PATCH v4 2/6] t/t7030-verify-tag.sh: Adds validation for multiple tags

On Mon, Apr 4, 2016 at 9:46 PM, Santiago Torres wrote: > Eric Sunshine wrote: >> > +test_expect_success GPG 'verify multiple tags' ' >> > + tags="fourth-signed sixth-signed seventh-signed" && >> > + for i in $tags; do >> > + git verify-tag -v --raw $i

Re: [PATCH v4 6/6] tag.c: Change gpg_verify_tag argument to sha1

On Mon, Apr 4, 2016 at 10:10 PM, Santiago Torres wrote: > On Mon, Apr 04, 2016 at 10:00:17PM -0400, Eric Sunshine wrote: >> On Mon, Apr 4, 2016 at 6:22 PM, wrote: >> > - return gpg_verify_tag(name, GPG_VERIFY_VERBOSE); >> > + return

support block comments in gitconfig

Could we have block comments in gitconfig? It's a nice-to-have supported in most languages. eg: #{ commented out block #} or other intuitive syntax -- 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

Re: [PATCH v5 4/4] pretty: test --expand-tabs

On Mon, Apr 04, 2016 at 05:58:37PM -0700, Junio C Hamano wrote: > +count_expand () > +{ This function takes a lot of unnamed arguments that we process with "shift". It might be nice to give a brief comment describing them. > +test_expand "" > +test_expand --pretty > +test_expand --pretty=short

Re: [PATCH v4 6/6] tag.c: Change gpg_verify_tag argument to sha1

On Mon, Apr 04, 2016 at 10:00:17PM -0400, Eric Sunshine wrote: > On Mon, Apr 4, 2016 at 6:22 PM, wrote: > > tag.c: Change gpg_verify_tag argument to sha1 > > s/Change/change/ Sorry I've been consistently missing these... > > > The gpg_verify_tag function resolves the ref

Re: [PATCH v4 6/6] tag.c: Change gpg_verify_tag argument to sha1

On Mon, Apr 4, 2016 at 6:22 PM, wrote: > tag.c: Change gpg_verify_tag argument to sha1 s/Change/change/ > The gpg_verify_tag function resolves the ref for any existing object. > However, git tag -v resolves to only tag-refs. We can provide support > for sha1 by moving the

Re: [PATCH v5 4/4] pretty: test --expand-tabs

On Mon, Apr 04, 2016 at 09:10:46PM -0400, Eric Sunshine wrote: > > + count=$1 ;# expected tabs > > Why semicolon before the hash here and above? I am in the habit of doing this, too. I have a vague recollection of getting bitten by a shell that treated: echo foo # bar or something

Re: [PATCH v5 0/4] Expanding tabs in "git log" output

On Mon, Apr 04, 2016 at 05:58:33PM -0700, Junio C Hamano wrote: > So here is the fifth and hopefully the final try. Previous round > are at $gmane/289694, $gmane/289166, $gmane/288987 and > $gmane/290222. With the exception of two minor nits on the final patch, this looks good to me. Thanks for

Re: [PATCH v4 2/6] t/t7030-verify-tag.sh: Adds validation for multiple tags

> > The bulk of this description is merely repeating what the patch itself > already says, thus is redundant. The entire commit message could > probably be collapsed to: > > t7030: test verify-tag with multiple tags > > git-verify-tag accepts multiple tags as arguments, however, >

Re: [PATCH v4 5/6] tag: use pgp_verify_function in tag -v call

On Mon, Apr 04, 2016 at 09:39:29PM -0400, Eric Sunshine wrote: > On Mon, Apr 4, 2016 at 6:22 PM, wrote: > > Instead of running the verify-tag plumbing command, we use the > > pgp_verify_tag(). This avoids the usage of an extra fork call. To do > > this, we extend the number of

Re: [PATCH v4 5/6] tag: use pgp_verify_function in tag -v call

On Mon, Apr 4, 2016 at 6:22 PM, wrote: > Instead of running the verify-tag plumbing command, we use the > pgp_verify_tag(). This avoids the usage of an extra fork call. To do > this, we extend the number of parameters that tag.c takes, and > verify-tag passes. Redundant calls

Re: [PATCH v4 4/6] tag.c: Replace varialbe name for readability

On Mon, Apr 4, 2016 at 6:22 PM, wrote: > tag.c: Replace varialbe name for readability s/Replace/replace/ s/varialbe/variable/ > The run_gpg_verify function has two variables size, and len. This may > come off as confusing when reading the code. We clarify which one > pertains

Re: [PATCH v4 2/6] t/t7030-verify-tag.sh: Adds validation for multiple tags

On Mon, Apr 4, 2016 at 6:22 PM, wrote: > t/t7030-verify-tag.sh: Adds validation for multiple tags Rewrite: t7030: test verify-tag with multiple tags The leading "t/" and the trailing "-*.sh" were dropped since they add no value. > The verify-tag command supports

Re: [PATCH v5 4/4] pretty: test --expand-tabs

On Mon, Apr 4, 2016 at 8:58 PM, Junio C Hamano wrote: > The test prepares a simple commit with HT on its log message lines, > and makes sure that > > - formats that should or should not expand tabs by default do or do >not expand tabs respectively, > > - with explicit

[PATCH v5 0/4] Expanding tabs in "git log" output

So here is the fifth and hopefully the final try. Previous round are at $gmane/289694, $gmane/289166, $gmane/288987 and $gmane/290222. This round is different from v4 in the following ways. * wording changes, grammo- and typo-fixes in the documentation (thanks to Eric Sunshine and Jeff

[PATCH v5 4/4] pretty: test --expand-tabs

The test prepares a simple commit with HT on its log message lines, and makes sure that - formats that should or should not expand tabs by default do or do not expand tabs respectively, - with explicit --expand-tabs= and short-hands --expand-tabs (equivalent to --expand-tabs=8) and

[PATCH v5 3/4] pretty: allow tweaking tabwidth in --expand-tabs

When the local convention of the project is to use tab width that is not 8, it may make sense to allow "git log --expand-tabs=" to tweak the output to match it. Signed-off-by: Junio C Hamano --- Documentation/pretty-options.txt | 9 ++--- commit.h

[PATCH v5 2/4] pretty: enable --expand-tabs by default for selected pretty formats

"git log --pretty={medium,full,fuller}" and "git log" by default prepend 4 spaces to the log message, so it makes sense to enable the new "expand-tabs" facility by default for these formats. Add --no-expand-tabs option to override the new default. The change alone breaks a test in t4201 that runs

[PATCH v5 1/4] pretty: expand tabs in indented logs to make things line up properly

From: Linus Torvalds A commit log message sometimes tries to line things up using tabs, assuming fixed-width font with the standard 8-place tab settings. Viewing such a commit however does not work well in "git log", as we indent the lines by prefixing 4 spaces in

Re: [GSoC] A late proposal: a modern send-email

惠轶群 wrote: > 2016-03-28 6:00 GMT+08:00 Eric Wong : > > While Gmail provides SMTP access, it was (last I was told) > > incompatible with two-factor auth; so I've encountered users > > unable to send patches with their normal 2FA-enabled accounts. > >

Re: [PATCH v12 5/5] commit: add a commit.verbose config variable

On Sun, Apr 3, 2016 at 8:58 PM, Eric Sunshine wrote: > The fact that the 32 new tests are nearly identical suggests strongly > that the testing should instead either be table-driven or be done via > for-loops to systematically cover all cases. Not only would either of >

Re: [PATCH] git-format-patch.txt: don't show -s as shorthand for multiple options

On Mon, Apr 4, 2016 at 6:38 PM, Eric Sunshine wrote: > On Mon, Apr 4, 2016 at 4:07 PM, Junio C Hamano wrote: >> Eric Sunshine writes: Given that the ifndef/endif block immediately before this part is also about

Re: [PATCH] git-format-patch.txt: don't show -s as shorthand for multiple options

On Mon, Apr 4, 2016 at 4:07 PM, Junio C Hamano wrote: > Eric Sunshine writes: >>> Given that the ifndef/endif block immediately before this part is >>> also about excluding -p/-u/--patch when formatting the documentation >>> for format-patch, perhaps

[PATCH v4 1/6] builtin/verify-tag.c: Ignore SIGPIPE on gpg-interface

From: Santiago Torres The verify_signed_buffer comand might cause a SIGPIPE signal when the gpg child process terminates early (due to a bad keyid, for example) and git tries to write to it afterwards. Previously, ignoring SIGPIPE was done on the builtin/verify-tag.c command to

[PATCH v4 6/6] tag.c: Change gpg_verify_tag argument to sha1

From: Santiago Torres The gpg_verify_tag function resolves the ref for any existing object. However, git tag -v resolves to only tag-refs. We can provide support for sha1 by moving the refname resolution code out of gpg_verify_tag and allow for the object's sha1 as an argument.

[PATCH v4 0/6] tag: move PGP verification code to tag.c

This is a follow up of [1], [2], and [3]: v4 (this): Thanks Eric, Peff, and Hannes for the feedback. * I relocated the sigchain_push call so it comes after the error on gpg-interface (thanks Hannnes for catching this). * I updated the unit test to match the discussion on [3]. Now it

[PATCH v4 5/6] tag: use pgp_verify_function in tag -v call

From: Santiago Torres Instead of running the verify-tag plumbing command, we use the pgp_verify_tag(). This avoids the usage of an extra fork call. To do this, we extend the number of parameters that tag.c takes, and verify-tag passes. Redundant calls done in the pgp_verify_tag

[PATCH v4 2/6] t/t7030-verify-tag.sh: Adds validation for multiple tags

From: Santiago Torres The verify-tag command supports mutliple tag names as an argument. However, no previous tests try to verify multiple tags at once. This test runs the verify-tag command against three tags separately and then compares the result against the invocation with

[PATCH v4 3/6] builtin/verify-tag: move verification code to tag.c

From: Santiago Torres The PGP verification routine for tags could be accessed by other commands that require it. We do this by moving it to the common tag.c code. We rename the verify_tag() function to gpg_verify_tag() to avoid conflicts with the mktag.c function.

[PATCH v4 4/6] tag.c: Replace varialbe name for readability

From: Santiago Torres The run_gpg_verify function has two variables size, and len. This may come off as confusing when reading the code. We clarify which one pertains to the length of the tag headers by renaming len to payload_length. Signed-off-by: Santiago Torres

Re: [PATCH v3][Outreachy] branch -D: allow - as abbreviation of @{-1}

elena petrashen wrote: > On Thu, Mar 31, 2016 at 6:31 PM, Remi Galan Alfonso > wrote: > > Elena Petrashen wrote: > >> +void delete_branch_advice(const char *name, const char *ref) > >> +{ > >> +

What's cooking in git.git (Apr 2016, #02; Mon, 4)

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. The tip of 'next' has been

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Hi Junio, On Mon, 4 Apr 2016, Junio C Hamano wrote: > Johannes Sixt writes: > > > Although I am convinced that the change is not necessary for > > correctness, I can buy the justification that we should produce forward > > slashes for consistency. There are a number of occasions

Re: git diff does not precompose unicode file paths (OS X)

> On 15 Mar 2016, at 06:45, Torsten Bögershausen wrote: > > >I created a test case but git diff exits with 0 if it does not recognize the > >file >path so the test case always succeeds. Can you give me a hint or one > >>example test case? > > The most clean (?) is to compare

[PATCH] diff: run arguments through precompose_argv

File paths containing decomposed unicode chars passed to diff command are not converted to precomposed unicode form. As a result, no diff is displayed when feeding such a file path to the diff command. Opposite to most builtin commands, the diff builtin is missing the parse_options call, which

[PATCH] diff: run arguments through precompose_argv

I found an issue where file paths containing decomposed unicode chars are not converted to precomposed unicode form when passed to the diff command family. As a result, no diff is displayed. With the help of Torsten Bögershausen and Junio C Hamano I came up with the following patch to fix the

Re: [PATCH v3][Outreachy] branch -D: allow - as abbreviation of @{-1}

On Thu, Mar 31, 2016 at 6:31 PM, Remi Galan Alfonso wrote: > Elena Petrashen wrote: >> +void delete_branch_advice(const char *name, const char *ref) >> +{ >> +const char fmt[] = >> +"\nNote: to restore the

Re: [Outreachy] Git remote whitelist/blacklist

Hi Lars, thank you so much for reaching out to me! and thank you for your suggestions too, I'm changing my application to reflect those. It does really make sense to start the discussion earlier then I scheduled, and add some extra ideas that could be completed after the whitelist/blacklist.

Re: [PATCH v3 4/4] tag: use pgp_verify_function in tag -v call

On Mon, Apr 04, 2016 at 02:24:48PM -0400, Santiago Torres wrote: > > I think it can be part of this series, but doesn't have to be. As I > > understand it, the current code is just handing the name to the `git > > verify-tag` process, so if we continue to do so, that would be OK. > > IIRC, the

Re: [PATCH] git-format-patch.txt: don't show -s as shorthand for multiple options

Eric Sunshine writes: >> Given that the ifndef/endif block immediately before this part is >> also about excluding -p/-u/--patch when formatting the documentation >> for format-patch, perhaps the attached may be a smaller equivalent? > > Perhaps. I kept self-contained to

Re: [PATCH] git-format-patch.txt: don't show -s as shorthand for multiple options

On Mon, Apr 4, 2016 at 3:32 PM, Junio C Hamano wrote: > Eric Sunshine writes: >> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt >> @@ -28,10 +28,12 @@ ifdef::git-diff[] >> endif::git-diff[] >> endif::git-format-patch[]

Re: [PATCH] git-format-patch.txt: don't show -s as shorthand for multiple options

Eric Sunshine writes: > Documentation/diff-options.txt | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt > index 306b7e3..6eb591f 100644 > --- a/Documentation/diff-options.txt > +++

Re: [PATCH 5/5] t/t5520: test --[no-]autostash with pull.rebase=true

Eric Sunshine writes: > Although I'm the one who brought up the idea of "automating" these > tests, I'm not convinced that it's an improvement in this case, but I > don't feel so strongly that I'd forbid it. Another option is to define helper functions to shorten the

Re: [PATCH v3 4/4] tag: use pgp_verify_function in tag -v call

On Mon, Apr 04, 2016 at 09:38:54AM -0400, Jeff King wrote: > On Mon, Apr 04, 2016 at 12:12:04AM -0400, Santiago Torres wrote: > > > > As a side note, it might actually be an improvement for pgp_verify_tag > > > to take a sha1 (so that git-tag is sure that it is verifying the same > > > object

Re: [PATCH 5/5] t/t5520: test --[no-]autostash with pull.rebase=true

Mehul Jain writes: > On Mon, Apr 4, 2016 at 10:22 PM, Matthieu Moy > wrote: >> I think it would be much simpler to drop the loop, and write instead >> something like (untested): > > I tested it (with few minor changes), and worked fine. >

Re: RFD: removing git.spec.in (Re: git 2.8.0 tarball rpmbuild error)

On za, 2016-04-02 at 20:41 -0700, Junio C Hamano wrote: > I think by now it is very clear that nobody active in the Git > development community tests RPM binaries built with git.spec.in we > have in our tree. I suspect RPM based distros are using their own > RPM build recipe without paying any

Re: [PATCH] doc: clarify that notes can be attached to any type of stored object

Sebastian Schuberth writes: >>> -It is also permitted for a notes ref to point directly to a tree >>> -object, in which case the history of the notes can be read with >>> +It is also permitted for a notes ref to point to any other object in >>> +the object store besides

Re: [PATCH] comment for a long #ifdef

Ivan Pozdeev writes: > --- > compat/poll/poll.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) As Eric pointed out, please sign-off your patch. > diff --git a/compat/poll/poll.c b/compat/poll/poll.c > index db4e03e..5eb0280 100644 > --- a/compat/poll/poll.c > +++

Re: Out Of Place Capitalization In Stash Feedback

Saxon Knight writes: > I recently did a git stash save "working on main", and in the > feedback, I noticed that "On" was capitalized ("...state On > master..."). > I don't think this is intentional, so I figured I'd try to let someone know. > > Here is the output (quotes

Re: [PATCH 5/5] t/t5520: test --[no-]autostash with pull.rebase=true

On Mon, Apr 4, 2016 at 1:36 PM, Mehul Jain wrote: > On Mon, Apr 4, 2016 at 10:22 PM, Matthieu Moy > wrote: >> I think it would be much simpler to drop the loop, and write instead >> something like (untested): > > I tested it (with few minor

Re: [PATCH] Fix spelling mistakes

Eric Engestrom writes: > I went by word-count: "through" was way more common than "thru", so > I kept the fix. That is not a "fix" (as it is not touching "mistakes") but "making them consistent". I do not personally feel strongly against such a change, but please leave them

Re: [PATCH 5/5] t/t5520: test --[no-]autostash with pull.rebase=true

On Mon, Apr 4, 2016 at 10:22 PM, Matthieu Moy wrote: > I think it would be much simpler to drop the loop, and write instead > something like (untested): I tested it (with few minor changes), and worked fine. test_autostash () { OLDIFS=$IFS IFS='='

Re: [sort-of-BUG] merge-resolve cannot resolve "content/mode" conflict

Jeff King writes: > Imagine a merge where one side changes the content of a path and the > other changes the mode. Here's a minimal reproduction: > > git init repo && cd repo && > > echo base >file && > git add file && > git commit -m base && > > echo changed >file && >

Re: What is an efficient way to get all blobs / trees that have notes attached?

On Mon, Apr 4, 2016 at 9:46 AM, Sebastian Schuberth wrote: > On Fri, Apr 1, 2016 at 2:16 PM, Johan Herland wrote: >>> 3) Recursively list all blobs / trees (git-ls-tree) and look whether an >>> object's hash is conatined in our table to get its notes. >>>

Re: [PATCH] git-format-patch.txt: don't show -s as shorthand for multiple options

Ping? On Sun, Mar 27, 2016 at 5:26 PM, Eric Sunshine wrote: > git-format-patch recognizes -s as shorthand only for --signoff, however, > its documentation shows -s as shorthand for both --signoff and > --no-patch. Resolve this confusion by suppressing the bogus -s

Re: [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues

On Mon, Apr 4, 2016 at 8:45 AM, Pranit Bauva wrote: > Okay I will do the change. I was previously unaware about the use of > '\' before EOF. I googled it now. But I am still confused about its > use in this scenario. Upto what I understood, it is used where you > want to

Re: [PATCH] comment for a long #ifdef

Signed-off-by: Ivan Pozdeev --- compat/poll/poll.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/compat/poll/poll.c b/compat/poll/poll.c index db4e03e..5eb0280 100644 --- a/compat/poll/poll.c +++ b/compat/poll/poll.c @@ -441,7 +441,7 @@ poll (struct pollfd *pfd, nfds_t

Re: [PATCH v2 0/7] t5520: tests for --[no-]autostash option

On Mon, Apr 4, 2016 at 10:30 PM, Junio C Hamano wrote: > Matthieu Moy writes: > >> Mehul Jain writes: >> >>> -test_rebase_autostash () { >>> +test_pull_autostash () { >>> git reset --hard before-rebase && >>>

Re: [PATCH v2 0/7] t5520: tests for --[no-]autostash option

Matthieu Moy writes: > Mehul Jain writes: > >> -test_rebase_autostash () { >> +test_pull_autostash () { >> git reset --hard before-rebase && >> echo dirty >new_file && >> git add new_file && >> -git pull --rebase

Re: [PATCH v2 0/7] t5520: tests for --[no-]autostash option

On Mon, Apr 4, 2016 at 1:01 PM, Matthieu Moy wrote: > Mehul Jain writes: > >> -test_rebase_autostash () { >> +test_pull_autostash () { >> git reset --hard before-rebase && >> echo dirty >new_file && >> git add new_file &&

Re: [PATCH 5/5] t/t5520: test --[no-]autostash with pull.rebase=true

Mehul Jain writes: > On Mon, Apr 4, 2016 at 12:58 AM, Eric Sunshine > wrote: >> On Fri, Apr 1, 2016 at 6:27 AM, Mehul Jain wrote: >>> In test_autostash() there's a line >>> >>> echo test_cmp_rev HEAD^ copy && >>>

Re: [PATCH 1/2] imap-send.c: implements the GIT_CURL_DEBUG environment variable

Elia Pinto writes: >> My impression is that using GIT_TRACE_* is the more mainstream >> trend, and it may be beneficial to work any new debugging aid like >> this one to fit within that mechanism. > > I thought about it, and I agree with you. The idea could be > > - Call

Re: [PATCH 5/5] t/t5520: test --[no-]autostash with pull.rebase=true

On Mon, Apr 4, 2016 at 12:58 AM, Eric Sunshine wrote: > On Fri, Apr 1, 2016 at 6:27 AM, Mehul Jain wrote: >> In test_autostash() there's a line >> >> echo test_cmp_rev HEAD^ copy && >> >> Originally it should have been >> >> test_cmp_rev

Re: [PATCH] doc: clarify that notes can be attached to any type of stored object

Sebastian Schuberth writes: > Done, I'll send a patch shortly. But I wanted to list the supported > object types explicitly, in particular as many guide in the net are > unclear that only annotated tags are object, and lightweight ones are > not. I'd really hate to see an

Re: [PATCH v3 13/16] ref-filter: allow porcelain to translate messages in the output

Matthieu Moy writes: > I'm not sure how important it is in this case, but it was in the case of > setup_unpack_trees_porcelain which I took inspiration from when we > discussed this (actually, in setup_unpack_trees_porcelain, there's isn't > any translation even in

Re: [PATCH 1/2] imap-send.c: implements the GIT_CURL_DEBUG environment variable

2016-04-01 17:35 GMT+02:00 Junio C Hamano : > Elia Pinto writes: > >> Implements the GIT_CURL_DEBUG environment variable to allow a greater >> degree of detail of GIT_CURL_VERBOSE, in particular the complete >> transport header and all the data payload

Re: [PATCH 1/4] config --show-origin: report paths with forward slashes

Johannes Sixt writes: > Although I am convinced that the change is not necessary for > correctness, I can buy the justification that we should produce forward > slashes for consistency. There are a number of occasions where we > present paths to the user, and we do show

Re: [PATCH v3 2/4] t/t7030-verify-tag.sh: Adds validation for multiple tags

On Sun, Apr 03, 2016 at 09:38:34PM -0400, Eric Sunshine wrote: > I think Peff meant that a simple grep would suffice; no need for > test_i18ngrep. In other words (reproducing Peff's example), something > like this: > > tags="fourth-signed sixth-signed seventh-signed" && > for i in $tags;

Re: [PATCH v3 4/4] tag: use pgp_verify_function in tag -v call

On Mon, Apr 04, 2016 at 12:12:04AM -0400, Santiago Torres wrote: > > As a side note, it might actually be an improvement for pgp_verify_tag > > to take a sha1 (so that git-tag is sure that it is verifying the same > > object that it is printing), but that refactoring should probably come > >

Re: [PATCH 1/2] imap-send.c: implements the GIT_CURL_DEBUG environment variable

2016-04-01 16:56 GMT+02:00 Ramsay Jones : > > > On 01/04/16 11:44, Elia Pinto wrote: >> Implements the GIT_CURL_DEBUG environment variable to allow a greater >> degree of detail of GIT_CURL_VERBOSE, in particular the complete >> transport header and all the data

Re: [PATCH v12 1/5] t0040-test-parse-options.sh: fix style issues

On Mon, Apr 4, 2016 at 2:30 AM, Eric Sunshine wrote: > On Sat, Apr 2, 2016 at 7:33 PM, Pranit Bauva wrote: >> Signed-off-by: Pranit Bauva >> --- >> diff --git a/t/t0040-parse-options.sh b/t/t0040-parse-options.sh >> @@

Re: [PATCH 2/2] http.c: implements the GIT_CURL_DEBUG environment variable

2016-04-01 17:03 GMT+02:00 Ramsay Jones : > > > On 01/04/16 11:44, Elia Pinto wrote: >> Implements the GIT_CURL_DEBUG environment variable to allow a greater >> degree of detail of GIT_CURL_VERBOSE, in particular the complete >> transport header and all the data

[PATCH] doc: Clarify which objects notes can be attached to

Explicitly name the supported object types, and ensure patches cannot be misinterpreted as non-objects that can have notes attached. Signed-off-by: Sebastian Schuberth --- Documentation/git-notes.txt | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff

Re: [PATCH] doc: clarify that notes can be attached to any type of stored object

On Fri, Apr 1, 2016 at 6:47 PM, Junio C Hamano wrote: > DESCRIPTION > --- > Adds, removes, or reads notes attached to objects, without touching > the objects themselves. > > This says "notes attached to objects" and "the objects themselves". > They do

[ANNOUNCE] Git for Windows 2.8.1

Dear Git users, It is my pleasure to announce that Git for Windows 2.8.1 is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.8.0 (March 29th 2016) New Features ??? Comes with Git v2.8.1. ??? The Git for Windows project updated its contributor

Re: [PATCH] doc: clarify that notes can be attached to any type of stored object

On Fri, Apr 1, 2016 at 5:31 PM, Junio C Hamano wrote: > Sebastian Schuberth writes: > >> Signed-off-by: Sebastian Schuberth >> --- >> Documentation/git-notes.txt | 5 +++-- >> 1 file changed, 3 insertions(+), 2 deletions(-) >> >>

Re: [PATCH v3 13/16] ref-filter: allow porcelain to translate messages in the output

Karthik Nayak writes: > cc'ing Matthieu since this patch was initially written by him. > > On Thu, Mar 31, 2016 at 3:28 AM, Junio C Hamano wrote: >> Karthik Nayak writes: >> >>> +static struct ref_msg { >>> + const char

Re: What is an efficient way to get all blobs / trees that have notes attached?

On Fri, Apr 1, 2016 at 2:16 PM, Johan Herland wrote: >> 3) Recursively list all blobs / trees (git-ls-tree) and look whether an >> object's hash is conatined in our table to get its notes. >> >> In particular 3) could be expensive for repos with a lot of files as we're >>

Re: [PATCH v2 0/7] t5520: tests for --[no-]autostash option

Mehul Jain writes: > -test_rebase_autostash () { > +test_pull_autostash () { > git reset --hard before-rebase && > echo dirty >new_file && > git add new_file && > - git pull --rebase --autostash . copy && > + git pull $@ . copy && Not strictly

git mv - exclude source / create target directory option

Hi, sometimes I want to reorganize the content of a directory and simply move everything into a subdirectory. This seems to be more complicated than it should be. Since git mv requires the destination to exist, I need to create the target directory first. Unfortunately this results in git mv *

Re: [PATCH] rev-parse: fix --git-common-dir when executed from subpath of main tree

On Sun, Apr 3, 2016 at 9:42 PM, Michael Rappazzo wrote: > Executing `git-rev-parse --git-common-dir` from the root of the main > worktree results in '.git', which is the relative path to the git dir. > When executed from a subpath of the main tree it returned somthing like: