Re: [PATCH 3/3] branch: forbid refs/heads/HEAD

On Sat, 2017-10-21 at 17:57 +0900, Junio C Hamano wrote: > ... The code may already > handle it, or there may need even more code to support the rename; I > didn't check. > As far as I could see there the code does seem to already handle the rename. This part of builtin/branch.c is what seems to

Re: [PATCH 0/3] a small branch API clean-up

On Sat, 2017-10-21 at 17:52 +0900, Junio C Hamano wrote: > > Sorry, but I am not sure what you are asking. > > I was looking at the code, noticed NEEDSWORK comment and worked on > cleaning things up---you seem to feel that I need a reason, or > perhaps even your permission, when I try

Re: [PATCH v3 4/4] status: test --ignored=matching

Jameson Miller writes: > Add tests around status reporting ignord files that match an exclude > pattern for both --untracked-files=normal and --untracked-files=all. > > Signed-off-by: Jameson Miller > --- > t/t7519-ignored-mode.sh | 183 >

Re: [PATCH 0/6] Create Git/Packet.pm

Christian Couder writes: > Goal > Totally offtopic, but is it only me who finds these "section headers" in cover letters from some people irritating and/or jarring? It perhaps is because I view the cover letter more as a part of conversation, not a

Re: [PATCH 5/6] t0021/rot13-filter: add capability functions

Christian Couder writes: > Add functions to help read and write capabilities. > These functions will be reused in following patches. One more thing that is more noteworthy (read: do not forget to describe it in the proposed log message) is that the original used to

Re: [PATCH 4/6] t0021/rot13-filter: add packet_initialize()

Christian Couder writes: > +sub packet_initialize { > + my ($name, $version) = @_; > + > + ( packet_txt_read() eq ( 0, $name . "-client" ) ) || die "bad > initialize"; > + ( packet_txt_read() eq ( 0, "version=" . $version ) ) || die "bad >

Re: [PATCH 1/6] t0021/rot13-filter: refactor packet reading functions

Christian Couder writes: > To make it possible in a following commit to move packet > reading and writing functions into a Packet.pm module, > let's refactor these functions, so they don't handle > printing debug output and exiting. > > Signed-off-by: Christian Couder

Re: [PATCH v4] commit: check result of resolve_ref_unsafe

Jeff King writes: >> Hello, >> I think this way is better for user experience: >> * git doesn't crash; >> * warning is shown; >> * commit has been successfully created then it's safe to show a summary >> message >> with already known information and without resolved HEAD. > > I'm

Re: [PATCH 4/4] worktree: handle broken symrefs in find_shared_symref()

Jeff King writes: > On Sat, Oct 21, 2017 at 06:49:15AM -0400, Eric Sunshine wrote: > >> On Thu, Oct 19, 2017 at 1:49 PM, Jeff King wrote: >> > The refs_resolve_ref_unsafe() function may return NULL even >> > with a REF_ISSYMREF flag if a symref points to a broken

RE: [RFE] Add minimal universal release management capabilities to GIT

-Original Message- From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On Behalf of.mail...@laposte.net On October 20, 2017 6:41 AM, nicolas wrote: To: git@vger.kernel.org Subject: [RFE] Add minimal universal release management capabilities to GIT >Git is a wonderful tool,

Re: [PATCH 4/4] worktree: handle broken symrefs in find_shared_symref()

On Sat, Oct 21, 2017 at 06:49:15AM -0400, Eric Sunshine wrote: > On Thu, Oct 19, 2017 at 1:49 PM, Jeff King wrote: > > The refs_resolve_ref_unsafe() function may return NULL even > > with a REF_ISSYMREF flag if a symref points to a broken ref. > > As a result, it's possible for

Re: [RFE] Add minimal universal release management capabilities to GIT

- Mail original - De: "Stefan Beller" >> Unfortunately Git is so good more and more developers start to procrastinate >> on any activity that happens outside of GIT, >> starting with cutting releases. The meme "one only needs a git commit hash" >> is going strong, even infecting

Re: [Alt. PATCH] ls-remote: deprecate -h as short for --heads

René Scharfe writes: > FWIW, I use "-?" for that everywhere. I have yet to find a command or > environment where it does something dangerous. Yeah, it would have made the world a better place if we made that choice back in 2008. If we start a transition to make it so right now,

Re: [PATCH 4/4] worktree: handle broken symrefs in find_shared_symref()

On Thu, Oct 19, 2017 at 1:49 PM, Jeff King wrote: > The refs_resolve_ref_unsafe() function may return NULL even > with a REF_ISSYMREF flag if a symref points to a broken ref. > As a result, it's possible for find_shared_symref() to > segfault when it passes NULL to strcmp(). >

Re: [Alt. PATCH] ls-remote: deprecate -h as short for --heads

Am 20.10.2017 um 07:35 schrieb Junio C Hamano: > Jeff King writes: > >> It seems weird and inconsistent to me that the meaning of "-h" >> depends on the position and presence of other unrelated options. The position is relevant with parse-options for *each* flag for a different

Re: [PATCH 2/3] branch: split validate_new_branchname() into two

Kaartic Sivaraam writes: >> +/* >> + * Check if a branch 'name' can be created as a new branch; die otherwise. >> + * 'force' can be used when it is OK for the named branch already exists. >> + * Return 1 if the named branch already exists; return 0 otherwise. >> + *

Re: [PATCH 3/3] branch: forbid refs/heads/HEAD

Kaartic Sivaraam writes: >> The only difference is improved tests where we use show-ref to make >> sure refs/heads/HEAD does not exist when it shouldn't, exercise >> update-ref to create and delete refs/heads/HEAD, and also make sure >> it can be deleted with "git

Re: [PATCH 0/3] a small branch API clean-up

Kaartic Sivaraam writes: > On Fri, 2017-10-13 at 14:11 +0900, Junio C Hamano wrote: >> This started as a little clean-up for a NEEDSWORK comment in >> branch.h, but it ended up adding a rather useful safety feature. >> > > Part of this series seems to duplicate the

Re: [Alt. PATCH] ls-remote: deprecate -h as short for --heads

On Fri, Oct 20, 2017 at 02:35:36PM +0900, Junio C Hamano wrote: > I may be biased as every time I think about this one, the first one > that comes to my mind is how "grep -h" (not "git grep", but GNU > grep) behaves. Yes, "-h" means something else, but by itself, the > command does not make

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

On Sat, 21 Oct 2017, Jeff King wrote: > On Fri, Oct 20, 2017 at 04:04:10AM -0400, Robert P. J. Day wrote: > > > > > I don't think there's any reason to go slow in marking something as > > > > deprecated. It's the part where we follow up and remove or change the > > > > feature that must take a

Re: [PATCH v2 2/2] mark git stash push deprecated in the man page

On Thu, Oct 19, 2017 at 07:33:04PM +0100, Thomas Gummerer wrote: > 'git stash push' fixes a historical wart in the interface of 'git stash > save'. As 'git stash push' has all functionality of 'git stash save', > with a nicer, more consistent user interface deprecate 'git stash > save'. To do

Re: [PATCH v2 1/2] replace git stash save with git stash push in the documentation

On Thu, Oct 19, 2017 at 07:33:03PM +0100, Thomas Gummerer wrote: > diff --git a/git-stash.sh b/git-stash.sh > index 8b2ce9afda..16919277ba 100755 > --- a/git-stash.sh > +++ b/git-stash.sh > @@ -267,11 +267,11 @@ push_stash () { > # translation of "error: " takes in your

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

On Fri, Oct 20, 2017 at 04:04:10AM -0400, Robert P. J. Day wrote: > > > I don't think there's any reason to go slow in marking something as > > > deprecated. It's the part where we follow up and remove or change the > > > feature that must take a while. > > > > Makes sense, let me drop it from

Re: [PATCH v4] commit: check result of resolve_ref_unsafe

On Fri, Oct 20, 2017 at 04:09:30PM +0300, Andrey Okoshkin wrote: > Add check of the resolved HEAD reference while printing of a commit summary. > resolve_ref_unsafe() may return NULL pointer if underlying calls of lstat() or > open() fail in files_read_raw_ref(). > Such situation can be caused by