[PATCH v1 0/3] fixup fixup documenation

. Philip Oakley (3): doc: commit: --fixup/--squash can take a commit revision doc: rebase: fixup! can take an object name doc: rebase: clarify fixup! fixup! constraint Documentation/git-commit.txt | 8 Documentation/git-rebase.txt | 9 + 2 files changed, 9 insertions(+), 8

Re: Draft of Git Rev News edition 18

From: "Christian Couder" Hi, A draft of a new Git Rev News edition is available here: https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-18.md Everyone is welcome to contribute in any section either by editing the above page on GitHub and

Re: Getting the "message" given a branch designation and conversely

From: I am learning how to use git. I would like to know how: Given a branch's designation, such as "master~4", how can I see the message I furnished when I created the branch using "git commit"? Conversely, given the message I furnished to "git commit", when I created a

Re: A note from the maintainer

From: "Eric Wong" Yes, I was somewhat careful to check for proper mboxes from gmane; I just missed entire ranges :x There were a number of messages that were listed by gmane as being in the various Git for Windows lists such as msysgit, especially when the messages went to

Re: [PATCH] help: make option --help open man pages only for Git commands

From: "Junio C Hamano" To: "Ralf Thielow" Cc: ; ; Sent: Friday, August 12, 2016 11:53 PM Subject: Re: [PATCH] help: make option --help open man pages only for Git commands Junio C

[PATCH v6 00/12] Update git revisions

These are the quick fixes to Marc's comments to patches 5,6,11, and a consequential change to 12. Only the changed patches are included. Philip Oakley (12): doc: use 'symmetric difference' consistently doc: revisions - name the left and right sides doc: show the actual left, right

[PATCH v6 05/12] doc: revisions: extra clarification of ^! notation effects

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- v6 updated Cc: Jakub Narębski <jna...@gmail.com> Cc: Marc Branchaud <marcn...@xiplink.com> https://public-inbox.org/git/578E4F4A.2020708%40gmail.com/ --- Documentation/revisions.txt | 3 ++- 1 file changed, 2 inserti

[PATCH v6 11/12] doc: revisions: show revision expansion in examples

unaffected in the next commit. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- v6 updated Cc: Jakub Narębski <jna...@gmail.com> Cc: Marc Branchaud <marcn...@xiplink.com> --- Documentation/revisions.txt | 23 +-- 1 file changed, 17 insertions(+), 6

[PATCH v6 12/12] doc: revisions: sort examples and fix alignment of the unchanged

The previous commit adjusted the column alignment for revision examples which show expansion. Fix the unchanged examples and sort those that show expansions to the end of the list. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- v6 updated Cc: Marc Branchaud <marcn...@xi

[PATCH v6 06/12] doc: revisions: single vs multi-parent notation comparison

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- v6 updated Junio's final comment https://public-inbox.org/git/xmqqwpkq6b4d.fsf%40gitster.mtv.corp.google.com/ Cc: Marc Branchaud <marcn...@xiplink.com> --- Documentation/revisions.txt | 4 1 file changed, 4 insertions(+)

Re: [PATCH v5 11/12] doc: revisions: show revision expansion in examples

From: "Marc Branchaud" <marcn...@xiplink.com> On 2016-08-12 03:07 AM, Philip Oakley wrote: The revisions examples show the revison arguments and the selected commits, but do not show the intermediate step of the expansion of the special 'range' notations. Extend the examples,

Re: [PATCH v5 06/12] doc: revisions: single vs multi-parent notation comparison

From: "Marc Branchaud" <marcn...@xiplink.com> On 2016-08-12 03:07 AM, Philip Oakley wrote: Signed-off-by: Philip Oakley <philipoak...@iee.org> --- new Junio's final comment https://public-inbox.org/git/xmqqwpkq6b4d.fsf%40gitster.mtv.corp.google.com/ --- Documenta

Re: [PATCH v5 05/12] doc: revisions: extra clarification of ^! notation effects

From: "Marc Branchaud" <marcn...@xiplink.com> On 2016-08-12 03:07 AM, Philip Oakley wrote: Signed-off-by: Philip Oakley <philipoak...@iee.org> --- new Cc: Jakub Narębski <jna...@gmail.com> https://public-inbox.org/git/578E4F4A.2020708%40gmail.com/ --- Documentat

Re: [PATCH v5 00/12] Update git revisions

From: "Marc Branchaud" <marcn...@xiplink.com> On 2016-08-12 03:07 AM, Philip Oakley wrote: [2nd attempt : ISP troubles] This has grown like topsy from a little two patch series that tried to name the 2-dots notation [1] into this extended set of tweaks. Honestly, I start j

Re: Mapping old gmane numbers to existing amil servers?

From: "Eric Wong" <e...@80x24.org> Sent: Thursday, August 11, 2016 11:26 PM Philip Oakley <philipoak...@iee.org> wrote: The raw download works. My home ISP is currently blocking your email for some reason, though I do see it at my work - my iee.org alias is via my p

[PATCH v5 00/12] Update git revisions

. Hopefully my updated workflow will get the right patches to the right people. [1] https://public-inbox.org/git/0648000B273C412AB7140AE959EBC99A%40PhilipOakley/ Philip Oakley (12): doc: use 'symmetric difference' consistently doc: revisions - name the left and right sides doc: show

[PATCH v5 01/12] doc: use 'symmetric difference' consistently

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- unchanged --- Documentation/gitk.txt | 2 +- Documentation/rev-list-options.txt | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index 6ade002..6

[PATCH v5 03/12] doc: show the actual left, right, and boundary marks

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Found while checking the 'symmetric difference' documentation Unchanged from v4 --- Documentation/pretty-formats.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/pretty-formats.txt b/Documentation/

[PATCH v5 05/12] doc: revisions: extra clarification of ^! notation effects

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- new Cc: Jakub Narębski <jna...@gmail.com> https://public-inbox.org/git/578E4F4A.2020708%40gmail.com/ --- Documentation/revisions.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/Documentation/rev

[PATCH v5 07/12] doc: gitrevisions - use 'reachable' in page description

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- unchanged --- Documentation/gitrevisions.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/gitrevisions.txt b/Documentation/gitrevisions.txt index e903eb7..33039c6 100644 --- a/Documen

[PATCH v5 04/12] doc: revisions: give headings for the two and three dot notations

ularly the docbook-groff step, does not cope with two font changes, failing to return the heading font to bold after the quotation of the notation. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Cc: Marc Branchaud <marcn...@xiplink.com> Cc: Jeff King <p...@peff.net> ref email Je

[PATCH v5 02/12] doc: revisions - name the left and right sides

The terms left and right side originate from the symmetric difference. Name them there. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- unchanged --- Documentation/revisions.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/revisions

[PATCH v5 12/12] doc: revisions: sort examples and fix alignment of the unchanged

The previous commit adjusted the column alignment for revision examples which show expansion. Fix the unchanged examples and sort those that show expansions to the end of the list. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- new --- Documentation/revisions.txt | 12 ++---

[PATCH v5 08/12] doc: gitrevisions - clarify 'latter case' is revision walk

The prior sentence has too many clauses for easy parsing. Replace 'the latter case' with a direct quote. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- unchanged --- Documentation/gitrevisions.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documen

[PATCH v5 11/12] doc: revisions: show revision expansion in examples

unaffected in the next commit. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- new Cc: Jakub Narębski <jna...@gmail.com> --- Documentation/revisions.txt | 19 +-- 1 file changed, 13 insertions(+), 6 deletions(-) diff --git a/Documentation/revisions.txt b/D

[PATCH v5 09/12] doc: revisions - define `reachable`

Do not self-define `reachable`, which can lead to misunderstanding. Instead define `reachability` explictly. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- unchanged --- Documentation/revisions.txt | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff

[PATCH v5 10/12] doc: revisions - clarify reachability examples

For the r1..r2 case, the exclusion of r1, rather than inclusion of r2, would be the unexpected case in natural language for a simple linear development, i.e. start..end excludes start. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- unchanged --- Documentation/revisions.tx

[PATCH v5 06/12] doc: revisions: single vs multi-parent notation comparison

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- new Junio's final comment https://public-inbox.org/git/xmqqwpkq6b4d.fsf%40gitster.mtv.corp.google.com/ --- Documentation/revisions.txt | 4 1 file changed, 4 insertions(+) diff --git a/Documentation/revisions.txt b/Documen

[PATCH v5 00/12] Update git revisions

will get the right patches to the right people. [1] https://public-inbox.org/git/0648000B273C412AB7140AE959EBC99A%40PhilipOakley/ Philip Oakley (12): doc: use 'symmetric difference' consistently doc: revisions - name the left and right sides doc: show the actual left, right, and boundary

[PATCH v5 01/12] doc: use 'symmetric difference' consistently

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- unchanged --- Documentation/gitk.txt | 2 +- Documentation/rev-list-options.txt | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index 6ade002..6

Re: [PATCH v5 00/12] Update git revisions

I'm having trouble with my ISP is not playing ball. only cover and patch 1 were sent. Will retry with alternate service. Philip - Original Message - From: "Philip Oakley" <philipoak...@iee.org> Sent: Thursday, August 11, 2016 10:50 PM Subject: [PATCH v5 00/12] Upda

[PATCH v5 01/12] doc: use 'symmetric difference' consistently

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- unchanged --- Documentation/gitk.txt | 2 +- Documentation/rev-list-options.txt | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index 6ade002..6

[PATCH v5 00/12] Update git revisions

will get the right patches to the right people. [1] https://public-inbox.org/git/0648000B273C412AB7140AE959EBC99A%40PhilipOakley/ Philip Oakley (12): doc: use 'symmetric difference' consistently doc: revisions - name the left and right sides doc: show the actual left, right, and boundary

Re: Mapping old gmane numbers to existing amil servers?

From: "Eric Wong" <e...@80x24.org> Sent: Thursday, August 11, 2016 8:56 AM Philip Oakley <philipoak...@iee.org> wrote: Is there an accessible mapping from the old gmane message numbers to one of the remaining email list servers for the git list? Yes, I just posted ab

Re: Can cc's be included in patches sent by send-email

From: "Junio C Hamano" <gits...@pobox.com> Jacob Keller <jacob.kel...@gmail.com> writes: On Thu, Aug 11, 2016 at 12:58 AM, Jacob Keller <jacob.kel...@gmail.com> wrote: On Thu, Aug 11, 2016 at 12:32 AM, Philip Oakley <philipoak...@iee.org> wrote: While 'git

Re: Can cc's be included in patches sent by send-email

From: "Jacob Keller" <jacob.kel...@gmail.com> On Thu, Aug 11, 2016 at 12:58 AM, Jacob Keller <jacob.kel...@gmail.com> wrote: On Thu, Aug 11, 2016 at 12:32 AM, Philip Oakley <philipoak...@iee.org> wrote: While 'git send-email' can have multiple --cc="addre

Can cc's be included in patches sent by send-email

While 'git send-email' can have multiple --cc="addressee" options on the command line, is it possible for the "cc:addressee" to actually be included in the patches that are to be sent, so that different patches can have different addressee? The fortmat-patch can include appropriate

Mapping old gmane numbers to existing amil servers?

Is there an accessible mapping from the old gmane message numbers to one of the remaining email list servers for the git list? I've seen discussions about the public-inbox, but no mention of any mapping for old message references. -- Philip -- To unsubscribe from this list: send the line

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

From: "Johannes Schindelin" <johannes.schinde...@gmx.de> Hi Philip, On Fri, 5 Aug 2016, Philip Oakley wrote: In the same vein, I always want,with my workflow, to use "fixup! ". Good news for you: this is already supported. See here: https://github.com/git/

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

From: "Duy Nguyen" On Wed, Aug 3, 2016 at 6:07 PM, Johannes Schindelin wrote: It would be a totally different matter, of course, if you used the branches I publish via my GitHub repository, added fixup! and squash! commits, published the result

Re: What's cooking in git.git (Aug 2016, #02; Thu, 4)

From: "Junio C Hamano" * po/range-doc (2016-07-20) 8 commits - doc: revisions - clarify reachability examples - doc: revisions - define `reachable` - doc: gitrevisions - clarify 'latter case' is revision walk - doc: gitrevisions - use 'reachable' in page description - doc:

Re: [RFC] A Change to Commit IDs Too Ridiculous to Consider?

From: "Jon Forrest" On 7/24/2016 11:51 AM, Rodrigo Campos wrote: And what is the problem with that, if you are doing it with instructional purposes? Let's assume that this helps and not confuses later when the commits *do* change. What is the problem you face? A lot of

Re: [PATCH v4 4/8] doc: give headings for the two and three dot notations

From: "Marc Branchaud" <marcn...@xiplink.com> On 2016-07-20 05:10 PM, Philip Oakley wrote: While there, also break out the other shorthand notations and add a title for the revision range summary (which also appears in git-rev-parse, so keep it mixed case). Signed-off-b

[PATCH v4 1/8] doc: use 'symmetric difference' consistently

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/gitk.txt | 2 +- Documentation/rev-list-options.txt | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index 6ade002..6c3eb15

[PATCH v4 5/8] doc: gitrevisions - use 'reachable' in page description

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/gitrevisions.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/gitrevisions.txt b/Documentation/gitrevisions.txt index e903eb7..33039c6 100644 --- a/Documentation/gitrevisions.txt

[PATCH v4 4/8] doc: give headings for the two and three dot notations

While there, also break out the other shorthand notations and add a title for the revision range summary (which also appears in git-rev-parse, so keep it mixed case). Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/revisions.tx

[PATCH v4 7/8] doc: revisions - define `reachable`

Do not self-define `reachable`, which can lead to misunderstanding. Instead define `reachability` explictly. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/revisions.txt | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documen

[PATCH v4 6/8] doc: gitrevisions - clarify 'latter case' is revision walk

The prior sentence has too many clauses for easy parsing. Replace 'the latter case' with a direct quote. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/gitrevisions.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/gitrevisions

[PATCH v4 8/8] doc: revisions - clarify reachability examples

For the r1..r2 case, the exclusion of r1, rather than inclusion of r2, would be the unexpected case in natural language for a simple linear development, i.e. start..end excludes start. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/revisions.txt | 11 ++-

[PATCH v4 3/8] doc: show the actual left, right, and boundary marks

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Found while checking the 'symmetric difference' documentation --- Documentation/pretty-formats.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt

[PATCH v4 2/8] doc: revisions - name the left and right sides

The terms left and right side originate from the symmetric difference. Name them there. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/revisions.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/revisions.txt b/Documen

[PATCH v4 0/8] Name for A..B ranges?

reader) two dots case of a linear development where r1..r2 excludes r1 itself. The patches can be squashed together if required. Original discussion starts at: $gmane/297908 V1 patch series $gmane/298223 V2 patch series $gmane/298689 V3 patch series $gmane/299293 Philip Oakley (8): doc: use

Re: Fast-forward able commit, otherwise fail

From: "Stefan Haller" Junio C Hamano wrote: Another thing to consider is that the proposed workflow would not scale if your team becomes larger. Requiring each and every commit on the trunk to be a merge commit, whose second parent (i.e. the tip of

Re: [PATCH v3 4/8] doc: give headings for the two and three dot notations

From: "Jakub Narębski" <jna...@gmail.com> W dniu 2016-07-13 o 00:11, Philip Oakley pisze: From: "Junio C Hamano" <gits...@pobox.com> [...] I actually think this is a good place to have them described. ^ is about specifying a single commit. These two are not th

Re: [PATCH v3 0/8] Name for A..B ranges?

From: "Junio C Hamano" <gits...@pobox.com> Philip Oakley <philipoak...@iee.org> writes: This is the re-roll of the po/range-doc (2016-07-01) 3 commits and its follow on patch. The series has gained additional patches following the discussions ($gmane/298790). .. The p

Re: [PATCH v3 4/8] doc: give headings for the two and three dot notations

From: "Junio C Hamano" Marc Branchaud writes: +The '{caret}' (caret) notation +~~~ To exclude commits reachable from a commit, a prefix '{caret}' notation is used. E.g. '{caret}r1 r2' means commits reachable from

Re: [PATCH v3 7/8] doc: revisions - define `reachable`

From: "Marc Branchaud" <marcn...@xiplink.com> On 2016-07-11 04:25 PM, Philip Oakley wrote: Do not self-define `reachable`, which can lead to misunderstanding. Instead define `reachability` explictly. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentat

Re: [PATCH v3 2/8] doc: revisions - name the Left and Right sides

From: "Junio C Hamano" <gits...@pobox.com> Philip Oakley <philipoak...@iee.org> writes: The terms Left and Right side originate from the symmetric difference. Name them there. --- Sign-off? Oops - will fix. Documentation/revisions.txt | 2 +- 1 file changed, 1 in

Re: [PATCH v3 4/8] doc: give headings for the two and three dot notations

From: "Marc Branchaud" <marcn...@xiplink.com> On 2016-07-11 04:25 PM, Philip Oakley wrote: While there, also break out the other shorthand notations and add a title for the revision range summary (which also appears in git-rev-parse, so keep it mixed case). Signed-off-b

[PATCH v3 3/8] doc: show the actual left, right, and boundary marks

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Found while checking the 'symmetric difference' documentation --- Documentation/pretty-formats.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt

[PATCH v3 8/8] doc: revisions - clarify reachability examples

For the r1..r2 case, the exclusion of r1, rather than inclusion of r2, would be the unexpected case in natural language for a simple linear development, i.e. start..end excludes start. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/revisions.txt | 11 ++-

[PATCH v3 2/8] doc: revisions - name the Left and Right sides

The terms Left and Right side originate from the symmetric difference. Name them there. --- Documentation/revisions.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt index 19314e3..79f6d03 100644 ---

[PATCH v3 1/8] doc: use 'symmetric difference' consistently

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/gitk.txt | 2 +- Documentation/rev-list-options.txt | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index 6ade002..6c3eb15

[PATCH v3 5/8] doc: gitrevisions - use 'reachable' in page description

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/gitrevisions.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/gitrevisions.txt b/Documentation/gitrevisions.txt index e903eb7..33039c6 100644 --- a/Documentation/gitrevisions.txt

[PATCH v3 7/8] doc: revisions - define `reachable`

Do not self-define `reachable`, which can lead to misunderstanding. Instead define `reachability` explictly. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/revisions.txt | 14 ++ 1 file changed, 10 insertions(+), 4 deletions(-) diff --git a/Documen

[PATCH v3 6/8] doc: gitrevisions - clarify 'latter case' is revision walk

The prior sentence has too many clauses for easy parsing. Replace 'the latter case' with a direct quote. Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/gitrevisions.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/Documentation/gitrevisions

[PATCH v3 4/8] doc: give headings for the two and three dot notations

While there, also break out the other shorthand notations and add a title for the revision range summary (which also appears in git-rev-parse, so keep it mixed case). Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/revisions.txt | 23 +-- 1 file c

[PATCH v3 0/8] Name for A..B ranges?

excludes r1 itself. The patches can be squashed together if required. Original discussion starts at: $gmane/297908 V1 patch series $gmane/298223 V2 patch series $gmane/298689 Philip Oakley (8): doc: use 'symmetric difference' consistently doc: revisions - name the Left and Right sides doc

Re: [PATCH v2 4/4] doc: clarify that `^r1` will exclude `r1` itself

From: "Junio C Hamano" <gits...@pobox.com> : Saturday, July 02, 2016 12:01 AM Junio C Hamano <gits...@pobox.com> writes: On Fri, Jul 1, 2016 at 3:08 PM, Philip Oakley <philipoak...@iee.org> wrote: ~~~ To exclude commits reachable fro

Re: [PATCH v2 4/4] doc: clarify that `^r1` will exclude `r1` itself

From: "Junio C Hamano" <gits...@pobox.com> Philip Oakley <philipoak...@iee.org> writes: Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/revisions.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/r

[PATCH v2 4/4] doc: clarify that `^r1` will exclude `r1` itself

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/revisions.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/revisions.txt b/Documentation/revisions.txt index 131060c..87be9c4 100644 --- a/Documentation/revisions.txt +++ b/Documen

[PATCH v2 3/4] doc: give headings for the two and three dot notations

While there, also break out the other shorthand notations and add a title for the revision range summary (which also appears in git-rev-parse, so keep it mixed case). Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/revisions.txt | 23 +-- 1 file c

[PATCH v2 1/4] doc: use 'symmetric difference' consistently

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/gitk.txt | 2 +- Documentation/rev-list-options.txt | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index 6ade002..6c3eb15

[PATCH v2 0/4] Name for A..B ranges?

This is the re-roll of the po/range-doc (2016-06-27) 3 commits The order is slightly re-arranged, and an additional patch clarifying that ^r1 excludes r1 itself being added. The heading have been tweaked. Discussion: $gmane/297908 previous patch series $gmane/298223 Philip Oakley (4): doc

[PATCH v2 2/4] doc: show the actual left, right, and boundary marks

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Found while checking the 'symmetric difference' documentation --- Documentation/pretty-formats.txt | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt

Re: name for A..B ranges?

From: "Junio C Hamano" <gits...@pobox.com> "Philip Oakley" <philipoak...@iee.org> writes: ..., I was wondering if an alternative would be to refer to it via [use the headings of] it's notation, i.e. "the 'two-dot' range notation" (or 'syntax' is that i

Re: name for A..B ranges?

From: "Junio C Hamano" <gits...@pobox.com> "Philip Oakley" <philipoak...@iee.org> writes: Yup, I think "range" is the commonly used word in discussions here. When inventing A...B as a new thing in addition to A..B, we called the former &

[PATCH] doc: show the actual left, right, and boundary marks

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- This is a quick follow on to the 'symmetric difference' documentation patches http://thread.gmane.org/gmane.comp.version-control.git/297908/focus=298223 where I checked all the uses of 'left' to see if other terms had been used. I n

[PATCH 2/2] doc: give headings for the two and three dot notations

While there, also break out the other shorthand notations and add a title for the revision range summary (which also appears in git-rev-parse). Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/revisions.txt | 17 + 1 file changed, 13 insertions

[PATCH 1/2] doc: use 'symmetric difference' consistently

Signed-off-by: Philip Oakley <philipoak...@iee.org> --- Documentation/gitk.txt | 2 +- Documentation/rev-list-options.txt | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt index 6ade002..6c3eb15

[PATCH 0/2] Re: name for A..B ranges?

>> On Wed, Jun 22, 2016 at 08:25:59AM +0100, Philip Oakley wrote: >> >>> Is there a common name for the A..B range format (two dots) that would >>> complement the A...B (three dots) symmetric range format's name? $gmane/297908 Here is a short two patch series to h

Re: name for A..B ranges?

From: "Junio C Hamano" <gits...@pobox.com> Jeff King <p...@peff.net> writes: On Wed, Jun 22, 2016 at 08:25:59AM +0100, Philip Oakley wrote: Is there a common name for the A..B range format (two dots) that would complement the A...B (three dots) symmetric range format'

name for A..B ranges?

Hi, Is there a common name for the A..B range format (two dots) that would complement the A...B (three dots) symmetric range format's name? I was looking at the --left-right distinctions and noticed that the trail back to the symmetric range description was rather thin (it's buried within

Re: what is a snapshot?

From: "Ovatta Bianca" I read in every comparison of git vs other version control systems, that git does not record differences but takes "snapshots" I was wondering what a "snapshot" is ? Does git store at every commit the entire files which have been modified even if

Re: [PATCHv4] Documentation: triangular workflow

From: "Ramkumar Ramachandra" Junio C Hamano wrote: Jordan DE GEA wrote: > +* Allows contributors to work with Git even though they do not have > +write access to **UPSTREAM**. > > +* Allows maintainers to receive code from contributors they may not > +trust. Triangular

Re: [PATCHv4] Documentation: triangular workflow

From: "Junio C Hamano" <gits...@pobox.com> "Philip Oakley" <philipoak...@iee.org> writes: +Preparation +~~~ + +Cloning from **PUBLISH**, which is a fork of **UPSTREAM** or an empty +repository. I agree here. To clone the upstream, to which you ha

Re: [PATCHv4] Documentation: triangular workflow

From: "Jordan DE GEA" Currently, triangular workflow can be configured, but there is no documentation about it. A documentation is useful to keep configuration possibilities up-to-date. A new subsection is created in gitworkflow. Signed-off-by: Michael Haggerty

Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation

From: "Matthieu Moy" <matthieu@grenoble-inp.fr> "Philip Oakley" <philipoak...@iee.org> writes: From: "Matthieu Moy" <matthieu@grenoble-inp.fr> But then the maintainer is not the one picking changes from it (you're sending them by

Re: [RFC/PATCHv2] Documentation: triangular workflow

From: "Junio C Hamano" Jordan DE GEA writes: +TRIANGULAR WORKFLOW +--- + +In some projects, you cannot push directly to the project but have to +suggest your commits to the maintainer (e.g. pull requests). +For these

Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation

From: "Matthieu Moy" <matthieu@grenoble-inp.fr> "Philip Oakley" <philipoak...@iee.org> writes: From: "Matthieu Moy" <matthieu@grenoble-inp.fr> I don't think you will find a name that fits all use-cases. IHMO, best is to pick on

Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation

didn't get any feedback on it. I think it translates the intent better than PUSH_REMOTE. An alternative would be PUBLISH (= the repository you use to publish your changes so that the maintainer can pick them). "Philip Oakley" <philipoak...@iee.org> writes: However your gitster/g

Re: [RFC/PATCH v2] pull: add --set-upstream

From: "Erwan Mathoniere" Implement `git pull [--set-upstream | -u] ` that set tracking to the remote branch the user just pulled from. After successfully pulling from ``, for each `` described in format `:`, set `branch..remote` to `` and `branch..merge` to

Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation

From: "Junio C Hamano" <gits...@pobox.com> "Philip Oakley" <philipoak...@iee.org> writes: That said, trying to find a good name for that 'third place' is not easy. It's neither upstream, nor downstream (for Junio - the maintainer special case - git.git would be

Re: [RFC/PATCH] Triangular Workflow UI improvement: Documentation

[Just catching up with responses] From: "Jordan DE GEA" Sent: Tuesday, May 31, 2016 1:28 PM Currently, Triangular Workflow can be configured, but there is no Documentation about it. A documentation is useful to keep configuration possibilities up-to-date. The

Re: [RFC] Triangular Workflow: user friendly full implementation

From: "Jordan DE GEA" We are working on full implementation of triangular workflow feature. For now, the main options available are: - branch..pushRemote - remote.pushDefault And only setable by hands. As it can be difficult to understand, here is what we want

Re: /* compiler workaround */ - what was the issue?

From: "Stefan Beller" On Fri, May 6, 2016 at 12:57 PM, Junio C Hamano wrote: Marc Branchaud writes: On 2016-05-06 02:54 PM, Junio C Hamano wrote: I wonder if can we come up with a short and sweet notation to remind futhre

Re: /* compiler workaround */ - what was the issue?

From: "Ramsay Jones" <ram...@ramsayjones.plus.com> On 06/05/16 14:15, Philip Oakley wrote: From: "Duy Nguyen" <pclo...@gmail.com> On Fri, May 6, 2016 at 4:41 AM, Junio C Hamano <gits...@pobox.com> wrote: "Philip Oakley" <philipoak...@iee.o

Re: /* compiler workaround */ - what was the issue?

From: "Duy Nguyen" <pclo...@gmail.com> On Fri, May 6, 2016 at 4:41 AM, Junio C Hamano <gits...@pobox.com> wrote: "Philip Oakley" <philipoak...@iee.org> writes: int saved_namelen = saved_namelen; /* compiler workaround */ Which then becomes an MSV

Re: [git-for-windows] [PATCH] exec_cmd.c, sideband.c, Makefile: avoid multiple PREFIX definitions

From: "Johannes Sixt" <j...@kdbg.org> Am 05.05.2016 um 23:28 schrieb Philip Oakley: The short and sweet PREFIX can be confused when used in many places. Rename both usages to better describe their purpose. Noticed when compiling Git for Windows using MSVC/Visual Stud

Re: [PATCH] exec_cmd.c, sideband.c, Makefile: avoid multiple PREFIX definitions

From: "Junio C Hamano" <gits...@pobox.com> Philip Oakley <philipoak...@iee.org> writes: The short and sweet PREFIX can be confused when used in many places. Rename both usages to better describe their purpose. Noticed when compiling Git for Windows using MSVC/Visua

<    1   2   3   4   5   6   7   8   9   10   >