Re: [PATCH v2] run-command: add hint when a hook is ignored

Junio C Hamano writes: > I think it is easier to reason about if this were not "else if", but > just a simple "if". And here are two small suggested changes to the code portion of your patch. - break if / else if cascade into two independent if / if statements for

Re: [PATCH v2] run-command: add hint when a hook is ignored

Here is a suggested rewrite of t7519 (I used t7520 to avoid crashing with another topic in flight). - use unused/unallocated 7520 to avoid crashes with bp/fsmonitor topic - use setup inside test_expect_success - use test_i18ngrep to avoid gettext-poison build gotchas - look for specific

Re: [PATCH v2] run-command: add hint when a hook is ignored

Junio C Hamano writes: >> diff --git a/t/t7519-ignored-hook-warning.sh >> b/t/t7519-ignored-hook-warning.sh >> new file mode 100755 Another thing; t7519 is taken by another topic in flight. Let's use t7520 instead.

Re: [PATCH v2 2/3] for-each-ref: let upstream/push optionally remote ref name

Johannes Schindelin writes: > Subject: Re: [PATCH v2 2/3] for-each-ref: let upstream/push optionally remote > ref name No verb? s/optionally/report/ perhaps? > diff --git a/ref-filter.c b/ref-filter.c > index 4819707d032..b4b2c9b2190 100644 > --- a/ref-filter.c >

Re: [PATCH v1 2/2] entry.c: check if file exists after checkout

On Fri, Oct 06, 2017 at 01:26:48PM +0900, Junio C Hamano wrote: > > We could probably be a bit more specific about the situation, since the > > user will see this message with no context. Maybe something like: > > > > unable to stat just-written file %s > > > > or something. We should probably

Re: [PATCH v1 1/2] entry.c: update cache entry only for existing files

On Fri, Oct 06, 2017 at 08:01:48AM +0900, Junio C Hamano wrote: > > But > > I think we'd want to protect the read_blob_entry() call at the top of > > the case with a check for dco->state == CE_RETRY. > > Yeah, I think that makes more sense. > > A patch may look like this on top of these two

Re: [PATCH v2] run-command: add hint when a hook is ignored

Damien Marié writes: > if (access(path.buf, X_OK) < 0) { > + int err = errno; OK, so we remember how/why we failed in err. > #ifdef STRIP_EXTENSION > strbuf_addstr(, STRIP_EXTENSION); > if (access(path.buf, X_OK) >= 0) >

Re: [PATCH] sha1_loose_object_info: handle errors from unpack_sha1_rest

On Fri, Oct 06, 2017 at 12:30:08AM -0400, Jeff King wrote: > On Fri, Oct 06, 2017 at 01:19:21PM +0900, Junio C Hamano wrote: > > > > But note that the leak in (2) is actually older than that. > > > The original unpack_sha1_file() directly returned the result > > > of unpack_sha1_rest() to its

Re: couple questions about git "logical variables" and "git var"

On Thu, Oct 05, 2017 at 07:35:30PM -0700, Jonathan Nieder wrote: > > It also only tells half the story. You have to know not just what's in > > $GIT_EDITOR, but you have to know the right way to evaluate it. There's > > a git_editor helper in git-sh-setup, but other scripting languages are > > on

Re: [PATCH] sha1_loose_object_info: handle errors from unpack_sha1_rest

On Fri, Oct 06, 2017 at 01:19:21PM +0900, Junio C Hamano wrote: > > But note that the leak in (2) is actually older than that. > > The original unpack_sha1_file() directly returned the result > > of unpack_sha1_rest() to its caller, when it should have > > been closing the zlib stream itself on

Re: [PATCH v1 2/2] entry.c: check if file exists after checkout

Jeff King writes: >> diff --git a/entry.c b/entry.c >> index 5dab656364..2252d96756 100644 >> --- a/entry.c >> +++ b/entry.c >> @@ -355,7 +355,8 @@ static int write_entry(struct cache_entry *ce, >> if (state->refresh_cache) { >> assert(state->istate); >>

Re: [PATCH] sha1_loose_object_info: handle errors from unpack_sha1_rest

Jeff King writes: > When a caller of sha1_object_info_extended() sets the > "contentp" field in object_info, we call unpack_sha1_rest() > but do not check whether it signaled an error. > > This causes two problems: > > 1. We pass back NULL to the caller via the contentp field, >

Re: [PATCH v2] api-argv-array.txt: Remove broken link to string-list API

Jonathan Nieder wrote: Thanks for catching it. Do you use a broken link detection tool to detect this kind of issue automatically? Yeah, in the Fedora git builds we pass all the generated html files through the linkchecker tool (http://wummel.github.io/linkchecker/). We started using that

Re: [RFC] Reporting index properties

Jonathan Nieder writes: > Aside: git-update-index(1) says > > Version 4 is relatively young (first released in 1.8.0 in > October 2012). > > My first reaction is to wonder if it is time to introduce a config > option to use index format version 4 by default, since

Re: [PATCH v2] api-argv-array.txt: Remove broken link to string-list API

Todd Zullinger wrote: > In 4f665f2cf3 (string-list.h: move documentation from Documentation/api/ > into header, 2017-09-26) the string-list API documentation was moved to > string-list.h. The argv-array API documentation may follow a similar > course in the future. Until then, prevent the

[PATCH v2] api-argv-array.txt: Remove broken link to string-list API

In 4f665f2cf3 (string-list.h: move documentation from Documentation/api/ into header, 2017-09-26) the string-list API documentation was moved to string-list.h. The argv-array API documentation may follow a similar course in the future. Until then, prevent the broken link from making it to the

Re: [RFC] Reporting index properties

Alex Vandiver wrote: > As part of gathering some automated performance statistics of git, it > would be useful to be able to extract some vital properties of the > index. While `git update-index` has ways to _set_ the index version, > and enable/disable various extensions, AFAICT there is no

Re: [RFC] Reporting index properties

Alex Vandiver writes: > On Fri, 6 Oct 2017, Junio C Hamano wrote: >> > Do folks have feelings about surfacing this information, and where such >> > logic should live? >> >> Probably one of the t/helper/test-dump-*.c programs, if we already >> do not have one. > > The goal

Re: [PATCH] api-argv-array.txt: Update link to string-list API

Todd Zullinger writes: > I noticed this broken link in the html documentation while building > 2.15.0-rc0. I'm not sure whether it's better to point the link to the > string-list.h file on Git Hub, remove the link, or drop the entire > paragraph. Probably removing the link is

Re: couple questions about git "logical variables" and "git var"

Jeff King wrote: > On Thu, Oct 05, 2017 at 05:11:04AM -0400, rpj...@crashcourse.ca wrote: >> - GIT_AUTHOR_IDENT >> - GIT_COMMITTER_IDENT >> - GIT_EDITOR >> - GIT_PAGER >> >> first question -- what is it about precisely those four variables that makes >> them "logical" variables in git

Re: [PATCH v2] fsck: handle NULL return of lookup_blob() and lookup_tree()

René Scharfe writes: > An error message is already shown by object_as_type(), which is called > by the lookup functions. The walk callback functions are expected to > handle NULL object pointers passed to them, but put_object_name() needs > a valid object, so avoid calling it

Re: [PATCH v2 11/12] read-cache: leave lock in right state in `write_locked_index()`

Martin Ågren writes: > v2: Except for the slightly different documentation in cache.h, this is > a squash of the last two patches of v1. I hope the commit message is > better. Yeah, it is long ;-) but readable. Thanks.

Re: [PATCH v2 10/12] read-cache: drop explicit `CLOSE_LOCK`-flag

Martin Ågren writes: > diff --git a/read-cache.c b/read-cache.c > index 65f4fe837..1c917eba9 100644 > --- a/read-cache.c > +++ b/read-cache.c > @@ -2343,14 +2343,13 @@ static int do_write_locked_index(struct index_state > *istate, struct lock_file *l > int ret =

Re: [PATCH v2 05/12] checkout-index: simplify locking logic

Martin Ågren writes: > `newfd` starts out negative. If we then take the lock, `newfd` will > become non-negative. We later check for exactly that property before > calling `write_locked_index()`. That is, we are simply using `newfd` as > a boolean to keep track of whether

Re: [PATCH v2 01/12] sha1_file: do not leak `lock_file`

Martin Ågren writes: > Bump `found` to the scope of the whole function and rearrange the "roll > back or write?"-checks to a straightforward if-else on `found`. This > also future-proves the code by making it obvious that we intend to take > exactly one of these paths. >

Re: is it "core.excludesfile" or "core.excludesFile"?

Stefan Beller writes: > On Thu, Oct 5, 2017 at 2:25 PM, Robert P. J. Day > wrote: >> >> more pedantic nitpickery, but the git source/docs seems to bounce >> all over the place as to which of those forms is the right one. >> opinions? > > In the code

Re: [RFC] Reporting index properties

On Fri, 6 Oct 2017, Junio C Hamano wrote: > > Do folks have feelings about surfacing this information, and where such > > logic should live? > > Probably one of the t/helper/test-dump-*.c programs, if we already > do not have one. The goal would be to be able to extract this information from

Re: [RFC] Reporting index properties

Alex Vandiver writes: > Do folks have feelings about surfacing this information, and where such > logic should live? Probably one of the t/helper/test-dump-*.c programs, if we already do not have one.

Re: Line ending normalization doesn't work as expected

Torsten Bögershausen writes: > Before we put this into stone: > Does it make sense to say "renormalize" instead of "rehash" ? > (That term does exist already for merge. > And rehash is more a technical term, rather then a user-point-of-view > explanation) I do not mind

[RFC] Reporting index properties

Heya, As part of gathering some automated performance statistics of git, it would be useful to be able to extract some vital properties of the index. While `git update-index` has ways to _set_ the index version, and enable/disable various extensions, AFAICT there is no method by which one can

Re: [PATCH v1 1/2] entry.c: update cache entry only for existing files

Jeff King writes: > On Thu, Oct 05, 2017 at 08:19:13PM +0900, Junio C Hamano wrote: > >> This is unrelated to the main topic of this patch, but we see this >> just before the precontext of this hunk: >> >> if (dco && dco->state != CE_NO_DELAY) { >>

Re: [PATCH 1/1] completion: Add forgotten describe options

On Thu, Oct 5, 2017 at 2:23 PM, Thomas Braun wrote: > completion: Add forgotten describe options When/Why was it forgotten? git-blame thinks it was me in b0176ce6b5 (builtin/describe: introduce --broken flag, 2017-03-21) Which do you add? (dirty and broken) I

Re: [PATCH 6/6] Handle unsupported combination status arguments

On Thu, Oct 5, 2017 at 1:54 PM, wrote: > From: Jameson Miller > > It is not clear what the correct behavior should be when you ask for > specific ignored behavior without reporting untracked files. For now, > report this as an unsupported

[PATCH 1/1] completion: Add forgotten describe options

Signed-off-by: Thomas Braun --- contrib/completion/git-completion.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index d934417475..0e16f017a4 100644 ---

Re: [PATCH 3/6] Add tests for git status `--ignored=matching`

On Thu, Oct 5, 2017 at 1:54 PM, wrote: > From: Jameson Miller > > Add tests for new ignored mode (matching) when showing all untracked > files. > > Signed-off-by: Jameson Miller > --- > t/t7519-ignored-mode.sh | 132 >

Re: [PATCH 2/6] Update documentation for new directory and status logic

On Thu, Oct 5, 2017 at 1:54 PM, wrote: > From: Jameson Miller > > Signed-off-by: Jameson Miller > --- > Documentation/git-status.txt | 22 +- >

[PATCH 1/1] completion: Add forgotten describe options

Signed-off-by: Thomas Braun --- contrib/completion/git-completion.bash | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash index d934417475..0e16f017a4 100644 ---

Re: Line ending normalization doesn't work as expected

> builtin/add.c | 42 +- > 1 file changed, 41 insertions(+), 1 deletion(-) > > diff --git a/builtin/add.c b/builtin/add.c > index 5d5773d5cd..264f84dbe7 100644 > --- a/builtin/add.c > +++ b/builtin/add.c > @@ -26,6 +26,7 @@ static const char * const

Re: is it "core.excludesfile" or "core.excludesFile"?

On Thu, Oct 5, 2017 at 2:25 PM, Robert P. J. Day wrote: > > more pedantic nitpickery, but the git source/docs seems to bounce > all over the place as to which of those forms is the right one. > opinions? In the code we use all lowercase to compare (any input is converted

is it "core.excludesfile" or "core.excludesFile"?

more pedantic nitpickery, but the git source/docs seems to bounce all over the place as to which of those forms is the right one. opinions? rday -- Robert P. J. Day Ottawa, Ontario,

Re: [PATCH 0/6] Teach Status options around showing ignored files

On 10/05/2017 05:16 PM, Jonathan Nieder wrote: Hi, jameson.mille...@gmail.com wrote: This patch series is the second part of [1], which was split into 2 parts. The first part, added an optimization in the directory listing logic to not scan the contents of ignored directories and was merged

Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick

Am 05.10.2017 um 21:33 schrieb Stefan Beller: On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt wrote: +git-post(1) +=== + +NAME + +git-post - Apply a commit on top of a branch that is not checked out Contrasted to: git-cherry-pick - Apply the changes introduced by

Re: [PATCH 0/6] Teach Status options around showing ignored files

Hi, jameson.mille...@gmail.com wrote: > This patch series is the second part of [1], which was split into 2 > parts. The first part, added an optimization in the directory listing > logic to not scan the contents of ignored directories and was merged > to master with commit 5aaa7fd3. This patch

[PATCH] api-argv-array.txt: Update link to string-list API

In 4f665f2cf3 (string-list.h: move documentation from Documentation/api/ into header, 2017-09-26) the string-list API documentation was moved into string-list.h. Fix the link from the argv-array API documentation. Signed-off-by: Todd Zullinger --- Hi, I noticed this broken

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.2(2)

Hi Lars, On Thu, 5 Oct 2017, Lars Schneider wrote: > > On 05 Oct 2017, at 22:02, Johannes Schindelin > > wrote: > > > > It is my pleasure to announce that Git for Windows 2.14.2(2) is available > > from: > > > > https://git-for-windows.github.io/ > > > >

[PATCH 1/6] Teach status options around showing ignored files

From: Jameson Miller This change teaches the status command more options to control which ignored files are reported independently of the which untracked files are reported by allowing the `--ignored` option to take additional arguments. Currently, the shown ignored files

[PATCH 4/6] Expand support for ignored arguments on status

From: Jameson Miller Teach status command to handle matching ignored mode when showing untracked files with the normal option. Signed-off-by: Jameson Miller --- dir.c | 20 ++-- 1 file changed, 18 insertions(+), 2 deletions(-) diff

[PATCH 0/6] Teach Status options around showing ignored files

From: Jameson Miller This patch series is the second part of [1], which was split into 2 parts. The first part, added an optimization in the directory listing logic to not scan the contents of ignored directories and was merged to master with commit 5aaa7fd3. This patch

[PATCH 2/6] Update documentation for new directory and status logic

From: Jameson Miller Signed-off-by: Jameson Miller --- Documentation/git-status.txt | 22 +- Documentation/technical/api-directory-listing.txt | 28 +++ 2 files changed, 45 insertions(+), 5

[PATCH 6/6] Handle unsupported combination status arguments

From: Jameson Miller It is not clear what the correct behavior should be when you ask for specific ignored behavior without reporting untracked files. For now, report this as an unsupported combination of input arguments, so it can be modified in the future without back

[PATCH 3/6] Add tests for git status `--ignored=matching`

From: Jameson Miller Add tests for new ignored mode (matching) when showing all untracked files. Signed-off-by: Jameson Miller --- t/t7519-ignored-mode.sh | 132 1 file changed, 132 insertions(+)

[PATCH 5/6] Add tests around status handling of ignored arguments

From: Jameson Miller Add tests for status handling of '--ignored=matching` and `--untracked-files=normal`. Signed-off-by: Jameson Miller --- t/t7519-ignored-mode.sh | 63 + 1 file changed, 63

[PATCH v2] run-command: add hint when a hook is ignored

When an hook is present but the file is not set as executable then git will ignore the hook. For now this is silent which can be confusing. This commit adds this warning to improve the situation: hint: The 'pre-commit' hook was ignored because it's not set as executable. hint: You can

Re: [PATCH] run-command.c: add hint when hook is not executable

On Wed, Oct 4, 2017 at 6:40 AM, Junio C Hamano wrote: > Damien writes: > >> --- > > Please explain why this change makes sense to those who find this > commit in "git log" output six months down the line, without having > read the original thread that motivated

[PATCH v2 07/12] apply: move lockfile into `apply_state`

We have two users of `struct apply_state` and the related functionality in apply.c. Each user sets up its `apply_state` by handing over a pointer to its static `lock_file`. (Before 076aa2cbd (tempfile: auto-allocate tempfiles on heap, 2017-09-05), we could never free lockfiles, so making them

[PATCH v2 08/12] apply: remove `newfd` from `struct apply_state`

Similar to a previous patch, we do not need to use `newfd` to signal that we have a lockfile to clean up. We can just unconditionally call `rollback_lock_file`. If we do not hold the lock, it will be a no-op. Where we check `newfd` to decide whether we need to take the lock, we can instead use

[PATCH v2 09/12] cache.h: document `write_locked_index()`

The next patches will tweak the behavior of this function. Document it in order to establish a basis for those patches. Signed-off-by: Martin Ågren --- v2: Tweaked to go better with the changed approach in the later patches. cache.h | 16 1 file

[PATCH v2 04/12] tempfile: fix documentation on `delete_tempfile()`

The function has always been documented as returning 0 or -1. It is in fact `void`. Correct that. As part of the rearrangements we lose the mention that `delete_tempfile()` might set `errno`. Because there is no return value, the user can't really know whether it did anyway. Signed-off-by: Martin

[PATCH v2 11/12] read-cache: leave lock in right state in `write_locked_index()`

If the original version of `write_locked_index()` returned with an error, it didn't roll back the lockfile unless the error occured at the very end, during closing/committing. See commit 03b866477 (read-cache: new API write_locked_index instead of write_index/write_cache, 2014-06-13). In commit

[PATCH v2 12/12] read_cache: roll back lock in `update_index_if_able()`

`update_index_if_able()` used to always commit the lock or roll it back. Commit 03b866477 (read-cache: new API write_locked_index instead of write_index/write_cache, 2014-06-13) stopped rolling it back in case a write was not even attempted. This change in behavior is not motivated in the commit

[PATCH v2 10/12] read-cache: drop explicit `CLOSE_LOCK`-flag

`write_locked_index()` takes two flags: `COMMIT_LOCK` and `CLOSE_LOCK`. At most one is allowed. But it is also possible to use no flag, i.e., `0`. But when `write_locked_index()` calls `do_write_index()`, the temporary file, a.k.a. the lockfile, will be closed. So passing `0` is effectively the

[PATCH v2 00/12] Re: various lockfile-leaks and -fixes

On 3 October 2017 at 08:21, Junio C Hamano wrote: > Martin Ågren writes: >> On 2 October 2017 at 08:30, Junio C Hamano wrote: >> >> Thanks both of you for your comments. Based on them, I have made the >> following notes: >> ... >>

[PATCH v2 01/12] sha1_file: do not leak `lock_file`

There is no longer any need to allocate and leak a `struct lock_file`. Initialize it on the stack instead. Before this patch, we set `lock = NULL` to signal that we have already rolled back, and that we should not do any more work. We need to take another approach now that we cannot assign NULL.

[PATCH v2 02/12] treewide: prefer lockfiles on the stack

There is no longer any need to allocate and leak a `struct lock_file`. The previous patch addressed an instance where we needed a minor tweak alongside the trivial changes. Deal with the remaining instances where we allocate and leak a struct within a single function. Change them to have the

[PATCH v2 06/12] cache-tree: simplify locking logic

After we have taken the lock using `LOCK_DIE_ON_ERROR`, we know that `newfd` is non-negative. So when we check for exactly that property before calling `write_locked_index()`, the outcome is guaranteed. If we write and commit successfully, we set `newfd = -1`, so that we can later avoid calling

[PATCH v2 05/12] checkout-index: simplify locking logic

`newfd` starts out negative. If we then take the lock, `newfd` will become non-negative. We later check for exactly that property before calling `write_locked_index()`. That is, we are simply using `newfd` as a boolean to keep track of whether we took the lock or not. (We always use `newfd` and

[PATCH v2 03/12] lockfile: fix documentation on `close_lock_file_gently()`

Commit 83a3069a3 (lockfile: do not rollback lock on failed close, 2017-09-05) forgot to update the documentation by the function definition to reflect that the lock is not rolled back in case closing fails. Signed-off-by: Martin Ågren Signed-off-by: Junio C Hamano

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.2(2)

> On 05 Oct 2017, at 22:02, Johannes Schindelin > wrote: > > Dear Git users, > > It is my pleasure to announce that Git for Windows 2.14.2(2) is available > from: > > https://git-for-windows.github.io/ > > Changes since Git for Windows v2.14.2 (September

[PATCH 2/1] mention git stash push first in the man page

Because 'stash push' and 'stash save' are so closely related they share one section in the man page. Currently 'stash save' comes first, as that was the command that people were historically using. However this makes the newer, more feature rich git stash push very easy to overlook. Change the

[ANNOUNCE] Git for Windows 2.14.2(2)

Dear Git users, It is my pleasure to announce that Git for Windows 2.14.2(2) is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.14.2 (September 26th 2017) New Features * Comes with BusyBox v1.28.0pre.16467.b4c390e17. * Comes with Git LFS v2.3.2.

[RFC] deprecate git stash save? (was: Re: [PATCH 2/3] http-push: fix construction of hex value from path)

On 10/04, Junio C Hamano wrote: > I do not object with such a well designed deprecation plan for any > other features, if there are other "favourite" ones people would > want to deprecate and eventually remove, by the way. Since you were asking :) With the introduction of 'git stash push', my

Re: [PATCH] .mailmap: normalize name for René Scharfe

René Scharfe wrote: > Reported-by: Johannes Schindelin > Reported-by: Stefan Beller > Signed-off-by: Rene Scharfe > --- > .mailmap | 1 + > 1 file changed, 1 insertion(+) A quick "git shortlog -nse" run confirms that this works.

[PATCH v2] fsck: handle NULL return of lookup_blob() and lookup_tree()

lookup_blob() and lookup_tree() can return NULL if they find an object of an unexpected type. Accessing the object member is undefined in that case. Cast the result to a struct object pointer instead; we can do that because object is the first member of all object types. This trick is already

Re: [PATCH] fsck: check results of lookup_blob() and lookup_tree() for NULL

Am 04.10.2017 um 06:00 schrieb Junio C Hamano: > René Scharfe writes: >> lookup_blob() and lookup_tree() can return NULL if they find an object >> of an unexpected type. Error out of fsck_walk_tree() in that case, like >> we do when encountering a bad file mode. An error message

[PATCH] .mailmap: normalize name for René Scharfe

Reported-by: Johannes Schindelin Reported-by: Stefan Beller Signed-off-by: Rene Scharfe --- .mailmap | 1 + 1 file changed, 1 insertion(+) diff --git a/.mailmap b/.mailmap index ab85e0d16d..224db83887 100644 --- a/.mailmap +++

Re: [PATCH/RFC] git-post: the opposite of git-cherry-pick

On Thu, Oct 5, 2017 at 12:13 PM, Johannes Sixt wrote: > Add a new command that can be used to copy an arbitrary commit > to a branch that is not checked out. Cool. :) > > Signed-off-by: Johannes Sixt > --- > I have been using this command since years, but got

[PATCH/RFC] git-post: the opposite of git-cherry-pick

Add a new command that can be used to copy an arbitrary commit to a branch that is not checked out. Signed-off-by: Johannes Sixt --- I have been using this command since years, but got around to write a man page and tests only now. I hope the man page makes sense. I don't have

Re: Regression in 'git branch -m'?

On Thu, Oct 05, 2017 at 07:25:52PM +0200, Andreas Krey wrote: > I got something that looks like a regression somewhere since 2.11. > This script > > set -xe > rm -rf repo > git init repo > cd repo > git commit -m nix --allow-empty > git branch -m master/master > git rev-parse HEAD

Regression in 'git branch -m'?

Hi everybody, I got something that looks like a regression somewhere since 2.11. This script set -xe rm -rf repo git init repo cd repo git commit -m nix --allow-empty git branch -m master/master git rev-parse HEAD git branch git status causes .git/HEAD to still contain 'ref:

Re: [ANNOUNCE] Git v2.15.0-rc0

+ Rene - kernel mailing list On Thu, Oct 5, 2017 at 6:10 AM, Johannes Schindelin wrote: > Hi Junio, > > On Thu, 5 Oct 2017, Junio C Hamano wrote: > >> New contributors whose contributions weren't in v2.14.0 are as follows. >> Welcome to the Git development community!

Re: git send-email does not work with Google anymore?!

On 05/10/2017 16:21, ankostis wrote: > > But this seems to have stopped working; I clicked the link in the page below > https://support.google.com/accounts/answer/6010255?hl=en > and for my account it tells me "less secure apps" access is unavailable :-( It says for me "This setting is not

Apply

UNSECURED BUSINESS/PERSONAL LOAN BY LOAN CAPITAL FINANCE - NO COLLATERAL - MINIMUM DOCUMENTATION - BUSINESS LOAN UP TO FIVE(5) MILLION US DOLLARS CONTACT US TODAY VIA EMAIL: financeloa...@hotmail.com

Re: git send-email does not work with Google anymore?!

On 5 October 2017 at 15:43, Paolo Bonzini wrote: > > On 05/10/2017 12:52, Lars Schneider wrote: > > Hi, > > > > I used to use the Google SMTP server to send my patches to the list with > > the following config: > > > > [sendemail] > > smtpencryption = tls > >

wildmatch + fnmatch compatibility

Hi all, I noticed a possible inconsistency in the documentation for .gitignore; the pertinent bit is: If the pattern does not contain a slash /, Git treats it as a shell glob pattern and checks for a match against the pathname relative to the location of the .gitignore file ...

Re: git send-email does not work with Google anymore?!

On 05/10/2017 12:52, Lars Schneider wrote: > Hi, > > I used to use the Google SMTP server to send my patches to the list with > the following config: > > [sendemail] > smtpencryption = tls > smtpserver = smtp.gmail.com > smtpuser = larsxschnei...@gmail.com >

[PATCH 2/4] trailer: simplify check_if_different

The check_all argument is pointless, because the function degenerates to !same_trailer when check_all==0 (if same_trailer fails, it always ends up returning 1). Remove it, switching the check_all==0 caller to use same_trailer directly. Signed-off-by: Paolo Bonzini ---

[PATCH 4/4] trailer: add "move" configuration for trailer.ifExists

In some cases, people apply patches to a queue branch immediately with "git am -3 -s", and later collect Reviewed-by or Acked-by trailers as they come in from the mailing list. In this case, "where=after" does not have the desired behavior, because it will add the trailer in an unorthodox

[PATCH 3/4] trailer: create a new function to handle adding trailers

Create a new function apply_arg that takes care of computing the new trailer's "neighbor", checking for duplicates through a pluggable callback, and adding the new argument according to "trailer.where". Rename after_or_end, and don't use it in apply_arg. It's a coincidence that the conditions

[PATCH 1/4] trailer: push free_arg_item up

All callees of process_trailers_lists are calling free_arg_item. Just do it in process_trailers_lists itself. Signed-off-by: Paolo Bonzini --- trailer.c | 9 ++--- 1 file changed, 2 insertions(+), 7 deletions(-) diff --git a/trailer.c b/trailer.c index

[RFC PATCH 0/4] interpret-trailers: introduce "move" action

The purpose of this action is for scripts to be able to keep the user's Signed-off-by at the end. For example say I have a script that adds a Reviewed-by tag: #! /bin/sh them=$(git log -i -1 --pretty='format:%an <%ae>' --author="$*") trailer="Reviewed-by: $them" git log -1

Re: [ANNOUNCE] Git v2.15.0-rc0

Hi Junio, On Thu, 5 Oct 2017, Junio C Hamano wrote: > New contributors whose contributions weren't in v2.14.0 are as follows. > Welcome to the Git development community! > > Ann T Ropea, Daniel Watkins, Dimitrios Christidis, Eric Rannaud, > Evan Zacks, Hielke Christian Braun, Ian Campbell,

Re: [PATCH v2 1/5] test-list-objects: List a subset of object ids

On 10/5/2017 6:00 AM, Jeff King wrote: On Thu, Oct 05, 2017 at 06:48:10PM +0900, Junio C Hamano wrote: Jeff King writes: This is weirdly specific. Can we accomplish the same thing with existing tools? E.g., could: git cat-file --batch-all-objects

Re: [PATCH 1/3] for-each-ref: let upstream/push optionally report the remote name

Hi Junio, On Wed, 4 Oct 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > This patch offers the new suffix :remote for the upstream and for the > > push atoms, allowing to show exactly that. > > Has the design changed since this description and

[PATCH v2 2/3] for-each-ref: let upstream/push optionally remote ref name

From: J Wyman There are times when scripts want to know not only the name of the push branch on the remote, but also the name of the branch as known by the remote repository. An example of this is when a tool wants to push to the very same branch from which it would pull

[PATCH v2 3/3] for-each-ref: test :remotename and :remoteref

This not only prevents regressions, but also serves as documentation what this new feature is expected to do. Signed-off-by: Johannes Schindelin --- t/t6300-for-each-ref.sh | 32 1 file changed, 32 insertions(+) diff --git

[PATCH v2 1/3] for-each-ref: let upstream/push optionally report the remote name

There are times when e.g. scripts want to know not only the name of the upstream branch on the remote repository, but also the name of the remote. This patch offers the new suffix :remotename for the upstream and for the push atoms, allowing to show exactly that. Example: $ cat

[PATCH v2 0/3] for-each-ref: add :remoteref and :remotename specifiers

This introduces support for git for-each-ref \ --format="%(merge:remotename),%(merge:remoteref)" git for-each-ref \ --format="%(push:remotename),%(push:remoteref)" to figure out the remote nickname as well as the name of the corresponding branch on

Re: [PATCH v2] branch: change the error messages to be more meaningful

On Thu, 2017-10-05 at 10:13 +0900, Junio C Hamano wrote: > Kaartic Sivaraam writes: > > > Moreover, as a consequence of my assumption that the tests don't check > > for the error messages themselves; I haven't even thought of checking > > whether the tests or the

Re: Quoted-printable support in git am

On 05/10/2017 11:43, Junio C Hamano wrote: > On Thu, Oct 5, 2017 at 6:30 PM, Jeff King wrote: > >> Mason wrote: >> >>> The patch header contains: >>> >>> Content-Type: text/plain; charset=UTF-8; format=flowed >>> Content-Transfer-Encoding: quoted-printable >> >> That looks right. Though I

Re: hacktoberfest

On Wed, Oct 04, 2017 at 10:20:53PM +0100, pedro rijo wrote: > here's the answer: Seems a nice start yes. I've been on vacations, but > next week I will go trough the current issues and add the > hacktoberfest label to some issues if you agree. > > I went through the open issues a few moments

  1   2   >