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 prepare
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
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
> imp
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 () {
> > por
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
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
> >
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
> > m
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 t
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 more
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 related,
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 don'
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, "interpret-traile
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 :
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 : 'sta...@vger.kernel
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 ignorant of
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
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
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))
> >> +
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 &quo
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 `g
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
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 d
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
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
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 aut
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:
>
>
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 crea
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 wi
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 i
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 no
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.
>
> St
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 che
32 matches
Mail list logo
