Re: body-CC-comment regression

Matthieu Moy writes: > Junio C Hamano writes: > >> Johan Hovold writes: >> >>> That's precisely what the patch I posted earlier in the thread did. >> >> That's good. I didn't see any patch yet > > It's here: > >

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

On Fri, Feb 17, 2017 at 02:43:50PM -0500, Jeff King wrote: > Yes. I think the options are basically (in order of decreasing > preference in my opinion): > > 1. Log a rename entry (same sha1, but note the rename in the free-form > text). > > 2. Log a delete (sha1 goes to null) followed

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

On Fri, Feb 17, 2017 at 09:50:54AM -0800, Junio C Hamano wrote: > > I see we actually already have a "logmsg" parameter. It already says > > "Branch: renamed %s to %s". Could we just reuse that? I know that this > > step is technically just the deletion, but I think it more accurately > >

Re: [PATCH v3 11/16] refs.c: kill register_ref_store(), add register_submodule_ref_store()

Nguyễn Thái Ngọc Duy writes: > This is the last function in this code (besides public API) that takes > submodule argument and handles both main/submodule cases. Break it down, > move main store registration in get_main_ref_store() and keep the rest > in

Re: [PATCH v3 04/16] files-backend: replace *git_path*() with files_path()

Nguyễn Thái Ngọc Duy writes: > This centralizes all path rewriting of files-backend.c in one place so > we have easier time removing the path rewriting later. There could be > some hidden indirect git_path() though, I didn't audit the code to the > bottom. > > Side note:

Re: [PATCH v3 03/16] files-backend: add files_path()

Nguyễn Thái Ngọc Duy writes: > This will be the replacement for both git_path() and git_path_submodule() > in this file. The idea is backend takes a git path and use that, > oblivious of submodule, linked worktrees and such. > > This is the middle step towards that.

[PATCH] l10n: de.po: translate 241 messages

Translate 241 messages came from git.pot update in 673bfad09 (l10n: git.pot: v2.12.0 round 1 (239 new, 15 removed)) and a4d94835a (l10n: git.pot: v2.12.0 round 2 (2 new)). Signed-off-by: Ralf Thielow --- po/de.po | 746

Re: body-CC-comment regression

Junio C Hamano writes: > Johan Hovold writes: > >> That's precisely what the patch I posted earlier in the thread did. > > That's good. I didn't see any patch yet It's here: http://public-inbox.org/git/20170217110642.GD2625@localhost/ but as I

Re: [PATCH 12/15] unpack-trees: check if we can perform the operation for submodules

On Wed, Feb 15, 2017 at 4:38 PM, Stefan Beller wrote: > + if (is_active_submodule_with_strategy(ce, SM_UPDATE_UNSPECIFIED)) Here, and in other cases where we use is_active_submodule_with_strategy(), why do we only ever check SM_UPDATE_UNSPECIFIED? It seems really weird

Re: [PATCH 08/15] submodules: introduce check to see whether to touch a submodule

On Wed, Feb 15, 2017 at 4:38 PM, Stefan Beller wrote: > In later patches we introduce the --recurse-submodule flag for commands > that modify the working directory, e.g. git-checkout. > > It is potentially expensive to check if a submodule needs an update, > because a common

Re: [PATCH v2 00/16] Remove submodule from files-backend.c

Nguyễn Thái Ngọc Duy writes: > I'll be sending two more follow-up series, if you are interested, soon: > > 1) v2 of nd/worktree-gc-protection > > which kills parse_ref() in worktree.c _and_ set_worktree_head_symref() > in files-backend.c. Both are bad things that should not

Re: body-CC-comment regression

Johan Hovold writes: > That's precisely what the patch I posted earlier in the thread did. That's good. I didn't see any patch yet but the message you are responding to is a response to Matthieu's message asking if you are planning to work on it, so I'd assume you are and and

Re: [PATCH v3 0/2] Fix bugs in rev-parse's output when run in a subdirectory

Johannes Schindelin writes: > The bug that bit me (hard!) and that triggered not only a long series of > curses but also my writing a patch and sending it to the list was that > `git rev-parse --git-path HEAD` would give *incorrect* output when run > in a subdirectory

Re: [PATCH 06/15] update submodules: add submodule config parsing

On Wed, Feb 15, 2017 at 4:38 PM, Stefan Beller wrote: > Similar to b33a15b08 (push: add recurseSubmodules config option, > 2015-11-17) and 027771fcb1 (submodule: allow erroneous values for the > fetchRecurseSubmodules option, 2015-08-17), we add submodule-config code > that is

Re: body-CC-comment regression

On Fri, Feb 17, 2017 at 10:18:46AM -0800, Junio C Hamano wrote: > Matthieu Moy writes: > > >> On Fri, Feb 17, 2017 at 02:16:42PM +0100, Matthieu Moy wrote: > > ... > > If I had a time machine, I'd probably go back then and forbid multiple > > addresses there, but

Re: body-CC-comment regression

Matthieu Moy writes: >> On Fri, Feb 17, 2017 at 02:16:42PM +0100, Matthieu Moy wrote: > ... > If I had a time machine, I'd probably go back then and forbid multiple > addresses there, but ... > >> There does not seem to be single commit in the kernel where multiple

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

Jeff King writes: > On Thu, Feb 16, 2017 at 10:58:00PM -0500, Kyle Meyer wrote: > >> When the current branch is renamed, the deletion of the old ref is >> recorded in HEAD's log with an empty message. Now that delete_refs() >> accepts a reflog message, provide a more descriptive

Re: body-CC-comment regression

On Fri, Feb 17, 2017 at 5:16 AM, Matthieu Moy wrote: > > I mostly agree for the SoB, but why should a Cc tag have only one email? Because changing that clearly broke real and useful behavior. The "multiple email addresses" thing is bogus and wrong. Just don't do

Re: body-CC-comment regression

On Fri, Feb 17, 2017 at 05:58:11PM +0100, Matthieu Moy wrote: > > On Fri, Feb 17, 2017 at 02:16:42PM +0100, Matthieu Moy wrote: > >> Johan Hovold writes: > > > >> The "multiple emails per Cc: field" has been there for a while already > >> (b1c8a11c8024 released in 2.6.0, sept

[L10N] Kickoff for Git 2.12.0 l10n round 2

Hi guys, Git v2.12.0-rc1 introduced another two new messages need to be translated, so let's start l10n for Git 2.12.0 round 2: l10n: git.pot: v2.12.0 round 2 (2 new) Generate po/git.pot from v2.12.0-rc1 for git v2.12.0 l10n round 2. Signed-off-by: Jiang Xin

Re: [PATCH 2/3] update-ref: pass reflog message argument to delete_refs

Jeff King writes: > ... All good review comments. I briefly wondered if recording the deletion of the current branch in HEAD's reflog has much practical values (Porcelain "git branch" would not even allow deletion in the first place), but because it is a rare and unusual event,

Re: [PATCH/RFC 00/15] Fix git-gc losing objects in multi worktree

Hi Duy, On Fri, 17 Feb 2017, Nguyễn Thái Ngọc Duy wrote: > So here is my latest attempt on fixing this issue. For people who are > not aware of it, git-gc does not take per-worktree refs, reflogs and > indexes into account. An odb prune may leave HEAD and references in > other worktrees pointing

Re: [PATCH 1/3] delete_refs(): accept a reflog message argument

Jeff King writes: >> diff --git a/refs.h b/refs.h >> index 9fbff90e7..81627a63d 100644 >> --- a/refs.h >> +++ b/refs.h >> @@ -277,7 +277,7 @@ int reflog_exists(const char *refname); >> * be NULL_SHA1. flags is passed through to ref_transaction_delete(). >> */ >> int

[PATCH v3 2/2] rev-parse: fix several options when running in a subdirectory

In addition to making git_path() aware of certain file names that need to be handled differently e.g. when running in worktrees, the commit 557bd833bb (git_path(): be aware of file relocation in $GIT_DIR, 2014-11-30) also snuck in a new option for `git rev-parse`: `--git-path`. On the face of it,

[PATCH v3 1/2] rev-parse tests: add tests executed from a subdirectory

From: Michael Rappazzo t2027-worktree-list has an incorrect expectation for --git-common-dir which has been adjusted and marked to expect failure. Some of the tests added have been marked to expect failure. These demonstrate a problem with the way that some options to git

[PATCH v3 0/2] Fix bugs in rev-parse's output when run in a subdirectory

The bug that bit me (hard!) and that triggered not only a long series of curses but also my writing a patch and sending it to the list was that `git rev-parse --git-path HEAD` would give *incorrect* output when run in a subdirectory of a regular checkout, but *correct* output when run in a

Re: body-CC-comment regression

> On Fri, Feb 17, 2017 at 02:16:42PM +0100, Matthieu Moy wrote: >> Johan Hovold writes: > >> The "multiple emails per Cc: field" has been there for a while already >> (b1c8a11c8024 released in 2.6.0, sept 2015), some users may have got >> used to it. What you are proposing

Re: [PATCH v2 1/2] rev-parse tests: add tests executed from a subdirectory

Hi Junio, On Fri, 10 Feb 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh > > index 292a0720fcc..1d6e27a09d8 100755 > > --- a/t/t1700-split-index.sh > > +++ b/t/t1700-split-index.sh > > @@

Re: [PATCH v2 1/2] rev-parse tests: add tests executed from a subdirectory

Hi Junio, On Fri, 10 Feb 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > diff --git a/t/t1700-split-index.sh b/t/t1700-split-index.sh > > index 292a0720fcc..1d6e27a09d8 100755 > > --- a/t/t1700-split-index.sh > > +++ b/t/t1700-split-index.sh > > @@

Re: [PATCH v2 2/2] rev-parse: fix several options when running in a subdirectory

Hi Junio, On Fri, 10 Feb 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > diff --git a/builtin/rev-parse.c b/builtin/rev-parse.c > > index ff13e59e1db..84af2802f6f 100644 > > --- a/builtin/rev-parse.c > > +++ b/builtin/rev-parse.c > > @@ -545,6 +545,7

Re: body-CC-comment regression

On Fri, Feb 17, 2017 at 02:16:42PM +0100, Matthieu Moy wrote: > Johan Hovold writes: > > > There is another option, namely to only accept a single address for tags > > in the body. I understand that being able to copy a CC-header to either > > the header section or to the

RE: new git-diff switch to eliminate leading "+" and "-" characters

> From: Duy Nguyen [mailto:pclo...@gmail.com] > Sent: Friday, February 17, 2017 6:54 AM > To: Vanderhoof, Tzadik > Cc: git@vger.kernel.org > > > Would it make sense to develop such a switch or has there been work on > that already? > > I face this "problem" every day, but most editors nowadays

RE: new git-diff switch to eliminate leading "+" and "-" characters

> From: Duy Nguyen [mailto:pclo...@gmail.com] > Sent: Friday, February 17, 2017 6:54 AM > To: Vanderhoof, Tzadik > Cc: git@vger.kernel.org > > On Tue, Feb 14, 2017 at 6:01 AM, Vanderhoof, Tzadik > wrote: > > The output of git-diff includes lines beginning with "+"

Re: [PATCH] mingw: make stderr unbuffered again

Hi Junio, On Wed, 15 Feb 2017, Junio C Hamano wrote: > Junio C Hamano writes: > > > Johannes Schindelin writes: > > > >> FWIW I wish it were different, that git.git's `master` reflected more > >> closely what the current Git for Windows version

libgit2::git_describe_workdir() fails with depth-cloned + detached head

Hi, I have a build on Travis failing with a weird error that happens while trying to get a description from a repo. One of the integration tests that are executed on Travis executes libgit2::git_describe_workdir() on it's own repo and fails with code: -3, klass: 9, message: "object not found - no

Re: new git-diff switch to eliminate leading "+" and "-" characters

On Tue, Feb 14, 2017 at 6:01 AM, Vanderhoof, Tzadik wrote: > The output of git-diff includes lines beginning with "+" and "-" to indicate > added and deleted lines. A somewhat common task (at least for me) is to want > to copy output from a "diff" (usually the

[PATCH 15/15] rev-list: expose and document --single-worktree

Signed-off-by: Nguyễn Thái Ngọc Duy --- Documentation/rev-list-options.txt | 8 revision.c | 2 ++ 2 files changed, 10 insertions(+) diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index

[PATCH 14/15] revision.c: --reflog add HEAD reflog from all worktrees

Note that add_other_reflogs_to_pending() is a bit inefficient, since it scans reflog for all refs of each worktree, including shared refs, so the shared ref's reflog is scanned over and over again. We could update refs API to pass "per-worktree only" flag to avoid that. But long term we should be

[PATCH 13/15] files-backend: make reflog iterator go through per-worktree reflog

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs/files-backend.c | 24 +++- 1 file changed, 23 insertions(+), 1 deletion(-) diff --git a/refs/files-backend.c b/refs/files-backend.c index 011a7e256..d429f8713 100644 --- a/refs/files-backend.c +++

[PATCH 12/15] refs: add refs_for_each_reflog[_ent]()

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 19 ++- refs.h | 3 +++ 2 files changed, 17 insertions(+), 5 deletions(-) diff --git a/refs.c b/refs.c index ce165c0ea..622c6b669 100644 --- a/refs.c +++ b/refs.c @@ -1592,9 +1592,8 @@ int

[PATCH 08/15] refs: add a refs_for_each_in() and friends

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 39 +++ refs.h | 5 + 2 files changed, 36 insertions(+), 8 deletions(-) diff --git a/refs.c b/refs.c index fc6cca3db..37b03d4ff 100644 --- a/refs.c +++ b/refs.c @@ -300,34 +300,52 @@

[PATCH 11/15] revision.c: --all adds HEAD from all worktrees

Unless single_worktree is set, --all now adds HEAD from all worktrees. Since reachable.c code does not use setup_revisions(), we need to call other_head_refs_submodule() explicitly there to have the same effect on "git prune", so that we won't accidentally delete objects needed by some other

[PATCH 09/15] revision.c: use refs_for_each*() instead of for_each_*_submodule()

Signed-off-by: Nguyễn Thái Ngọc Duy --- revision.c | 48 1 file changed, 32 insertions(+), 16 deletions(-) diff --git a/revision.c b/revision.c index d82f72ff3..d82c37b44 100644 --- a/revision.c +++ b/revision.c @@ -1189,12

[PATCH 05/15] refs: add refs_read_ref[_full]()

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 19 --- refs.h | 5 + 2 files changed, 21 insertions(+), 3 deletions(-) diff --git a/refs.c b/refs.c index 9c86c44b8..06890db5d 100644 --- a/refs.c +++ b/refs.c @@ -186,16 +186,29 @@ struct ref_filter {

[PATCH 07/15] refs: add refs_for_each_ref()

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 33 ++--- refs.h | 1 + 2 files changed, 23 insertions(+), 11 deletions(-) diff --git a/refs.c b/refs.c index 26758b8cf..fc6cca3db 100644 --- a/refs.c +++ b/refs.c @@ -1170,10 +1170,9 @@ int

[PATCH 10/15] refs: remove dead for_each_*_submodule()

These are used in revision.c. After the last patch they are replaced with the refs_ version. Delete them (except for_each_remote_ref_submodule which is still used by submodule.c) Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 30 -- refs.h | 9

[PATCH 03/15] revision.c: --indexed-objects add objects from all worktrees

This is the result of single_worktree flag never being set (no way to up until now). To get objects from current index only, set single_worktree. The other add_index_objects_to_pending's caller is mark_reachable_objects() (e.g. "git prune") which also mark objects from all indexes.

[PATCH 06/15] refs: add refs_head_ref()

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 19 +-- refs.h | 1 + 2 files changed, 10 insertions(+), 10 deletions(-) diff --git a/refs.c b/refs.c index 06890db5d..26758b8cf 100644 --- a/refs.c +++ b/refs.c @@ -1139,27 +1139,26 @@ int

[PATCH 02/15] revision.c: refactor add_index_objects_to_pending()

The core code is factored out and take 'struct index_state *' instead so that we can reuse it to add objects from index files other than .git/index in the next patch. Signed-off-by: Nguyễn Thái Ngọc Duy --- revision.c | 18 -- 1 file changed, 12 insertions(+),

[PATCH 04/15] refs: move submodule slash stripping code to get_submodule_ref_store

This is a better place that will benefit all submodule callers instead of just resolve_gitlink_ref() Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 38 -- 1 file changed, 20 insertions(+), 18 deletions(-) diff --git a/refs.c b/refs.c

[PATCH/RFC 00/15] Fix git-gc losing objects in multi worktree

So here is my latest attempt on fixing this issue. For people who are not aware of it, git-gc does not take per-worktree refs, reflogs and indexes into account. An odb prune may leave HEAD and references in other worktrees pointing to nowhere. This series is based on my "kill parse_ref()" series

[PATCH 01/15] revision.h: new flag in struct rev_info wrt. worktree-related refs

The revision walker can walk through per-worktree refs like HEAD or SHA-1 references in the index. These currently are from the current worktree only. This new flag is added to change rev-list behavior in this regard: When single_worktree is set, only current worktree is considered. When it is

Hopefully

Dear friend, My name is Mr Micheal Rita, I am the Bill and Exchange (assistant) Manager of Bank of Africa Ouagadougou, Burkina Faso. In my department I discovered an abandoned sum of teen million five hundred thousand United State of American dollars (10.5MILLION USA DOLLARS) in an account that

[PATCH v3 15/16] files-backend: remove submodule_allowed from files_downcast()

Since submodule or not is irrelevant to files-backend after the last patch, remove the parameter from files_downcast() and kill files_assert_main_repository(). PS. This implies that all ref operations are allowed for submodules. But we may need to look more closely to see if that's really true...

[PATCH v3 11/16] refs.c: kill register_ref_store(), add register_submodule_ref_store()

This is the last function in this code (besides public API) that takes submodule argument and handles both main/submodule cases. Break it down, move main store registration in get_main_ref_store() and keep the rest in register_submodule_ref_store(). Signed-off-by: Nguyễn Thái Ngọc Duy

[PATCH v3 07/16] files-backend: remove the use of git_path()

Given $GIT_DIR and $GIT_COMMON_DIR, files-backend is now in charge of deciding what goes where. The end goal is to pass $GIT_DIR only. A refs "view" of a linked worktree is a logical ref store that combines two files backends together. (*) Not entirely true since strbuf_git_path_submodule() still

[PATCH v3 09/16] refs: rename lookup_ref_store() to lookup_submodule_ref_store()

With get_main_ref_store() being used inside get_ref_store(), lookup_ref_store() is only used for submodule code path. Rename to reflect that and delete dead code. Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 13 - 1 file changed, 4 insertions(+), 9

[PATCH v3 08/16] refs.c: introduce get_main_ref_store()

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 16 1 file changed, 12 insertions(+), 4 deletions(-) diff --git a/refs.c b/refs.c index 7a474198e..10994d992 100644 --- a/refs.c +++ b/refs.c @@ -1445,15 +1445,23 @@ static struct ref_store

[PATCH v3 14/16] refs: move submodule code out of files-backend.c

files-backend is now initialized with a $GIT_DIR. Converting a submodule path to where real submodule gitdir is located is done in get_ref_store(). The new code in init_submodule_ref_store() is basically a copy of strbuf_git_path_submodule(). This gives a slight performance improvement for

[PATCH v3 16/16] refs: rename get_ref_store() to get_submodule_ref_store() and make it public

This function is intended to replace *_submodule() refs API. It provides a ref store for a specific submodule, which can be operated on by a new set of refs API. Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 12 refs.h | 11

[PATCH v3 12/16] refs.c: make get_main_ref_store() public and use it

get_ref_store() will soon be renamed to get_submodule_ref_store(). Together with future get_worktree_ref_store(), the three functions provide an appropriate ref store for different operation modes. New APIs will be added to operate directly on ref stores. Signed-off-by: Nguyễn Thái Ngọc Duy

[PATCH v3 10/16] refs.c: flatten get_ref_store() a bit

This helps the future changes in this code. And because get_ref_store() is destined to become get_submodule_ref_store(), the "get main store" code path will be removed eventually. After this the patch to delete that code will be cleaner. Signed-off-by: Nguyễn Thái Ngọc Duy ---

[PATCH v3 13/16] path.c: move some code out of strbuf_git_path_submodule()

refs is learning to avoid path rewriting that is done by strbuf_git_path_submodule(). Factor out this code so it could be reused by refs* Signed-off-by: Nguyễn Thái Ngọc Duy --- path.c | 34 +++--- submodule.c | 31

[PATCH v3 02/16] files-backend: convert git_path() to strbuf_git_path()

git_path() and friends are going to be killed in files-backend.c in near future. And because there's a risk with overwriting buffer in git_path(), let's convert them all to strbuf_git_path(). We'll have easier time killing/converting strbuf_git_path() then because we won't have to worry about

[PATCH v3 05/16] refs.c: share is_per_worktree_ref() to files-backend.c

Signed-off-by: Nguyễn Thái Ngọc Duy --- refs.c | 6 -- refs/refs-internal.h | 6 ++ 2 files changed, 6 insertions(+), 6 deletions(-) diff --git a/refs.c b/refs.c index 4f845798b..7a474198e 100644 --- a/refs.c +++ b/refs.c @@ -489,12 +489,6 @@ int

[PATCH v3 04/16] files-backend: replace *git_path*() with files_path()

This centralizes all path rewriting of files-backend.c in one place so we have easier time removing the path rewriting later. There could be some hidden indirect git_path() though, I didn't audit the code to the bottom. Side note: set_worktree_head_symref() is a bad boy and should not be in

[PATCH v3 03/16] files-backend: add files_path()

This will be the replacement for both git_path() and git_path_submodule() in this file. The idea is backend takes a git path and use that, oblivious of submodule, linked worktrees and such. This is the middle step towards that. Eventually the "submodule" field in 'struct files_ref_store' should

[PATCH v3 00/16] Remove submodule from files-backend.c

v3 only changes 07/16 but it's kinda important because I broke packed-refs. packed-refs' path became $GIT_DIR/packed-refs instead of $GIT_COMMON_DIR/packed-refs and as a result the majority of refs will disappear in linked worktrees. Interdiff diff --git a/refs/files-backend.c

[PATCH v3 06/16] refs-internal.h: correct is_per_worktree_ref()

All refs outside refs/ directory is per-worktree, not just HEAD. Signed-off-by: Nguyễn Thái Ngọc Duy --- refs/refs-internal.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/refs/refs-internal.h b/refs/refs-internal.h index f4aed49f5..69d02b6ba 100644 ---

[PATCH v3 01/16] refs-internal.c: make files_log_ref_write() static

Created in 5f3c3a4e6f (files_log_ref_write: new function - 2015-11-10) but probably never used outside refs-internal.c Signed-off-by: Nguyễn Thái Ngọc Duy --- refs/files-backend.c | 3 +++ refs/refs-internal.h | 4 2 files changed, 3 insertions(+), 4 deletions(-) diff

Re: git alias for options

On Fri, Feb 17, 2017 at 9:23 AM, hIpPy wrote: > Git has aliases for git commands. Is there a (an inbuilt) way to alias > options? If not, what is the reason? This has long been on my wishlist, because there's a lot of copy/pasted logic all over Git to make git foo

Re: body-CC-comment regression

Johan Hovold writes: > There is another option, namely to only accept a single address for tags > in the body. I understand that being able to copy a CC-header to either > the header section or to the command line could be useful, but I don't > really see the point in allowing

Re: git alias for options

hIpPy venit, vidit, dixit 17.02.2017 09:23: > Git has aliases for git commands. Is there a (an inbuilt) way to alias > options? If not, what is the reason? > > Thanks, > hippy > You can setup an alias for "command with options", for example: git help s `git s' is aliased to `status -s -b -uno

dotfiles in git template dir are not copied

Hi, I noticed yesterday that dotfiles inside the directory configured in init.templatedir are not copied when creating a new repository. Here is the line I think is responsible for this behavior : https://github.com/git/git/blob/master/builtin/init-db.c#L48 Is it a bug or a feature? Steps

Re: body-CC-comment regression

On Thu, Feb 16, 2017 at 07:16:57PM +0100, Matthieu Moy wrote: > Johan Hovold writes: > > > Hi, > > > > I recently noticed that after an upgrade, git-send-email (2.10.2) > > started aborting when trying to send patches that had a linux-kernel > > stable-tag in its body. For

Re: [PATCH] tempfile: avoid "ferror | fclose" trick

On 02/17/2017 09:07 AM, Jeff King wrote: > [...] > That's similar to what I wrote earlier, but if we don't mind overwriting > errno unconditionally, I think just: > > errno = EIO; /* covers ferror(), overwritten by failing fclose() */ > err |= ferror(fp); > err |= fclose(fp); > > does the

Re: [PATCH v2 00/19] object_id part 6

On 02/14/2017 03:31 AM, brian m. carlson wrote: > This is another series in the continuing conversion to struct object_id. > > This series converts more of the builtin directory and some of the refs > code to use struct object_id. Additionally, it implements an > nth_packed_object_oid function

Re: [PATCH v2 15/19] refs: simplify parsing of reflog entries

On 02/14/2017 03:31 AM, brian m. carlson wrote: > The current code for reflog entries uses a lot of hard-coded constants, > making it hard to read and modify. Use parse_oid_hex and two temporary > variables to simplify the code and reduce the use of magic constants. > > Signed-off-by: brian m.

Re: topological index field for commit objects

On 17 February 2017 at 10:26, Jeff King wrote: > On Sat, Feb 04, 2017 at 02:43:01PM +0100, Jakub Narębski wrote: > >> Do Git use EWAH / EWOK bitmaps for reachability analysis, or is it still >> limited to object counting? >> >>> >> >>> At GitHub we are using them for

Re: [PATCH v2 14/19] hex: introduce parse_oid_hex

On 02/14/2017 03:31 AM, brian m. carlson wrote: > Introduce a function, parse_oid_hex, which parses a hexadecimal object > ID and if successful, sets a pointer to just beyond the last character. > This allows for simpler, more robust parsing without needing to > hard-code integer values throughout

Re: topological index field for commit objects

On Sat, Feb 04, 2017 at 02:43:01PM +0100, Jakub Narębski wrote: > Do Git use EWAH / EWOK bitmaps for reachability analysis, or is it still > limited to object counting? > >>> > >>> At GitHub we are using them for --contains analysis, along with mass > >>> ahead/behind (e.g., as in

Re: [PATCH v2 11/19] builtin/replace: convert to struct object_id

On 02/14/2017 03:31 AM, brian m. carlson wrote: > Convert various uses of unsigned char [20] to struct object_id. Rename > replace_object_sha1 to rename_object_oid. Finally, specify a constant > in terms of GIT_SHA1_HEXSZ. The new name is not rename_object_oid but rather replace_object_oid. >

Re: [PATCH 3/3] rename_ref: replace empty deletion message in HEAD's log

On Thu, Feb 16, 2017 at 10:58:00PM -0500, Kyle Meyer wrote: > When the current branch is renamed, the deletion of the old ref is > recorded in HEAD's log with an empty message. Now that delete_refs() > accepts a reflog message, provide a more descriptive message. This > message will not be

git alias for options

Git has aliases for git commands. Is there a (an inbuilt) way to alias options? If not, what is the reason? Thanks, hippy

Re: [PATCH 2/3] update-ref: pass reflog message argument to delete_refs

On Thu, Feb 16, 2017 at 10:57:59PM -0500, Kyle Meyer wrote: > Now that delete_refs() accepts a reflog message, pass the > user-provided message to delete_refs() rather than silently dropping > it. The doesn't matter for the deleted ref's log because the log is > deleted along with the ref, but

Re: [PATCH 0/3] delete_ref(): support reflog messages

On Thu, Feb 16, 2017 at 10:57:57PM -0500, Kyle Meyer wrote: > [Sorry for the slow response.] No problem. The pace of open source varies wildly. :) > > - "git branch -m" does seem to realize when we are renaming HEAD, > > because it updates HEAD to point to the new branch name. But it > >

Re: [PATCH 1/3] delete_refs(): accept a reflog message argument

On Thu, Feb 16, 2017 at 10:57:58PM -0500, Kyle Meyer wrote: > When the current branch is renamed with 'git branch -m/-M' or deleted > with 'git update-ref -m -d', the event is recorded in HEAD's log > with an empty message. > > In preparation for adding a more meaningful message to HEAD's log in

Re: [PATCH] tempfile: avoid "ferror | fclose" trick

On Fri, Feb 17, 2017 at 09:00:09AM +0100, Michael Haggerty wrote: > As you pointed out, if ferror() fails, it doesn't set errno properly. At > least one caller tries to strerror(errno), so it would probably be good > to store *something* in there, probably EIO. Yeah, we discussed this up-thread

Re: [PATCH] tempfile: avoid "ferror | fclose" trick

On 02/16/2017 10:31 PM, Jeff King wrote: > On Thu, Feb 16, 2017 at 11:43:59AM -0500, Jeff King wrote: > >> On Thu, Feb 16, 2017 at 11:10:18AM +0100, Andreas Schwab wrote: >> > int xfclose(FILE *fp) > { > return ferror(fp) | fclose(fp); > } Yes, that's

<    1   2