Re: [PATCH v4] doc/SubmittingPatches: correct subject guidance

rence the > `format-patch` helper arguments, and also make some minor text > clarifications in the area. > > Signed-off-by: Adam Dinwoodie <a...@dinwoodie.org> > Helped-by: Eric Sunshine <sunsh...@sunshineco.com> This looks great! Thank you for updating this documen

Re: [RFC PATCH 2/4] change submodule push test to use proper repository setup

t` a series branch. Modifying commands like git-add and similar to automatically manage .gitmodules won't cause any issue at all, as long as git itself doesn't start rejecting or complaining about repositories that have gitlinks without a .gitmodules file. - Josh Triplett

Re: Regarding "git log" on "git series" metadata

On Mon, Nov 07, 2016 at 04:42:04PM +0700, Duy Nguyen wrote: > On Mon, Nov 7, 2016 at 8:18 AM, Josh Triplett <j...@joshtriplett.org> wrote: > > Once we have gitrefs, you have both alternatives: reachable (gitref) or > > not reachable (gitlink). > > > > Howe

Re: Regarding "git log" on "git series" metadata

On Sun, Nov 06, 2016 at 12:17:10PM -0800, Jacob Keller wrote: > On Sun, Nov 6, 2016 at 9:33 AM, Josh Triplett <j...@joshtriplett.org> wrote: > > On Sun, Nov 06, 2016 at 09:14:56AM -0800, Junio C Hamano wrote: > >> Josh Triplett <j...@joshtriplett.org> writes: >

Re: Regarding "git log" on "git series" metadata

On Sun, Nov 06, 2016 at 09:14:56AM -0800, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > We could, but if we (or one of the many third-party git implementations) > > miss a case, gitlinks+reachability may appear to work in many cases with > >

Re: Regarding "git log" on "git series" metadata

On Sat, Nov 05, 2016 at 09:50:07PM -0700, Jacob Keller wrote: > On Sat, Nov 5, 2016 at 1:25 PM, Josh Triplett <j...@joshtriplett.org> wrote: > > On Sat, Nov 05, 2016 at 09:21:58PM +0100, Christian Couder wrote: > >> On Sat, Nov 5, 2016 at 4:18 PM, Josh Triplett <j...@jo

Re: Regarding "git log" on "git series" metadata

On Sat, Nov 05, 2016 at 09:21:58PM +0100, Christian Couder wrote: > On Sat, Nov 5, 2016 at 4:18 PM, Josh Triplett <j...@joshtriplett.org> wrote: > > On Sat, Nov 05, 2016 at 01:45:27PM +0100, Christian Couder wrote: > >> And with what Peff says above it looks like we will

Re: Regarding "git log" on "git series" metadata

On Sat, Nov 05, 2016 at 01:45:27PM +0100, Christian Couder wrote: > And with what Peff says above it looks like we will need ways > configure and tweak commit reachability with gitlink/gitref anyway. So > the point of gitref compared to gitlink would be that they just have a > different

Re: Regarding "git log" on "git series" metadata

>the >> server doesn't support this so I'm going to stop pushing"? > >Yes, it would be easy for the client to abort if the server fails to >advertise a particular extension. And the reverse (old client, new server) should work as well? - Josh Triplett

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 04, 2016 at 04:37:34PM -0700, Jacob Keller wrote: > On Fri, Nov 4, 2016 at 2:55 PM, Josh Triplett <j...@joshtriplett.org> wrote: > > That said, I'd *love* to have gitrefs available, for a wide variety of > > applications, and I can see an argument for introdu

Re: Regarding "git log" on "git series" metadata

its to any server until that server updates git. That said, I'd *love* to have gitrefs available, for a wide variety of applications, and I can see an argument for introducing them and waiting a few years for them to become universally available, similar to the process gitlinks went through. But I'd also love to have a backward-compatible solution. - Josh Triplett

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 04, 2016 at 09:47:41PM +0100, Christian Couder wrote: > On Fri, Nov 4, 2016 at 6:57 PM, Junio C Hamano wrote: > > > > Imagine we invent a new tree entry type, "gitref", that is similar > > to "gitlink" in that it can record a commit object name in a tree, > > but

Re: Regarding "git log" on "git series" metadata

On Fri, Nov 04, 2016 at 10:57:09AM -0700, Junio C Hamano wrote: > After your talk at LPC2016, I was thinking about your proposal to > give an option to hide certain parents from "git log" traversal. > > While I do not think we would terribly mind a new feature in the > core to support third-party

Re: [PATCH] t4014-format-patch: Adjust git_version regex to better handle distro changes to DEF_VER

On October 9, 2016 7:53:23 PM PDT, Jeremy Huddleston Sequoia <jerem...@apple.com> wrote: >Regressed-in: 480871e09ed2e5275b4ba16b278681e5a8c122ae >Signed-off-by: Jeremy Huddleston Sequoia <jerem...@apple.com> >CC: Josh Triplett <j...@joshtriplett.org> >CC: Junio C Ham

Re: git 2.10.1 test regression in t4014-format-patch.sh

On October 9, 2016 5:15:22 PM PDT, Jeremy Huddleston Sequoia wrote: >Hey Josh, > >Hope you're doing well. > >I wanted to let you know that this patch of yours, which landed in git >2.10.1, introduced some test failures, seen on macOS. > >Let me know if you need any

[PATCH v3] format-patch: Add --rfc for the common case of [RFC PATCH]

This provides a shorter and more convenient alias for --subject-prefix='RFC PATCH'. Includes documentation in the format-patch manpage, and a new test covering --rfc. Signed-off-by: Josh Triplett <j...@joshtriplett.org> --- v3: - Fix an error message referring to --subject-prefix -

Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]

On Mon, Sep 19, 2016 at 04:46:06PM -0700, Jacob Keller wrote: > On Mon, Sep 19, 2016 at 4:40 PM, Josh Triplett <j...@joshtriplett.org> wrote: > > On Mon, Sep 19, 2016 at 04:34:35PM -0700, Jeff King wrote: > >> As far as your patch goes, I'd be OK with def

Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]

On Mon, Sep 19, 2016 at 04:34:35PM -0700, Jeff King wrote: > On Mon, Sep 19, 2016 at 01:44:08PM -0700, Josh Triplett wrote: > > > On Mon, Sep 19, 2016 at 10:49:17AM -0700, Junio C Hamano wrote: > > > Andrew Donnellan <andrew.donnel...@au1.ibm.com> writes: > > >

Re: [PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]

On Mon, Sep 19, 2016 at 10:49:17AM -0700, Junio C Hamano wrote: > Andrew Donnellan writes: > > > Sounds good to me. Agreed that "RFC" is essentially the only prefix > > other than "PATCH" that I see, at least in the kernel. > > Around here I think we saw WIP too,

[PATCH v2] format-patch: Add --rfc for the common case of [RFC PATCH]

This provides a shorter and more convenient alias for --subject-prefix='RFC PATCH'. Includes documentation in the format-patch manpage, and a new test covering --rfc. Signed-off-by: Josh Triplett <j...@joshtriplett.org> --- v2: - Add documentation to the format-patch manpage

Re: [PATCH] format-patch: Add --rfc for the common case of [RFC PATCH]

On Fri, Sep 16, 2016 at 05:49:22PM -0700, Jeff King wrote: > On Fri, Sep 16, 2016 at 10:27:45AM -0700, Josh Triplett wrote: > > > By far, the most common subject-prefix I've seen other than "PATCH" is > > "RFC PATCH" (or occasionally "PATCH RFC").

[PATCH] format-patch: Add --rfc for the common case of [RFC PATCH]

This provides a shorter and more convenient alias for --subject-prefix='RFC PATCH'. Add a test covering --rfc. Signed-off-by: Josh Triplett <j...@joshtriplett.org> --- By far, the most common subject-prefix I've seen other than "PATCH" is "RFC PATCH" (or occasionally

Re: [PATCH] Move format-patch base commit and prerequisites before email signature

On Wed, Sep 14, 2016 at 03:57:36PM -0700, Junio C Hamano wrote: > Junio C Hamano writes: > > > I do not mind doing it myself, but I am already in today's > > integration cycle (which will merge a handful of topics to > > 'master'), so I won't get around to it for some time.

Re: [PATCH] Move format-patch base commit and prerequisites before email signature

On Fri, Sep 09, 2016 at 01:51:04PM -0700, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > > On Fri, Sep 09, 2016 at 12:41:56PM -0700, Junio C Hamano wrote: > >> So here is a suggested replacement. I notice that in the MIME case, > >

Re: [PATCH] Move format-patch base commit and prerequisites before email signature

uot; && > cat >msg <<-INPUT_END && > base-commit: 6ebdac1bab966b720d776aa43ca188fe378b1f4b > > ------mimemime-- > > We may want to tweak it a bit further. > > -- >8 -- > From: Josh Triplett <j...@joshtriplett.org> >

Re: [PATCH] Move format-patch base commit and prerequisites before email signature

On Thu, Sep 08, 2016 at 11:34:15AM -0700, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > > Any text below the "-- " for the email signature gets treated as part of > > the signature, and many mail clients will trim it from the quoted te

[PATCH] Move format-patch base commit and prerequisites before email signature

add tests to ensure the email signature appears last. (Patch by Junio Hamano; tests by Josh Triplett.) Signed-off-by: Josh Triplett <j...@joshtriplett.org> --- Does the above seem reasonable, for a patch that incorporates the proposed patch from Message-Id xmqqh99rpud4@gitster.mtv.corp.goo

Re: [RFC/PATCH v2 0/3] patch-id for merges

etter for "format-patch --base". I'd like > to get input from Xiaolong Ye (who worked on --base), and Josh Triplett > (who has proposed some patches in that area, and is presumably using > them). Thanks. I'd love to see a more resilient patch-id mechanism, to make it easier t

Re: format-patch base-commit: moving to above the patch?

On Wed, Sep 07, 2016 at 09:06:31AM -0700, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > > Currently, format-patch puts base-commit and prerequisite-patch-id > > information below the patch, and below the email signature. Most mail > &

Re: [PATCH 9/9] rebase -i: rearrange fixup/squash lines using the rebase--helper

On Fri, Sep 02, 2016 at 06:23:42PM +0200, Johannes Schindelin wrote: > Let's reimplement this with linear complexity (using a hash map to > match the commits' subject lines) for the common case; Sadly, the > fixup/squash feature's design neglected performance considerations, > allowing arbitrary

format-patch base-commit: moving to above the patch?

Currently, format-patch puts base-commit and prerequisite-patch-id information below the patch, and below the email signature. Most mail clients automatically trim everything below the signature marker as unimportant when quoting a mail for a reply, which would make it difficult for someone to

Re: Extending "extended SHA1" syntax to traverse through gitlinks?

On Wed, Aug 24, 2016 at 07:05:17PM +0200, Jakub Narębski wrote: > W dniu 24.08.2016 o 16:20, Josh Triplett pisze: > > On Wed, Aug 24, 2016 at 03:16:56PM +0200, Jakub Narębski wrote: > [...] > >> Not really. > >> > >> The above means only that the support f

Re: Extending "extended SHA1" syntax to traverse through gitlinks?

On Wed, Aug 24, 2016 at 03:16:56PM +0200, Jakub Narębski wrote: > W dniu 24.08.2016 o 07:36, Junio C Hamano pisze: > > Jakub Narębski writes: > > > >> The point is that submodule has it's own object database. It might > >> be the same as superproject's, but you need to handle

Re: Extending "extended SHA1" syntax to traverse through gitlinks?

On Mon, Aug 22, 2016 at 08:39:19PM +0200, Jakub Narębski wrote: > W dniu 21.08.2016 o 16:26, Josh Triplett pisze: > > On Sun, Aug 21, 2016 at 03:46:36PM +0200, Jakub Narębski wrote: > >> W dniu 21.08.2016 o 00:50, Josh Triplett pisze: > >>> Currently, if

Re: Adding more namespace support to git

On Mon, Aug 22, 2016 at 07:36:31PM +0100, Richard wrote: > On 21 Aug 2016 15:07, "Josh Triplett" <j...@joshtriplett.org> wrote: > > I'd like to see it work more automatically than that. Perhaps a > > separate environment variable to set the client-side namespace?

Re: Extending "extended SHA1" syntax to traverse through gitlinks?

On Sun, Aug 21, 2016 at 03:46:36PM +0200, Jakub Narębski wrote: > W dniu 21.08.2016 o 00:50, Josh Triplett pisze: > > Currently, if you have a branch "somebranch" that contains a gitlink > > "somecommit", you can write "somebranch:somecommit" to refe

Re: Adding more namespace support to git

On Sun, Aug 21, 2016 at 12:30:16PM +0100, Richard wrote: > On 21 August 2016 at 03:05, Josh Triplett <j...@joshtriplett.org> wrote: > > Unfortunately, I think at this point, GIT_NAMESPACE has to exclusively > > refer to the namespace for the remote end, to avoid breakage.

Re: Most recent revision that contains a string

On Sun, Aug 21, 2016 at 10:13:33AM +0200, Andreas Schwab wrote: > On Aug 20 2016, Josh Triplett <j...@joshtriplett.org> wrote: > > If you want to find a change that introduces or removes a particular > > string, you could use "git log -S". That doesn't allow regex

Re: Adding more namespace support to git

On Sat, Aug 20, 2016 at 08:07:00PM +0100, Richard wrote: > I work on a git server called gitano. > We've been using and recommending cgit for the web UI. > > I've been working on adding git namespace support to both, > so that we can separate administrative branches from code branches. > >

Re: Most recent revision that contains a string

On Sat, Aug 20, 2016 at 02:41:35PM -0700, Nikolaus Rath wrote: > Hello, > > What's the easiest way to find the most recent revision (of any file in > the repository, including those that have been deleted in the current > HEAD) that contains a given string? > > I was hoping that "git grep" would

Extending "extended SHA1" syntax to traverse through gitlinks?

doesn't support accessing a file named "x..y" or "x...y", so scripts already can't expect to access arbitrary filenames with that syntax without some kind of quoting, wich we also don't have.) Does this seem reasonable? Would a patch introducing such syntax (including documentation and

Re: Draft of Git Rev News edition 18

On Tue, Aug 16, 2016 at 09:27:04PM +, Eric Wong wrote: > Josh Triplett <j...@joshtriplett.org> wrote: > > On Tue, Aug 16, 2016 at 09:30:27AM +, Eric Wong wrote: > > > Jakub Narębski <jna...@gmail.com> wrote: > > > > It's a great pity that https://p

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 05:15:51PM -0400, Jeff King wrote: > On Tue, Aug 16, 2016 at 02:11:41PM -0700, Josh Triplett wrote: > > > > For HTTPS, I'd just as soon use HTTP-level features. > > > > ALPN, used carefully, could potentially allow eliminating one round

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 04:54:27PM -0400, Jeff King wrote: > On Tue, Aug 16, 2016 at 01:31:50PM -0700, Josh Triplett wrote: > > > > You can dig up the discussion on the list under the name "protocol v2", > > > but basically yes, that approach has been consider

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 11:50:11AM -0700, Stefan Beller wrote: > On Tue, Aug 16, 2016 at 11:28 AM, Jeff King <p...@peff.net> wrote: > > On Tue, Aug 16, 2016 at 10:34:44AM -0700, Josh Triplett wrote: > > > >> > Sadly you cannot use a capability to fix that, because

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 02:28:52PM -0400, Jeff King wrote: > On Tue, Aug 16, 2016 at 10:34:44AM -0700, Josh Triplett wrote: > > > > Sadly you cannot use a capability to fix that, because all of this > > > happens before the client agrees to any capabilities (you can find &

Re: upload-pack/ls-remote: showing non-HEAD symbolic refs?

On Tue, Aug 16, 2016 at 12:31:45PM -0400, Jeff King wrote: > On Tue, Aug 16, 2016 at 09:18:39AM -0700, Josh Triplett wrote: > > > Commit 5e7dcad771cb873e278a0571b46910d7c32e2f6c in September 2013 added > > support to upload-pack to show the symbolic target of non-HEAD symbolic

upload-pack/ls-remote: showing non-HEAD symbolic refs?

request for the targets of all symrefs? - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Draft of Git Rev News edition 18

On Tue, Aug 16, 2016 at 09:30:27AM +, Eric Wong wrote: > Jakub Narębski wrote: > > It's a great pity that https://public-inbox.org/ is just > > directory index, not a true home page. > > +Cc m...@public-inbox.org > > I'm not sure one could do better while staying true to

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Mon, Aug 15, 2016 at 12:17:11PM -0600, Simon Glass wrote: > On 1 August 2016 at 12:37, Josh Triplett <j...@joshtriplett.org> wrote: > > On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote: > >> On 07/29/2016 12:40 AM, Josh Triplett wrote: > >> >

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On August 9, 2016 11:37:31 PM HST, Richard Ipsum <richard.ip...@codethink.co.uk> wrote: >On Thu, Aug 04, 2016 at 12:40:58PM -1000, Josh Triplett wrote: >> On Wed, Aug 03, 2016 at 08:12:02PM +0100, Richard Ipsum wrote: >> > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Tr

Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

On Wed, Aug 10, 2016 at 09:30:01AM +0200, Jakub Narębski wrote: > On 10 August 2016 at 02:55, Josh Triplett <j...@joshtriplett.org> wrote: > > On Tue, Aug 09, 2016 at 06:28:00PM +, Eric Wong wrote: > >> Some of these problems I hope public-inbox (or something like &

Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

cepted attachments with inline disposition, but not all of it. All of it would go away if the submission process just involved "git push" to an appropriate location.) - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majo

Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

On Tue, Aug 09, 2016 at 06:57:05AM -0400, Jeff King wrote: > On Tue, Aug 09, 2016 at 10:11:30AM +0200, Michael J Gruber wrote: > > > Maybe two more points of input for the discussion: > > > > off-line capabilities > > = > > > > The current workflow here seems to work best

Re: [PATCH v2 1/2] format-patch: Add a config option format.from to set the default for --from

On Mon, Aug 08, 2016 at 12:54:41AM -0400, Jeff King wrote: > On Sun, Aug 07, 2016 at 06:42:07PM -1000, Josh Triplett wrote: > > > > Drop trailing comma after the last enum definition (trailing comma > > > after the last element in an array is OK, though). > > >

Re: [PATCH 1/2] format-patch: Add a config option format.from to set the default for --from

On Mon, Aug 01, 2016 at 01:32:49PM -0700, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > > +static char *from; > > static const char *signature = git_version_string; > > static const char *signature_file; > > static int config

Re: [PATCH v2 1/2] format-patch: Add a config option format.from to set the default for --from

On Mon, Aug 01, 2016 at 02:18:47PM -0700, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > +enum from { > > + FROM_AUTHOR, > > + FROM_USER, > > + FROM_VALUE, > > Drop trailing comma after the last enum definition (trailing com

Re: [PATCH v2 1/2] format-patch: Add a config option format.from to set the default for --from

On Sun, Aug 07, 2016 at 06:59:09PM -0700, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > > I'd actually seriously considered this exact approach, which I preferred > > as well, but I'd discarded it because I figured it'd get rejected. &

Re: [PATCH v2 1/2] format-patch: Add a config option format.from to set the default for --from

On Mon, Aug 01, 2016 at 01:38:47PM -0400, Jeff King wrote: > On Sat, Jul 30, 2016 at 12:11:11PM -0700, Josh Triplett wrote: > > > +enum from { > > + FROM_AUTHOR, > > + FROM_USER, > > + FROM_VALUE, > > +}; > > + > > +static void set_from(enum f

Re: patch submission process, was Re: [PATCH v6 06/16] merge_recursive: abort properly upon errors

On Mon, Sep 17, 2001 at 10:00:00AM +, Stefan Beller wrote: > But both send-email as well as mail-patch-series as well as git-series > are all about the *sending* part. Not about the back and forth part, i.e. > these don't deal with: "here is a fixup on top". And by that I mean > receiving

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Wed, Aug 03, 2016 at 08:12:02PM +0100, Richard Ipsum wrote: > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote: > > I'd welcome any feedback, whether on the interface and workflow, the > > internals and collaboration, ideas on presenting diffs of patch series, >

Re: [PATCH v2 0/2] format-patch: Transition the default to --from to avoid spoofed mails

On Mon, Aug 01, 2016 at 01:47:24PM -0400, Jeff King wrote: > On Sat, Jul 30, 2016 at 12:11:05PM -0700, Josh Triplett wrote: > > > Josh Triplett (2): > > format-patch: Add a config option format.from to set the default for > > --from > > format-patch: Defaul

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Mon, Aug 01, 2016 at 09:14:54AM -0600, Stephen Warren wrote: > On 07/29/2016 12:40 AM, Josh Triplett wrote: > > I'd like to announce a project I've been working on for a while: > > > > git-series provides a tool for managing patch series with git, tracking > > th

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Mon, Aug 01, 2016 at 07:55:54AM +, Eric Wong wrote: > Christian Couder <christian.cou...@gmail.com> wrote: > > On Fri, Jul 29, 2016 at 12:10 PM, Richard Ipsum > > <richard.ip...@codethink.co.uk> wrote: > > > On Thu, Jul 28, 2016 at 11:40:55PM -07

[PATCH v2 1/2] format-patch: Add a config option format.from to set the default for --from

This helps users who would prefer format-patch to default to --from, and makes it easier to change the default in the future. Signed-off-by: Josh Triplett <j...@joshtriplett.org> --- Documentation/config.txt | 10 ++- builtin/log.c

[PATCH v2 0/2] format-patch: Transition the default to --from to avoid spoofed mails

don't think this needs a transition period, you can go ahead and apply the second patch. v2: Unify the various places setting from into a single helper function. Josh Triplett (2): format-patch: Add a config option format.from to set the default for --from format-patch: Default to --from

[PATCH v2 2/2] format-patch: Default to --from

This avoids spoofing mails when formatting commits not written by the user. Add tests for the new default, and fix tests whose expected output depended on the old default. Signed-off-by: Josh Triplett <j...@joshtriplett.org> --- Documentation/config.txt | 2 +- builtin/log.c

Re: [PATCH 1/2] format-patch: Add a config option format.from to set the default for --from

On Sat, Jul 30, 2016 at 11:40:34AM -0400, Jeff King wrote: > On Sat, Jul 30, 2016 at 02:41:56AM -0700, Josh Triplett wrote: > > > @@ -807,6 +808,17 @@ static int git_format_config(const char *var, const > > char *value, void *cb) > > base_auto = gi

[PATCH 0/2] format-patch: Transition the default to --from to avoid spoofed mails

don't think this needs a transition period, you can go ahead and apply the second patch. Josh Triplett (2): format-patch: Add a config option format.from to set the default for --from format-patch: Default to --from Documentation/config.txt | 10 - builtin/log.c

[PATCH 1/2] format-patch: Add a config option format.from to set the default for --from

This helps users who would prefer format-patch to default to --from, and makes it easier to change the default in the future. Signed-off-by: Josh Triplett <j...@joshtriplett.org> --- Documentation/config.txt | 10 +++- builtin/log.c

[PATCH 2/2] format-patch: Default to --from

This avoids spoofing mails when formatting commits not written by the user. Add tests for the new default, and fix tests whose expected output depended on the old default. Signed-off-by: Josh Triplett <j...@joshtriplett.org> --- Documentation/config.txt | 2 +- builtin/log.c

Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

On Sat, Jul 30, 2016 at 01:47:42AM -0400, Jeff King wrote: > On Fri, Jul 29, 2016 at 09:50:55PM -0700, Josh Triplett wrote: > > > I would propose the following then: > > > > - I'll write a patch adding a config option format.from, along with > > documentation

Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

On Fri, Jul 29, 2016 at 06:58:00PM -0400, Jeff King wrote: > On Thu, Jul 28, 2016 at 07:08:02PM -0700, Josh Triplett wrote: > > > > I think on the whole that defaulting to "--from" would help more people > > > than hurt them, but if we do believe there are scr

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Fri, Jul 29, 2016 at 01:44:44PM +0100, Richard Ipsum wrote: > On Fri, Jul 29, 2016 at 04:04:26AM -0700, Josh Triplett wrote: > > I hope to use git notes with git-series in the future, by putting > > another gitlink under the git-series for notes related to the series. &

Re: [ANNOUNCE] git-series: track changes to a patch series over time

On Fri, Jul 29, 2016 at 11:10:11AM +0100, Richard Ipsum wrote: > On Thu, Jul 28, 2016 at 11:40:55PM -0700, Josh Triplett wrote: > [snip] > > > > I'd welcome any feedback, whether on the interface and workflow, the > > internals and collaboration, ideas on presenti

[ANNOUNCE] git-series: track changes to a patch series over time

S.md , including the details for how git-series ensures git can always reach, push, and pull a series. I'd welcome any feedback, whether on the interface and workflow, the internals and collaboration, ideas on presenting diffs of patch series, or anything else. - Josh Triplett -- To unsubscribe fr

Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

On Thu, Jul 28, 2016 at 08:16:19PM -0400, Jeff King wrote: > The question in my mind is whether people actually use format-patch for > things besides emailing, and if the final destination is something other > than "git am". It is a handy format because it is the least-lossy way > to move commits

Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

On Thu, Jul 28, 2016 at 02:37:04PM -0700, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > > I'd like to propose changing the default behavior of git-format-patch to > > --from (and adding a --from-author option to override, and perh

Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

On Thu, Jul 28, 2016 at 05:56:03PM -0400, Jeff King wrote: > Another way to think about it is that "--from" is a no-brainer when you > really are going to email the patches (and that's why it is has always > been the default behavior in git-send-email). But if you _aren't_ going > to mail the

Re: [RFC] git-format-patch: default to --from to avoid spoofed mails?

On Thu, Jul 28, 2016 at 03:14:48PM -0700, Junio C Hamano wrote: > Jeff King writes: > > I think the original reason I did not make "--from" the default is that > > I was worried about breaking consumers which do not know how to handle > > in-body headers. > > That's a fair

[RFC] git-format-patch: default to --from to avoid spoofed mails?

both handle the --from format without any issues. Before I write such a patch: does anyone see a problem with such a change? - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: format-patch with pager.format-patch=true gets very confused

On Sun, Jul 17, 2016 at 02:41:48PM +0200, Johannes Schindelin wrote: > Hi Josh, > > On Sat, 16 Jul 2016, Josh Triplett wrote: > > > git-config(1) documents the ability to enable or disable the pager (or > > set a command-specific pager) for any command by setting &g

format-patch with pager.format-patch=true gets very confused

atch, but for format-patch *without* stdout to ignore pager.* and *never* spawn a pager, given that its only output (the list of patch files) goes to "realstdout". - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to major

Re: gc and repack ignore .git/*HEAD when checking reachability

On Sat, Jul 09, 2016 at 09:35:24AM +0200, Johannes Schindelin wrote: > On Fri, 8 Jul 2016, Junio C Hamano wrote: > > Josh Triplett <j...@joshtriplett.org> writes: > > > > > That sounds reasonable. And if they *do* end up taking any time to > > > traverse, i

Re: gc and repack ignore .git/*HEAD when checking reachability

nces." (Where "those locations" will need to expand to mention "*HEAD".) (Also, I'd suggest "*HEAD", possibly limited to characters matching [-_A-Z], rather than "*_HEAD".) - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: gc and repack ignore .git/*HEAD when checking reachability

On Fri, Jul 08, 2016 at 10:14:33AM -0700, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > > That sounds reasonable. And if they *do* end up taking any time to > > traverse, it's because they weren't reachable from other anchoring > > po

Re: gc and repack ignore .git/*HEAD when checking reachability

On Thu, Jul 07, 2016 at 09:34:02PM -0700, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > This could result in data loss, if a user expected that having an object > > referenced from those places would protect it from pruning. > > Yeah, lucki

gc and repack ignore .git/*HEAD when checking reachability

ial" refs, to provide compatibility with any other tool or future version of git that introduces another such ref.) This seems fairly easily done with a new variant of do_head_ref that includes all such refs, along with a one-line change to mark_reachable_objects to use it. Does this seem like

Easiest way to clone over an existing directory?

Currently, every time I set up a new system, I run the following: git clone $MY_HOMEDIR mv home/.git . rm -r home git checkout -f This seems like an odd dance to go through. But I can't just git clone into ~ directly, because git clone will not clone into an existing non-empty directory. (I

Re: Properties of trees referencing commit objects (mode 160000)?

On Mon, Mar 21, 2016 at 01:57:13AM -0400, Jeff King wrote: > On Sun, Mar 20, 2016 at 04:22:02PM -0700, Josh Triplett wrote: > > > I want to track the evolution of a patch series or other commit history, > > through non-fast-forwarding actions like rebase, rebase -i, or

Re: Properties of trees referencing commit objects (mode 160000)?

On Sun, Mar 20, 2016 at 04:07:25PM -0400, Jeff King wrote: > On Sun, Mar 20, 2016 at 11:45:24AM -0700, Josh Triplett wrote: > > > No, we do not follow "gitlinks" like this for reachability. Neither for > > > pruning, nor for object transfer via push/fetch. So you'

Re: Properties of trees referencing commit objects (mode 160000)?

On Sun, Mar 20, 2016 at 03:30:27PM -0700, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > > On Sun, Mar 20, 2016 at 12:18:04AM -0400, Jeff King wrote: > >> On Sat, Mar 19, 2016 at 03:13:48PM -0700, Josh Triplett wrote: > >> > >&

Re: Properties of trees referencing commit objects (mode 160000)?

On Sun, Mar 20, 2016 at 12:18:04AM -0400, Jeff King wrote: > On Sat, Mar 19, 2016 at 03:13:48PM -0700, Josh Triplett wrote: > > > I'm building some tools to track commit objects, and I'm thinking of > > using submodule-style references to commit objects in tree objects (mode &g

Properties of trees referencing commit objects (mode 160000)?

discard it as unreachable? - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html

Re: Can't git stash after using git add -N

On Tue, Mar 15, 2016 at 09:51:35PM -0700, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > > As far as I can tell, if I run "git add -N" on a file, and then commit > > without adding the file contents, it gets committed as an empty

Re: Can't git stash after using git add -N

On Tue, Mar 15, 2016 at 04:46:48PM -0700, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > After using "git add -N", "git stash" can no longer stash: > > I think this is unfortunately one of the fundamental limitations > that c

Can't git stash after using git add -N

of a 1 file changed, 1 insertion(+) create mode 100644 a /tmp/temp$ echo b > b /tmp/temp$ git add -N b /tmp/temp$ git stash error: Entry 'b' not uptodate. Cannot merge. Cannot save the current worktree state - Josh Triplett -- To unsubscribe from this list: send the line "unsubscribe git"

Re: Resumable git clone?

On Wed, Mar 02, 2016 at 12:41:20AM -0800, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > If you clone a repository, and the connection drops, the next attempt > > will have to start from scratch. This can add significant time and > > expense i

Re: Resumable git clone?

On Wed, Mar 02, 2016 at 12:31:16AM -0800, Junio C Hamano wrote: > Josh Triplett <j...@joshtriplett.org> writes: > > I think several simpler optimizations seem > > preferable, such as binary object names, and abbreviating complete > > object sets ("I have th

Re: Resumable git clone?

On Wed, Mar 02, 2016 at 03:22:17PM +0700, Duy Nguyen wrote: > On Wed, Mar 2, 2016 at 3:13 PM, Josh Triplett <j...@joshtriplett.org> wrote: > > On Wed, Mar 02, 2016 at 02:30:24AM +, Al Viro wrote: > >> On Tue, Mar 01, 2016 at 05:40:28PM -0800, Stefan Beller wrote: >

  1   2   >