Re: Re* [ANNOUNCE] Git v2.27.0-rc1

On Wed, May 20, 2020 at 01:31:30PM -0700, Junio C Hamano wrote: > The promotion in Git 2.26 was buried in the "performance & > implementation details" section and not in the backward > compatibility section, so it feels a bit funny to highlight the > reversion. In any case, here is what I

Re: [ANNOUNCE] Git v2.27.0-rc1

On Wed, May 20, 2020 at 12:17:11PM -0700, Junio C Hamano wrote: > Git 2.27 Release Notes (draft) > == > > Updates since v2.26 > --- > > Backward compatibility notes Is it worth mentioning here the reversion of v2 as the default protocol? It does end

Re: [Breakage] Git v2.21.0-rc0 - t5318 (NonStop)

On Sat, Feb 09, 2019 at 09:39:43AM +0100, Johannes Sixt wrote: > > Great. Since it sounds like you're preparing some patches to deal with > > /dev/zero elsewhere, do you want to wrap it up in a patch as part of > > that? > > Please do not use yes to generate an infinite amount of bytes. Our >

Re: [Breakage] Git v2.21.0-rc0 - t5318 (NonStop)

On Fri, Feb 08, 2019 at 05:53:53PM -0500, Randall S. Becker wrote: > > diff --git a/t/test-lib-functions.sh b/t/test-lib-functions.sh index > > 92cf8f812c..4afab14431 100644 > > --- a/t/test-lib-functions.sh > > +++ b/t/test-lib-functions.sh > > @@ -1302,3 +1302,8 @@ test_set_port () { > >

Re: [Breakage] Git v2.21.0-rc0 - t5318 (NonStop)

On Fri, Feb 08, 2019 at 05:12:43PM -0500, Randall S. Becker wrote: > On February 8, 2019 17:07, brian m. carlson wrote: > > On Fri, Feb 08, 2019 at 02:31:57PM -0500, Jeff King wrote: > > > > It is available AFAIK on Linux, POSIX, and Windows under Cygwin. > > > &g

Re: [Breakage] Git v2.21.0-rc0 - t5318 (NonStop)

On Fri, Feb 08, 2019 at 02:26:17PM -0500, Randall S. Becker wrote: > > > For this, we could use truncate -s count file instead of dd to get a > > > fixed size file of nulls. This would remove the need for /dev/zero in > > > t5318 (the patch below probably will wrap badly in my mailer so I can > >

Re: [Breakage] Git v2.21.0-rc0 - t5318 (NonStop)

On Fri, Feb 08, 2019 at 01:47:04PM -0500, Randall S. Becker wrote: > > Though I suspect we may be able to just find a solution that works > > everywhere, without having two different implementations. If we know we > > need $count bytes for dd, we could probably just generate a file with that > >

Re: [Breakage] Git v2.21.0-rc0 - t5318 (NonStop)

On Fri, Feb 08, 2019 at 12:49:59PM -0500, Randall S. Becker wrote: > > We did discuss this at the time of the patch, but it seems we already use > > /dev/zero in a bunch of places: > > > > https://public-inbox.org/git/xmqqbm57rkg5@gitster-ct.c.googlers.com/ > > > > Were you just skipping

Re: [Breakage] Git v2.21.0-rc0 - t5318 (NonStop)

On Fri, Feb 08, 2019 at 06:08:33AM -0500, Randall S. Becker wrote: > t5318 is rather problematic and I have no good way to fix this. There > is no /dev/zero on the platform, and the corrupt_graph_and_verify > hard-codes if=/dev/zero, which is a linux-specific pseudo device. > Please provide a

Re: git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)

On Fri, Feb 24, 2017 at 12:03:45PM +0100, Geert Uytterhoeven wrote: > > The problem isn't on the applying end, but rather on the generating end. > > The From header in the attached mbox is: > > > > From: =?us-ascii?B?PT9VVEYtOD9xP1NpbW9uPTIwU2FuZHN0cj1DMz1CNm0/PQ==?= > > >

Re: git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)

On Fri, Feb 24, 2017 at 12:03:45PM +0100, Geert Uytterhoeven wrote: > > The problem isn't on the applying end, but rather on the generating end. > > The From header in the attached mbox is: > > > > From: =?us-ascii?B?PT9VVEYtOD9xP1NpbW9uPTIwU2FuZHN0cj1DMz1CNm0/PQ==?= > > > > Slightly

Re: git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)

On Thu, Feb 23, 2017 at 07:04:44AM +0100, Greg KH wrote: > > Poor Simon Sandström. > > > > Funnily enough, this only exists for one commit. You've got several > > other commits from Simon that get his name right. > > > > What happened? > > I don't know what happened, I used git for this, I

Re: git email From: parsing (was Re: [GIT PULL] Staging/IIO driver patches for 4.11-rc1)

On Thu, Feb 23, 2017 at 07:04:44AM +0100, Greg KH wrote: > > Poor Simon Sandström. > > > > Funnily enough, this only exists for one commit. You've got several > > other commits from Simon that get his name right. > > > > What happened? > > I don't know what happened, I used git for this, I

Re: [RFC for GIT] pull-request: add praise to people doing QA

On Thu, Jan 19, 2017 at 09:43:45PM +0100, Wolfram Sang wrote: > > As to the implementation, I am wondering if we can make this somehow > > work well with the "trailers" code we already have, instead of > > inventing yet another parser of trailers. > > > > In its current shape,

Re: [RFC for GIT] pull-request: add praise to people doing QA

On Thu, Jan 19, 2017 at 09:43:45PM +0100, Wolfram Sang wrote: > > As to the implementation, I am wondering if we can make this somehow > > work well with the "trailers" code we already have, instead of > > inventing yet another parser of trailers. > > > > In its current shape,

Re: [char-misc-next] mei: request async autosuspend at the end of enumeration

On Thu, Nov 24, 2016 at 10:37:14PM +, Winkler, Tomas wrote: > > > > Cc: # 4.4+ > > > > > > Looks like git send-email is not able to parse this address correctly > > > though this is suggested format by Documentation/stable_kernel_rules.txt. > > > Create wrong address

Re: [char-misc-next] mei: request async autosuspend at the end of enumeration

On Thu, Nov 24, 2016 at 10:37:14PM +, Winkler, Tomas wrote: > > > > Cc: # 4.4+ > > > > > > Looks like git send-email is not able to parse this address correctly > > > though this is suggested format by Documentation/stable_kernel_rules.txt. > > > Create wrong address If git parsers is used :

Re: [char-misc-next] mei: request async autosuspend at the end of enumeration

On Thu, Nov 24, 2016 at 04:10:49PM +, Winkler, Tomas wrote: > > Cc: # 4.4+ > > Looks like git send-email is not able to parse this address correctly > though this is suggested format by Documentation/stable_kernel_rules.txt. > Create wrong address If git parsers is

Re: [char-misc-next] mei: request async autosuspend at the end of enumeration

On Thu, Nov 24, 2016 at 04:10:49PM +, Winkler, Tomas wrote: > > Cc: # 4.4+ > > Looks like git send-email is not able to parse this address correctly > though this is suggested format by Documentation/stable_kernel_rules.txt. > Create wrong address If git parsers is used :

Re: [PATCH] apply: refuse touching a file beyond symlink

On Fri, Jan 30, 2015 at 12:20:02PM -0800, Junio C Hamano wrote: > Jeff King writes: > > > I had the impression that we did not apply in any arbitrary order that > > could work, but rather that we did deletions first followed by > > additions. But I am fairly ig

Re: [PATCH] apply: refuse touching a file beyond symlink

On Fri, Jan 30, 2015 at 12:11:30PM -0800, Junio C Hamano wrote: > I am not sure how to fix this, without completely ripping out the > misguided "We should be able to concatenate outputs from multiple > invocations of 'git diff' into a single file and apply the result > with a single invocation of

Re: [PATCH] apply: refuse touching a file beyond symlink

On Fri, Jan 30, 2015 at 11:48:14AM -0800, Junio C Hamano wrote: > Jeff King writes: > > >> + if (!patch->is_delete && path_is_beyond_symlink(patch->new_name)) > >> + return error(_("affected file '%s' is beyond a symbolic link"

Re: [PATCH] apply: refuse touching a file beyond symlink

On Fri, Jan 30, 2015 at 11:42:49AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > On Thu, Jan 29, 2015 at 12:45:22PM -0800, Junio C Hamano wrote: > > > >> + if (!patch->is_delete && path_is_beyond_symlink(patch->new_name)) > >> +

Re: [PATCH 2/1] apply: reject input that touches outside $cwd

On Fri, Jan 30, 2015 at 11:07:34AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > It looks like your new --allow-uplevel goes to verify_path(). So this > > isn't just about "..", but it will also protect against applying a patch > > inside ".gi

Re: [PATCH 2/1] apply: reject input that touches outside $cwd

On Thu, Jan 29, 2015 at 03:48:14PM -0800, Junio C Hamano wrote: > By default, a patch that affects outside the working area is > rejected as a mistake; Git itself never creates such a patch > unless the user bends backwards and specifies nonstandard > prefix to "git diff" and friends. > > When

Re: [PATCH] apply: refuse touching a file beyond symlink

On Thu, Jan 29, 2015 at 12:45:22PM -0800, Junio C Hamano wrote: > +static int path_is_beyond_symlink(const char *name_) > +{ > + struct strbuf name = STRBUF_INIT; > + > + strbuf_addstr(, name_); > + do { > + struct patch *previous; > + > + while (--name.len &&

Re: [PATCH] apply: refuse touching a file beyond symlink

On Thu, Jan 29, 2015 at 12:45:22PM -0800, Junio C Hamano wrote: +static int path_is_beyond_symlink(const char *name_) +{ + struct strbuf name = STRBUF_INIT; + + strbuf_addstr(name, name_); + do { + struct patch *previous; + + while (--name.len

Re: [PATCH] apply: refuse touching a file beyond symlink

On Fri, Jan 30, 2015 at 12:20:02PM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: I had the impression that we did not apply in any arbitrary order that could work, but rather that we did deletions first followed by additions. But I am fairly ignorant of the apply code

Re: [PATCH 2/1] apply: reject input that touches outside $cwd

On Thu, Jan 29, 2015 at 03:48:14PM -0800, Junio C Hamano wrote: By default, a patch that affects outside the working area is rejected as a mistake; Git itself never creates such a patch unless the user bends backwards and specifies nonstandard prefix to git diff and friends. When `git

Re: [PATCH] apply: refuse touching a file beyond symlink

On Fri, Jan 30, 2015 at 11:48:14AM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: + if (!patch-is_delete path_is_beyond_symlink(patch-new_name)) + return error(_(affected file '%s' is beyond a symbolic link), + patch-new_name); Why does

Re: [PATCH] apply: refuse touching a file beyond symlink

On Fri, Jan 30, 2015 at 12:11:30PM -0800, Junio C Hamano wrote: I am not sure how to fix this, without completely ripping out the misguided We should be able to concatenate outputs from multiple invocations of 'git diff' into a single file and apply the result with a single invocation of 'git

Re: [PATCH 2/1] apply: reject input that touches outside $cwd

On Fri, Jan 30, 2015 at 11:07:34AM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: It looks like your new --allow-uplevel goes to verify_path(). So this isn't just about .., but it will also protect against applying a patch inside .git. Which seems like a good thing to me

Re: [PATCH] apply: refuse touching a file beyond symlink

On Fri, Jan 30, 2015 at 11:42:49AM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: On Thu, Jan 29, 2015 at 12:45:22PM -0800, Junio C Hamano wrote: + if (!patch-is_delete path_is_beyond_symlink(patch-new_name)) + return error(_(affected file '%s' is beyond

Re: project wide: git config entry for [diff] renames=true

On Thu, Sep 25, 2014 at 08:48:31AM -0700, Joe Perches wrote: > On Thu, 2014-09-25 at 17:03 +0200, Greg Kroah-Hartman wrote: > > > In the future, please generate a git "move" diff, which makes it easier > > to review, and prove that nothing really changed. It also helps if the > > file is a bit

Re: project wide: git config entry for [diff] renames=true

On Thu, Sep 25, 2014 at 08:48:31AM -0700, Joe Perches wrote: On Thu, 2014-09-25 at 17:03 +0200, Greg Kroah-Hartman wrote: In the future, please generate a git move diff, which makes it easier to review, and prove that nothing really changed. It also helps if the file is a bit different

Re: [ANNOUNCE] Git v1.9-rc0

On Mon, Jan 27, 2014 at 02:56:28PM -0800, Junio C Hamano wrote: > > # replace this with however you store your oauth token > > # if you don't have one, make one here: > > # https://github.com/settings/tokens/new > > token() { > > pass -n github.web.oauth > > Hmph, what is this "pass" thing?

Re: [ANNOUNCE] Git v1.9-rc0

On Mon, Jan 27, 2014 at 02:56:28PM -0800, Junio C Hamano wrote: # replace this with however you store your oauth token # if you don't have one, make one here: # https://github.com/settings/tokens/new token() { pass -n github.web.oauth Hmph, what is this pass thing? It's a poor

Re: [ANNOUNCE] Git v1.9-rc0

On Thu, Jan 23, 2014 at 10:15:33AM -0800, Junio C Hamano wrote: > Jeff King writes: > > > Junio, since you prepare such tarballs[1] anyway for kernel.org, it > > might be worth uploading them to the "Releases" page of git/git. I > > imagine there is a programm

Re: [ANNOUNCE] Git v1.9-rc0

On Thu, Jan 23, 2014 at 10:15:33AM -0800, Junio C Hamano wrote: Jeff King p...@peff.net writes: Junio, since you prepare such tarballs[1] anyway for kernel.org, it might be worth uploading them to the Releases page of git/git. I imagine there is a programmatic way to do so via GitHub's

Re: [ANNOUNCE] Git v1.9-rc0

On Wed, Jan 22, 2014 at 08:30:30PM +, Ken Moffat wrote: > Two questions: Does regenerating (e.g. if the tarball has dropped > out of the cache) change its sums (md5sum or similar) ? In (beyond) > linuxfromscratch we use md5sums to verify that a tarball has not > changed. The tarballs we

Re: [ANNOUNCE] Git v1.9-rc0

On Wed, Jan 22, 2014 at 08:30:30PM +, Ken Moffat wrote: Two questions: Does regenerating (e.g. if the tarball has dropped out of the cache) change its sums (md5sum or similar) ? In (beyond) linuxfromscratch we use md5sums to verify that a tarball has not changed. The tarballs we

Re: [PATCH] commit: Add -f, --fixes option to add Fixes: line

On Mon, Oct 28, 2013 at 11:10:13PM +0100, Thomas Rast wrote: > * In your list > > > Fixes: > > Reported-by: > > Suggested-by: > > Improved-by: > > Acked-by: > > Reviewed-by: > > Tested-by: > > Signed-off-by: > > and I might add > > Cherry-picked-from: > Reverts: > >

Re: [PATCH] commit: Add -f, --fixes option to add Fixes: line

On Mon, Oct 28, 2013 at 12:29:32PM +0100, Johan Herland wrote: > > A hook-based solution could do this. But a built-in "all-purpose" > > handler like "footer.Fixes.arg=commit", which was intended to be > > reusable, wouldn't be able to do such footer-specific extra work without > > having to

Re: [PATCH] commit: Add -f, --fixes commit option to add Fixes: line

On Mon, Oct 28, 2013 at 12:29:32PM +0100, Johan Herland wrote: A hook-based solution could do this. But a built-in all-purpose handler like footer.Fixes.arg=commit, which was intended to be reusable, wouldn't be able to do such footer-specific extra work without having to create new

Re: [PATCH] commit: Add -f, --fixes commit option to add Fixes: line

On Mon, Oct 28, 2013 at 11:10:13PM +0100, Thomas Rast wrote: * In your list Fixes: Reported-by: Suggested-by: Improved-by: Acked-by: Reviewed-by: Tested-by: Signed-off-by: and I might add Cherry-picked-from: Reverts: if one were to phrase

Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

On Tue, Oct 23, 2012 at 03:06:59PM -0700, Marc Gauthier wrote: > Can a later commit be eventually be made to reference some set > of notes added so far, so they become part of the whole history > signed by the HEAD SHA1? hence pulled/pushed automatically as > well. Otherwise do you not end up

Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

On Tue, Oct 23, 2012 at 11:25:06PM +0200, Thomas Gleixner wrote: > > The resulting notes are stored in a separate revision-controlled branch > > Which branch(es) is/are that ? What are the semantics of that? They are stored in refs/notes/commits by default, but you can have multiple notes refs

Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

On Tue, Oct 23, 2012 at 10:09:46PM +0100, Catalin Marinas wrote: > > It is spelled: > > > > git notes add -m SHA1 > > > > The resulting notes are stored in a separate revision-controlled branch > > and can be pushed and pulled like regular refs. Note, though, that the > > default refspecs do

Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote: > I agree that this is a common issue. Acked-by/Reviewed-by mails come > in after the fact that the patch has been committed to an immutable > (i.e no-rebase mode) branch or if the change in question already hit > Linus tree. > >

Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

On Tue, Oct 23, 2012 at 10:47:28PM +0200, Thomas Gleixner wrote: I agree that this is a common issue. Acked-by/Reviewed-by mails come in after the fact that the patch has been committed to an immutable (i.e no-rebase mode) branch or if the change in question already hit Linus tree. Still

Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

On Tue, Oct 23, 2012 at 10:09:46PM +0100, Catalin Marinas wrote: It is spelled: git notes add -m comment SHA1 The resulting notes are stored in a separate revision-controlled branch and can be pushed and pulled like regular refs. Note, though, that the default refspecs do not yet

Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

On Tue, Oct 23, 2012 at 11:25:06PM +0200, Thomas Gleixner wrote: The resulting notes are stored in a separate revision-controlled branch Which branch(es) is/are that ? What are the semantics of that? They are stored in refs/notes/commits by default, but you can have multiple notes refs if

Re: [PATCH] tile: support GENERIC_KERNEL_THREAD and GENERIC_KERNEL_EXECVE

On Tue, Oct 23, 2012 at 03:06:59PM -0700, Marc Gauthier wrote: Can a later commit be eventually be made to reference some set of notes added so far, so they become part of the whole history signed by the HEAD SHA1? hence pulled/pushed automatically as well. Otherwise do you not end up with

Re: [GIT PULL] sound fixes for 3.6-rc6

On Thu, Sep 13, 2012 at 02:28:51PM +0200, Takashi Iwai wrote: > > FWIW, it was an output from git-pull-request, which fell back to the > > equivalent branch. Usually I check it manually but I forgot it at > > this time just before going to a meeting. > > > > This was with git 1.7.11.5. I'll

Re: [GIT PULL] sound fixes for 3.6-rc6

On Thu, Sep 13, 2012 at 02:28:51PM +0200, Takashi Iwai wrote: FWIW, it was an output from git-pull-request, which fell back to the equivalent branch. Usually I check it manually but I forgot it at this time just before going to a meeting. This was with git 1.7.11.5. I'll check