Re: Re: dotfiles in git template dir are not copied

> You could, for example, have your template directory itself be a git repository. I can and I do and indeed, that might be the reason behind this. I made a PR to document this : https://github.com/git/git/pull/325 -- greg0ire

Re: git diff --quiet exits with 1 on clean tree with CRLF conversions

Mike Crowe writes: > If "git diff --quiet" finds it necessary to compare actual file contents, > and a file requires CRLF conversion, then it incorrectly exits with an exit > code of 1 even if there have been no changes. > > The patch below adds a test file that shows the

Re: body-CC-comment regression

Matthieu Moy writes: > Junio C Hamano writes: > >> That approach may still constrain what those in the former camp can >> write in the "cruft" part, like they cannot write comma or semicolon >> as part of the "cruft", no? > > Right. Indeed, this

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

Junio C Hamano writes: > 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 >> ... >> 2) the real worktree-gc-protection >> >> This series adds a bunch of new

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

On Fri, Feb 17, 2017 at 01:17:06PM -0800, Junio C Hamano wrote: > > I guess we are simultaneously assuming that it is OK to munge errno on > > success in our function, but that fclose() will not do so. Which seems a > > bit hypocritical. Maybe the "if" dance is better. > > Yes. When both

Re: git alias for options

I think the conversation has drifted away from what I am asking / hoping for. I apologize but I do not feel in the position of submitting patches yet. I'll first need to read some code first before that. I'm coming from the angle where currently I can alias just the command (ex: l for log) not

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] tempfile: avoid "ferror | fclose" trick

Jeff King writes: > On Fri, Feb 17, 2017 at 11:42:25AM +0100, Michael Haggerty wrote: > >> 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

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

On Fri, Feb 17, 2017 at 10:55:03AM +0100, Michael Haggerty wrote: > 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

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

Hey, > @@ -916,17 +916,17 @@ msgstr "" > msgid "" > "The merge base %s is %s.\n" > "This means the first '%s' commit is between %s and [%s].\n" > msgstr "" > "Die Merge-Basis %s ist %s.\n" > "Das bedeutet, der erste '%s' Commit befindet sich zwischen %s und [%s]\n" "Das bedeutet, der erste

Re: dotfiles in git template dir are not copied

Grégoire PARIS writes: >> You could, for example, have your template directory itself be a git > repository. > > I can and I do and indeed, that might be the reason behind this. An embedded .git was _not_ the reason behind the current behaviour when we wrote it. The

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

Jeff King writes: > Thinking on it more, we probably _do_ want two entries. Because the > operations are not atomic, it's possible that we may end up in a > half-way state after the first entry is written. And when debugging such > a case, I'd much rather see the first half of the

Re: git alias for options

On Fri, Feb 17, 2017 at 9:42 PM, Jeff King wrote: > On Fri, Feb 17, 2017 at 02:50:23PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> 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 >> >

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

Jeff King writes: > On Fri, Feb 17, 2017 at 01:17:06PM -0800, Junio C Hamano wrote: > >> Stepping back a bit, would this be really needed? Even if the ferror() >> does not update errno, the original stdio operation that failed >> would have, no? > > Sure, but we have no clue what

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

On Fri, Feb 17, 2017 at 11:42:25AM +0100, Michael Haggerty wrote: > 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

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

On Fri, Feb 17, 2017 at 03:54:42PM -0500, Jeff King wrote: > I guess we are simultaneously assuming that it is OK to munge errno on > success in our function, but that fclose() will not do so. Which seems a > bit hypocritical. Maybe the "if" dance is better. So here's that patch with a

git diff --quiet exits with 1 on clean tree with CRLF conversions

If "git diff --quiet" finds it necessary to compare actual file contents, and a file requires CRLF conversion, then it incorrectly exits with an exit code of 1 even if there have been no changes. The patch below adds a test file that shows the problem. The first test of diff without --quiet

Re: git alias for options

On Fri, Feb 17, 2017 at 11:10:08PM +0100, Ævar Arnfjörð Bjarmason wrote: > > A first step in that direction would probably be an environment variable > > to tell Git to suppress command-aliases. Scripts would set that to > > ensure a more vanilla experience. It doesn't fix _existing_ scripts, but

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

On Fri, Feb 17, 2017 at 01:42:21PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > On Fri, Feb 17, 2017 at 01:17:06PM -0800, Junio C Hamano wrote: > > > >> Stepping back a bit, would this be really needed? Even if the ferror() > >> does not update errno, the original

Git bisect does not find commit introducing the bug

Hi there, According to the documentation "git bisect" is designed "to find the commit that introduced a bug" . I have found a situation in which it does not returns the commit I expected. In order to reproduce the problem: 1. mkdir test; cd test; git clone

Re: git diff --quiet exits with 1 on clean tree with CRLF conversions

On Friday 17 February 2017 at 14:05:17 -0800, Junio C Hamano wrote: > Mike Crowe writes: > > > If "git diff --quiet" finds it necessary to compare actual file contents, > > and a file requires CRLF conversion, then it incorrectly exits with an exit > > code of 1 even if there

Re: git alias for options

On Fri, Feb 17, 2017 at 02:50:23PM +0100, Ævar Arnfjörð Bjarmason wrote: > 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

Re: dotfiles in git template dir are not copied

On Fri, Feb 17, 2017 at 10:31:37AM +0100, greg0ire wrote: > 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 : >

Re: git alias for options

Jeff King writes: > On Fri, Feb 17, 2017 at 11:10:08PM +0100, Ævar Arnfjörð Bjarmason wrote: > >> The most gentle first step would be to try to turn the existing config >> options where you can override cli-options into some declarative thing >> from the current ad-hoc code we

Re: dotfiles in git template dir are not copied

> I do not think we should change the behaviour > to copy files whose names begin with a dot. So bug turned feature it is :) I amended my commit message accordingly. In my case, my template dir is not at the root of the repository where it is versioned, so it would not be a problem for me,

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

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: 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

[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 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 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 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 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 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/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

[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 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

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: [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

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: [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 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: 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: [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: [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

[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

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: 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 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 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: body-CC-comment regression

Junio C Hamano writes: > That approach may still constrain what those in the former camp can > write in the "cruft" part, like they cannot write comma or semicolon > as part of the "cruft", no? Right. Indeed, this may be a problem since the use of "#" for stable seem to

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.

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: Re: dotfiles in git template dir are not copied

From: "Grégoire PARIS" > You could, for example, have your template directory itself be a git repository. I can and I do and indeed, that might be the reason behind this. I made a PR to document this : https://github.com/git/git/pull/325 While the PR is a simple one

[PATCH v5 5/6] stash: use stash_push for no verb form

Now that we have stash_push, which accepts pathspec arguments, use it instead of stash_save in git stash without any additional verbs. Previously we allowed git stash -- -message, which is no longer allowed after this patch. Messages starting with a hyphen was allowed since 3c2eb80f, ("stash:

Re: dotfiles in git template dir are not copied

Grégoire PARIS writes: >> You could, for example, have your template directory itself be a git > repository. > > I can and I do and indeed, that might be the reason behind this. > I made a PR to document this : https://github.com/git/git/pull/325 Let's take a look. >

Re: [PATCH v5 0/6] stash: support pathspec argument

Thomas Gummerer writes: [some people may see this message twice, as I forgot to check if the copy I received had "Some A . Body" not enclosed in dq; blindly doing "Reply-All" ended up listing an invalid address on my Cc: line and dropped by vger. apologies] > diff --git

Re: [PATCH v5 6/6] stash: allow pathspecs in the no verb form

On Fri, Feb 17, 2017 at 10:41:41PM +, Thomas Gummerer wrote: > Now that stash_push is used in the no verb form of stash, allow > specifying the command line for this form as well. Always use -- to > disambiguate pathspecs from other non-option arguments. I think that makes sense. > Also

Re: [PATCH] mingw: make stderr unbuffered again

Johannes Schindelin writes: > ... there is a different problem here: you stated very explicitly > that it is okay for `pu` to be broken [*1*]. If it were different, if any > breakage would imply that a fix is really, really required lest the patch > series be evicted

[PATCH v5 3/6] stash: refactor stash_create

Refactor the internal stash_create function to use a -m flag for specifying the message and -u flag to indicate whether untracked files should be added to the stash. This makes it easier to pass a pathspec argument to stash_create in the next patch. The user interface for git stash create stays

[PATCH v5 0/6] stash: support pathspec argument

Thanks Matthieu, Peff and Junio for the discussion on v3 and v4. Changes since v4: Dropped patch 1 from the series, as it's already in master Instead of changing the external interface to git stash create, only refactor the internal create_stash() function to take -m and -u arguments. This also

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

Jeff King writes: >> If we are trying to make sure that the caller would not say "failed >> to close tempfile: ERRNO" with an ERRNO that is unrelated to any >> stdio opration, I am not sure if the patch improves things. The >> caller did not fail to close (most likely we

Re: dotfiles in git template dir are not copied

Grégoire PARIS writes: >> I do not think we should change the behaviour >> to copy files whose names begin with a dot. > > So bug turned feature it is :) There was no 'bug' either. It's just the way it is ;-)

Re: [PATCH] submodule.c: Add missing quotation marks

On 02/18, Phillip Sz wrote: > Hi, > > just found this while translating, sorry if this is intended. > > Best regards, > > Phillip Definitely not intended. Thanks for catching that. > --- > submodule.c | 4 ++-- > 1 file changed, 2 insertions(+), 2 deletions(-) > > diff --git a/submodule.c

[PATCH] Document dotfiles exclusion on template copy

Since there is no dotfile in the default template directory, there was no point in making the check for . or .. more accurate when copying. Now that you can customize the template directory, it would make sense, but it's actually a good thing to at this because you would not want to have your git

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

Jeff King writes: [...] >> diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh >> index b0ffc0b57..65918d984 100755 >> --- a/t/t1400-update-ref.sh >> +++ b/t/t1400-update-ref.sh >> @@ -85,6 +85,15 @@ test_expect_success "delete $m (by HEAD)" ' >> ' >> rm -f .git/$m >>

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

On Fri, Feb 17, 2017 at 06:40:28PM -0500, Kyle Meyer wrote: > > For reference, the two things I notice are: > > > > - we prefer test_path_is_missing to "! test -f" these days. > > > > - we don't redirect the output of grep (it's handled already in > > non-verbose mode, and in verbose mode

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

Junio C Hamano writes: [...] > Do we even want these "internal" delete_ref() invocations to be > logged in HEAD's reflog? I understand that this is inside the > implementation of renaming an old ref to a new ref, and reflog > message given to delete_ref() would matter only

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

On Fri, Feb 17, 2017 at 03:52:36PM -0800, Junio C Hamano wrote: > > So I think that "easy" thing falls far short of a solution, but it's at > > least easy. I could take it or leave it at this point. > > Well, I already said that earlier in this thread, and ended up > queuing your patch on 'pu'

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

Kyle Meyer writes: > Junio C Hamano writes: > > [...] > >> Do we even want these "internal" delete_ref() invocations to be >> logged in HEAD's reflog? I understand that this is inside the >> implementation of renaming an old ref to a new ref, and reflog >>

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

On Fri, Feb 17, 2017 at 06:41:32PM -0500, Kyle Meyer wrote: > Junio C Hamano writes: > > [...] > > > Do we even want these "internal" delete_ref() invocations to be > > logged in HEAD's reflog? I understand that this is inside the > > implementation of renaming an old ref

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

Jeff King writes: > I'm also not sure that it's all that useful to distinguish errors from > fwrite() versus fclose(). In practice, errors will come from write() in > either case, and the caller does not have much control over when the > flushing happens. So any error saying

[PATCH] remote: Ignore failure to remove missing branch..merge

If a branch is configured with a default remote but no branch..merge and then the remote is removed, git fails to remove the remote with: "fatal: could not unset 'branch..merge'" Instead, ignore this since it is not an error and shouldn't prevent the remote from being removed. Signed-off-by:

[PATCH v5 4/6] stash: teach 'push' (and 'create_stash') to honor pathspec

While working on a repository, it's often helpful to stash the changes of a single or multiple files, and leave others alone. Unfortunately git currently offers no such option. git stash -p can be used to work around this, but it's often impractical when there are a lot of changes over multiple

[PATCH v5 1/6] stash: introduce push verb

Introduce a new git stash push verb in addition to git stash save. The push verb is used to transition from the current command line arguments to a more conventional way, in which the message is given as an argument to the -m option. This allows us to have pathspecs at the end of the command

[PATCH v5 2/6] stash: add test for the create command line arguments

Currently there is no test showing the expected behaviour of git stash create's command line arguments. Add a test for that to show the current expected behaviour and to make sure future refactorings don't break those expectations. Signed-off-by: Thomas Gummerer ---

Re: body-CC-comment regression

Junio C Hamano writes: > Matthieu Moy writes: > >> Junio C Hamano writes: >> >>> That approach may still constrain what those in the former camp can >>> write in the "cruft" part, like they cannot write comma or semicolon >>>

Re: dotfiles in git template dir are not copied

> Thanks for your guidance. I believe I just sent the patch to the mailing list. I just retried with the Gmail SMTP, and now I am sure it worked. Sorry for the noobery.

Re: [PATCH] Document dotfiles exclusion on template copy

-The template directory contains files and directories that will be copied to -the `$GIT_DIR` after it is created. +The template directory contains files and directories whose name do not start +with a dot will be copied to the `$GIT_DIR` after it is created. The template directory

Re: [PATCH v5 3/6] stash: refactor stash_create

On Fri, Feb 17, 2017 at 10:41:38PM +, Thomas Gummerer wrote: > Refactor the internal stash_create function to use a -m flag for > specifying the message and -u flag to indicate whether untracked files > should be added to the stash. > > This makes it easier to pass a pathspec argument to

[ANNOUNCE] Git v2.12.0-rc2

A release candidate Git v2.12.0-rc2 is now available for testing at the usual places. It is comprised of 487 non-merge commits since v2.11.0, contributed by 67 people, 21 of which are new faces. The tarballs are found at: https://www.kernel.org/pub/software/scm/git/testing/ The following

Re: [PATCH v5 0/6] stash: support pathspec argument

On 02/17, Junio C Hamano wrote: > Thomas Gummerer writes: > > [some people may see this message twice, as I forgot to check if the > copy I received had "Some A . Body" not enclosed in dq; blindly > doing "Reply-All" ended up listing an invalid address on my Cc: line > and

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

On Fri, Feb 17, 2017 at 02:40:19PM -0800, Junio C Hamano wrote: > > Right. EIO is almost certainly _not_ the error we saw. But I would > > rather consistently say "I/O error" and have the user scratch their > > head, look up this thread, and say "ah, it was probably a deferred > > error", as

Re: dotfiles in git template dir are not copied

>There was no 'bug' either. It's just the way it is ;-) Sure !

Re: [PATCH] Document dotfiles exclusion on template copy

Thanks, will queue.

[PATCH v3 01/19] builtin/commit: convert to struct object_id

Convert most leaf functions to use struct object_id. Signed-off-by: brian m. carlson --- builtin/commit.c | 46 +++--- 1 file changed, 23 insertions(+), 23 deletions(-) diff --git a/builtin/commit.c b/builtin/commit.c index

[PATCH v3 03/19] builtin/describe: convert to struct object_id

Convert the functions in this file and struct commit_name to struct object_id. Signed-off-by: brian m. carlson --- builtin/describe.c | 50 +- 1 file changed, 25 insertions(+), 25 deletions(-) diff --git

[PATCH v3 04/19] builtin/fast-export: convert to struct object_id

In addition to converting to struct object_id, write some hardcoded buffer sizes in terms of GIT_SHA1_RAWSZ. Signed-off-by: brian m. carlson --- builtin/fast-export.c | 58 +-- 1 file changed, 29 insertions(+), 29

[PATCH v3 09/19] builtin/merge: convert to struct object_id

Additionally convert several uses of the constant 40 into GIT_SHA1_HEXSZ. Signed-off-by: brian m. carlson --- builtin/merge.c | 134 1 file changed, 66 insertions(+), 68 deletions(-) diff --git

[PATCH v3 19/19] wt-status: convert to struct object_id

Convert the remaining uses of unsigned char [20] to struct object_id. Signed-off-by: brian m. carlson --- wt-status.c | 44 ++-- 1 file changed, 22 insertions(+), 22 deletions(-) diff --git a/wt-status.c b/wt-status.c index

[PATCH v3 05/19] builtin/fmt-merge-message: convert to struct object_id

Convert most of the code to use struct object_id, including struct origin_data and struct merge_parents. Convert several instances of hardcoded numbers into references to GIT_SHA1_HEXSZ. Signed-off-by: brian m. carlson --- builtin/fmt-merge-msg.c | 70

[PATCH v3 08/19] builtin/clone: convert to struct object_id

Signed-off-by: brian m. carlson --- builtin/clone.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/builtin/clone.c b/builtin/clone.c index 3f63edbbf9..b4c929bb8a 100644 --- a/builtin/clone.c +++ b/builtin/clone.c @@ -681,7 +681,7 @@

[PATCH v3 02/19] builtin/diff-tree: convert to struct object_id

Convert most leaf functions to struct object_id. Rewrite several hardcoded numbers in terms of GIT_SHA1_HEXSZ, using an intermediate variable where that makes sense. Signed-off-by: brian m. carlson --- builtin/diff-tree.c | 38

[PATCH v3 00/19] object_id part 6

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 which provides a struct object_id version of the

[PATCH v3 10/19] Convert remaining callers of resolve_refdup to object_id

There are a few leaf functions in various files that call resolve_refdup. Convert these functions to use struct object_id internally to prepare for transitioning resolve_refdup itself. Signed-off-by: brian m. carlson --- builtin/notes.c| 18

  1   2   >