Wherefor worktrees?

On 2018-09-26 11:48 AM, Duy Nguyen wrote: I believe the main selling point of multiple worktrees is sharing refs. You could easily avoid expensive clones with --local, but synchronizing between different clones is not very convenient. Other than that, different worktrees tend to behave like

[PATCH] fetch: Ensure that fetch.recurseSubmodules overrides submodule.recurse.

Also document this fact. Signed-off-by: Marc Branchaud --- I ran into this bug when I had both fetch.recurseSubmodules=on-demand and submodule.recurse=true, and submodule.recurse was set *after* fetch.recurseSubmodules in my config. The fix ensures that fetch.recurseSubmodules always overrides

Re: Is rebase --force-rebase any different from rebase --no-ff?

with -f as a synonym). M. --- Best Regards, Ilya Kantor On Wed, May 9, 2018 at 10:27 PM, Marc Branchaud <marcn...@xiplink.com> wrote: On 2018-05-09 02:21 PM, Stefan Beller wrote: +cc Marc and Johannes who know more about rebase. On Wed, May 9, 2018 at 9:01 AM, Ilya

Re: Is rebase --force-rebase any different from rebase --no-ff?

On 2018-05-09 02:21 PM, Stefan Beller wrote: +cc Marc and Johannes who know more about rebase. On Wed, May 9, 2018 at 9:01 AM, Ilya Kantor wrote: Right now in "git help rebase" for --no-ff: "Without --interactive, this is a synonym for --force-rebase." But *with*

Re: [RFC PATCH] checkout: Force matching mtime between files

On 2018-04-27 01:03 PM, Duy Nguyen wrote: On Wed, Apr 25, 2018 at 5:18 PM, Marc Branchaud <marcn...@xiplink.com> wrote: The best approach to do so is to have those people do the "touch" thing in their own post-checkout hook. People who use Git as the source control system w

Re: [RFC PATCH] checkout: Force matching mtime between files

On 2018-04-25 09:25 PM, Junio C Hamano wrote: Marc Branchaud <marcn...@xiplink.com> writes: But Git is not an archiver (tar), but is a source code control system, so I do not think we should spend any extra cycles to "improve" its behaviour wrt the relative ordering, at least

Re: [RFC PATCH] checkout: Force matching mtime between files

On 2018-04-25 04:48 AM, Junio C Hamano wrote: "Robin H. Johnson" writes: In the thread from 6 years ago, you asked about tar's behavior for mtimes. 'tar xf' restores mtimes from the tar archive, so relative ordering after restore would be the same, and would only rebuild

Re: [RFC PATCH] checkout: Force matching mtime between files

On 2018-04-13 01:01 PM, Michał Górny wrote: Currently git does not control mtimes of files being checked out. This means that the only assumption you could make is that all files created or modified within a single checkout action will have mtime between start time and end time of this

Re: [PATCH V2] config: add --expiry-date

On 2017-11-14 01:21 AM, Christian Couder wrote: On Tue, Nov 14, 2017 at 3:04 AM, wrote: From: Haaris Description: This patch adds a new option to the config command. Uses flag --expiry-date as a data-type to covert date-strings to timestamps when

Re: Recovering from gc errors

(It turned out that this problem is related to worktrees. CCing some worktree folks.) On 2017-11-14 12:53 AM, Jeff King wrote: On Mon, Nov 13, 2017 at 04:13:19PM -0500, Marc Branchaud wrote: Various incantations of "git show ... 9c355a7726e31" only fail with the same error,

Recovering from gc errors

(I'm using git 2.15.0.) So today "git gc" started complaining: error: Could not read 2bc277bcb7e9cc6ef2ea677dd1c3dcd1f9af0c2b fatal: Failed to traverse parents of commit 9c355a7726e31b3033b8e714cf7edb4f0a41d8d4 error: failed to run repack I suspect I'm a victim of the worktree+submodule bugs

Re: [RFC PATCH] proposal for refs/tracking/* hierarchy

On 2017-06-23 04:54 PM, Junio C Hamano wrote: Jacob Keller writes: Instead, lets add support for a new refs/tracking/* hierarchy which is laid out in such a way to avoid this inconsistency. All refs in "refs/tracking//*" will include the complete ref, such that

[PATCHv2 (resend)] Tweak help auto-correct phrasing.

called a Git command named 'lgo', which does not exist. Continuing under the assumption that you meant 'log'. Signed-off-by: Marc Branchaud <marcn...@xiplink.com> --- So here's the patch again. M. help.c | 18 -- 1 file changed, 12 insertions(+),

Re: [PATCHv2] Tweak help auto-correct phrasing.

On 2017-06-20 02:04 PM, Kaartic Sivaraam wrote: On Tue, 2016-12-20 at 09:02 -0500, Marc Branchaud wrote: When auto-correct is enabled, an invalid git command prints a warning and a continuation message, which differs depending on whether or not help.autoCorrect is positive or negative

Re: proposal for how to share other refs as part of refs/tracking/*

On 2017-06-13 10:41 AM, Marc Branchaud wrote: So I like your refs/tracking proposal, and hope that it aims for mirroring a remote's refs, to eventually replace refs/remotes entirely. To be extra-clear: I think a refs/tracking hierarchy that starts with notes and maybe some other bits

Re: proposal for how to share other refs as part of refs/tracking/*

On 2017-06-12 06:58 PM, Jacob Keller wrote: Hi, There's no actual code yet, (forgive me), but I've been thinking back to a while ago about attempting to find a way to share things like refs/notes, and similar refs which are usually not shared across a remote. By default, those refs are not

Re: [PATCH] tag: duplicate mention of --contains should mention --no-contains

On 2017-05-15 11:01 AM, Ævar Arnfjörð Bjarmason wrote: On Mon, May 15, 2017 at 4:20 PM, Marc Branchaud <marcn...@xiplink.com> wrote: On 2017-05-15 08:23 AM, Ævar Arnfjörð Bjarmason wrote: Fix a duplicate mention of --contains in the SYNOPSIS to mention --no-contains. This fixes an

Re: [PATCH] tag: duplicate mention of --contains should mention --no-contains

On 2017-05-15 08:23 AM, Ævar Arnfjörð Bjarmason wrote: Fix a duplicate mention of --contains in the SYNOPSIS to mention --no-contains. This fixes an error introduced in my commit ac3f5a3468 ("ref-filter: add --no-contains option to tag/branch/for-each-ref", 2017-03-24). Signed-off-by: Ævar

Re: What's cooking in git.git (May 2017, #03; Wed, 10)

On 2017-05-10 01:18 AM, Junio C Hamano wrote: * mb/diff-default-to-indent-heuristics (2017-05-09) 4 commits - add--interactive: drop diff.indentHeuristic handling - diff: enable indent heuristic by default - diff: have the diff-* builtins configure diff before initializing revisions - diff:

Re: [PATCH v4 2/4] diff: have the diff-* builtins configure diff before initializing revisions

On 2017-05-08 11:22 PM, Jeff King wrote: On Mon, May 08, 2017 at 12:03:37PM -0400, Marc Branchaud wrote: This matches how the diff Porcelain works. It makes the plumbing commands respect diff's configuration options, such as indentHeuristic, because init_revisions() calls diff_setup() which

[PATCH v4 1/4] diff: make the indent heuristic part of diff's basic configuration

to respect the setting. The heuristic itself merely makes the diffs more aesthetically pleasing, without changing their correctness. Scripts that rely on the diff plumbing commands should not care whether or not the heuristic is employed. Signed-off-by: Marc Branchaud <marcn...@xiplink.

[PATCH v4 2/4] diff: have the diff-* builtins configure diff before initializing revisions

This matches how the diff Porcelain works. It makes the plumbing commands respect diff's configuration options, such as indentHeuristic, because init_revisions() calls diff_setup() which fills in the diff_options struct. Signed-off-by: Marc Branchaud <marcn...@xiplink.com> --- builti

[PATCH v4 3/4] diff: enable indent heuristic by default

ly new line after line 2, instead of simply duplicating it. Helped-by: Jeff King <p...@peff.net> Signed-off-by: Stefan Beller <sbel...@google.com> Signed-off-by: Marc Branchaud <marcn...@xiplink.com> --- diff.c | 2 +- t/t4051-diff-function-context.s

[PATCH v4 4/4] add--interactive: drop diff.indentHeuristic handling

From: Jeff King <p...@peff.net> Now that diff.indentHeuristic is handled automatically by the plumbing commands, there's no need to propagate it manually. Signed-off-by: Jeff King <p...@peff.net> Signed-off-by: Marc Branchaud <marcn...@xiplink.com> --- git-add--interactive.per

[PATCH v4 0/4] Make diff plumbing commands respect the indentHeuristic.

): add--interactive: drop diff.indentHeuristic handling Marc Branchaud (2): diff: make the indent heuristic part of diff's basic configuration diff: have the diff-* builtins configure diff before initializing revisions Stefan Beller (1): diff: enable indent heuristic by default builtin/diff

Enabling the diff "indent" heuristic by default

On 2017-05-08 03:48 AM, Junio C Hamano wrote: * mb/diff-default-to-indent-heuristics (2017-05-02) 4 commits (merged to 'next' on 2017-05-08 at 158f401a92) I think there's a general open question about this, which is whether or not we should just drop the diff.indentHeuristic configuration

[PATCHv3 3/4] diff: enable indent heuristic by default

ly new line after line 2, instead of simply duplicating it. Helped-by: Jeff King <p...@peff.net> Signed-off-by: Stefan Beller <sbel...@google.com> Signed-off-by: Marc Branchaud <marcn...@xiplink.com> --- Tested the sed "2a" command's escaping in both Ubuntu 17.04 a

[PATCHv3 4/4] add--interactive: drop diff.indentHeuristic handling

From: Jeff King <p...@peff.net> Now that diff.indentHeuristic is handled automatically by the plumbing commands, there's no need to propagate it manually. Signed-off-by: Jeff King <p...@peff.net> Signed-off-by: Marc Branchaud <marcn...@xiplink.com> --- git-add--interactive.per

[PATCHv3 0/4] Make diff plumbing commands respect the indentHeuristic.

On 2017-04-29 09:14 AM, Jeff King wrote: > On Sat, Apr 29, 2017 at 08:40:52AM -0400, Jeff King wrote: > >> On Fri, Apr 28, 2017 at 06:33:12PM -0400, Marc Branchaud wrote: >> >>> v2: Fixed up the commit messages and added tests. >>> >>> Marc Brancha

[PATCHv3 1/4] diff: make the indent heuristic part of diff's basic configuration

to respect the setting. The heuristic itself merely makes the diffs more aesthetically pleasing, without changing their correctness. Scripts that rely on the diff plumbing commands should not care whether or not the heuristic is employed. Signed-off-by: Marc Branchaud <marcn...@xiplink.

[PATCHv3 2/4] diff: have the diff-* builtins configure diff before initializing revisions

This matches how the diff Porcelain works. It makes the plumbing commands respect diff's configuration options, such as indentHeuristic, because init_revisions() calls diff_setup() which fills in the diff_options struct. Signed-off-by: Marc Branchaud <marcn...@xiplink.com> --- builti

[PATCHv2 2/3] diff: have the diff-* builtins configure diff before initializing revisions

This makes the commands respect diff configuration options, such as indentHeuristic, because init_revisions() calls diff_setup() which fills in the diff_options struct. Signed-off-by: Marc Branchaud <marcn...@xiplink.com> --- builtin/diff-files.c | 2 +- builtin/diff-index.c

[PATCH 3/3] diff: enable indent heuristic by default

(which includes plumbing commands, see prior patches). Signed-off-by: Stefan Beller <sbel...@google.com> Signed-off-by: Marc Branchaud <marcn...@xiplink.com> --- diff.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/diff.c b/diff.c index da96577ea..2c47ccb4a 100644

[PATCHv2 1/3] diff: make the indent heuristic part of diff's basic configuration

to respect the setting. The heuristic itself merely makes the diffs more aesthetically pleasing, without changing their correctness. Scripts that rely on the diff plumbing commands should not care whether or not the heuristic is employed. Signed-off-by: Marc Branchaud <marcn...@xiplink.

[PATCHv2 0/3] Make diff plumbing commands respect the indentHeuristic.

v2: Fixed up the commit messages and added tests. Marc Branchaud (2): diff: make the indent heuristic part of diff's basic configuration diff: have the diff-* builtins configure diff before initializing revisions Stefan Beller (1): diff: enable indent heuristic by default builtin

[PATCH 0/2] Make diff plumbing commands respect the indentHeuristic.

is respected regardless of when diff_setup() is invoked. M. Marc Branchaud (2): Make the indent heuristic part of diff's basic configuration. Have the diff-* builtins configure diff before initializing revisions. builtin/diff-files.c | 2 +- builtin/diff-index.c | 2 +- builtin

[PATCH 2/2] Have the diff-* builtins configure diff before initializing revisions.

This makes the commands respect diff configuration options, such as indentHeuristic. Signed-off-by: Marc Branchaud <marcn...@xiplink.com> --- builtin/diff-files.c | 2 +- builtin/diff-index.c | 2 +- builtin/diff-tree.c | 2 +- 3 files changed, 3 insertions(+), 3 deletions(-) diff

[PATCH 1/2] Make the indent heuristic part of diff's basic configuration.

Signed-off-by: Marc Branchaud <marcn...@xiplink.com> --- diff.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/diff.c b/diff.c index 11eef1c85..da96577ea 100644 --- a/diff.c +++ b/diff.c @@ -290,9 +290,6 @@ int git_diff_ui_config(const char *var, const char

BUG: diff-{index,files,tree} (and git-gui) do not respect the diff.indentHeuristic config setting

So I have diff.indentHeuristic = true and I noticed that git-gui was not using the heuristic. This is because git-gui uses diff-index, and that does not respect the config setting, even though it supports the --indent-heuristic option. And it looks like diff-files and diff-tree

Re: [PATCH] Do not require Python for the git-remote-{bzr,hg} placeholder scripts

On 2017-03-03 05:57 AM, Sebastian Schuberth wrote: It does not make sense for these placeholder scripts to depend on Python just because the real scripts do. At the example of Git for Windows, we would not even be able to see those warnings as it does not ship with Python. So just use plain

Re: [RFC][Git GUI] Make Commit message field in git GUI re sizable.

On 2017-02-22 06:59 AM, Jessie Hernandez wrote: HI, the reason why it is fixed, is because commit messages should be wrapped at 76 characters to be used in mails. So it helps you with the wrapping. Bert Right ok. I understand. Knowing this I think I might start writing my commit messages

Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references

On 2016-12-19 11:44 AM, Michael Haggerty wrote: This patch series changes a bunch of details about how remote-tracking references are rendered in the commit list of gitk: I don't see this series in git v2.12.0-rc0, nor in Paul's gitk repo. I hope this is an oversight, and not that the series

Re: [RFC] stash --continue

On 2017-01-19 04:30 PM, Johannes Schindelin wrote: At this point I will stop commenting on this issue, as I have said all that I wanted to say about it, at least once. If I failed to get my points across so far, I simply won't be understood. Yes, we're obviously looking at this from

Re: [RFC] stash --continue

On 2017-01-19 10:49 AM, Johannes Schindelin wrote: Hi Marc, On Wed, 18 Jan 2017, Marc Branchaud wrote: On 2017-01-18 11:34 AM, Johannes Schindelin wrote: On Wed, 18 Jan 2017, Marc Branchaud wrote: On 2017-01-16 05:54 AM, Johannes Schindelin wrote: On Mon, 16 Jan 2017, Stephan Beyer

Re: [RFC] stash --continue

On 2017-01-18 11:34 AM, Johannes Schindelin wrote: Hi Marc, On Wed, 18 Jan 2017, Marc Branchaud wrote: On 2017-01-16 05:54 AM, Johannes Schindelin wrote: On Mon, 16 Jan 2017, Stephan Beyer wrote: a git-newbie-ish co-worker uses git-stash sometimes. Last time he used "git stash pop

Re: [RFC] stash --continue

On 2017-01-16 05:54 AM, Johannes Schindelin wrote: Hi Stephan, On Mon, 16 Jan 2017, Stephan Beyer wrote: a git-newbie-ish co-worker uses git-stash sometimes. Last time he used "git stash pop", he got into a merge conflict. After he resolved the conflict, he did not know what to do to get the

Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references

On 2016-12-22 03:15 AM, Michael Haggerty wrote: On 12/21/2016 08:07 PM, Marc Branchaud wrote: On 2016-12-20 07:05 PM, Michael Haggerty wrote: On 12/20/2016 04:01 PM, Marc Branchaud wrote: [...] Please don't change the remotebgcolor default. Also, perhaps the default remoterefbgcolor should

Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references

On 2016-12-20 07:05 PM, Michael Haggerty wrote: On 12/20/2016 04:01 PM, Marc Branchaud wrote: On 2016-12-19 11:44 AM, Michael Haggerty wrote: This patch series changes a bunch of details about how remote-tracking references are rendered in the commit list of gitk: Thanks for this! I like

Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references

On 2016-12-20 05:17 PM, Paul Mackerras wrote: On Tue, Dec 20, 2016 at 10:01:15AM -0500, Marc Branchaud wrote: On 2016-12-19 11:44 AM, Michael Haggerty wrote: This patch series changes a bunch of details about how remote-tracking references are rendered in the commit list of gitk: Thanks

Re: [PATCH 00/13] gitk: tweak rendering of remote-tracking references

On 2016-12-19 11:44 AM, Michael Haggerty wrote: This patch series changes a bunch of details about how remote-tracking references are rendered in the commit list of gitk: Thanks for this! I like the new, compact look very much! That said, I remember when I was a new git user and I leaned

[PATCHv2] Tweak help auto-correct phrasing.

called a Git command named 'lgo', which does not exist. Continuing under the assumption that you meant 'log'. Signed-off-by: Marc Branchaud <marcn...@xiplink.com> --- Writing the commit message was more work than the commit! :) M. help.c | 18 -- 1 file

[PATCH] Tweak help auto-correct phrasing.

Signed-off-by: Marc Branchaud <marcn...@xiplink.com> --- On 2016-12-18 07:48 PM, Chris Packham wrote: > > This feature already exists (although it's not interactive). See > help.autoCorrect in the git-config man page. "git config > help.autoCorrect -1" should to the tr

[PATCH] Release note spelling and phrasing fixups.

Signed-off-by: Marc Branchaud <marcn...@xiplink.com> --- Mostly just missing words and what I feel are clarifications. The biggest change is to the "git add -N" item. Not 100% sure I got it right. M. Documentation/RelNotes/

Re: [ANNOUNCE] Git v2.11.0-rc3

On 2016-11-23 06:21 PM, Junio C Hamano wrote: * The original command line syntax for "git merge", which was "git merge HEAD ...", has been deprecated for quite some time, and "git gui" was the last in-tree user of the syntax. This is finally fixed, so that we can move forward with

Re: BUG: indent-with-non-tab always on

On 2016-08-15 12:55 PM, Marc Branchaud wrote: On 2016-08-15 11:00 AM, Philip Oakley wrote: From: "Marc Branchaud" <marcn...@xiplink.com> On 2016-08-12 07:45 PM, Philip Oakley wrote: These are the quick fixes to Marc's comments to patches 5,6,11, and a consequential cha

BUG: indent-with-non-tab always on (was: Re: [PATCH v6 00/12] Update git revisions)

On 2016-08-15 11:00 AM, Philip Oakley wrote: From: "Marc Branchaud" <marcn...@xiplink.com> On 2016-08-12 07:45 PM, Philip Oakley wrote: 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.

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

On 2016-08-12 07:45 PM, Philip Oakley wrote: 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. Looks good to me -- no further comments! However, I still don't understand why git says 11/12 has "indent with

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

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 just trying point out something concrete, like misrendered

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

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, including an all-parents multi-parent merge commit example. Sort

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

On 2016-08-12 03:07 AM, Philip Oakley wrote: Signed-off-by: Philip Oakley --- 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

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

On 2016-08-12 03:07 AM, Philip Oakley wrote: Signed-off-by: Philip Oakley --- new Cc: Jakub Narębski https://public-inbox.org/git/578E4F4A.2020708%40gmail.com/ --- Documentation/revisions.txt | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff

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

On 2016-08-12 03:07 AM, 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). We do not quote the notation within the headings as the asciidoc -> docbook ->

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

On 2016-07-21 03:54 PM, Philip Oakley wrote: 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-re

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

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-by: Philip Oakley ---

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

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-by: Philip Oakley ---

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

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 --- Documentation/revisions.txt | 14 ++ 1 file changed, 10 insertions(+),

Re: [PATCH v5 0/5] Better ref summary alignment in "git fetch"

On 2016-07-01 12:03 PM, Nguyễn Thái Ngọc Duy wrote: v5 changes the substitute symbol from '$' to '*' in compact mode and makes sure long lines in compact mode will not make the remote ref column too big (it's far from perfect but I think it's still good to do). I think the first 4 patches are

Re: [PATCH v3 1/6] git-fetch.txt: document fetch output

On 2016-06-04 11:11 PM, Nguyễn Thái Ngọc Duy wrote: This documents the ref update status of fetch. The structure of this output is defined in [1]. The ouput content is refined a bit in [2] [3] [4]. This patch is a copy from git-push.txt, modified a bit because the flag '-' means different

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

On 2016-06-03 01:04 PM, Junio C Hamano wrote: Marc Branchaud <marcn...@xiplink.com> writes: What if we detect when the full line exceeds the terminal width, and insert a newline after the remote ref and indent the -> to the same offset as its surrounding lines, like this: * [n

Re: [PATCH v2 3/3] fetch: reduce duplicate in ref update status lines

On 2016-06-03 07:08 AM, Nguyễn Thái Ngọc Duy wrote: When there are lots of ref updates, each has different name length, this will make it easier to look because the variable part is at the end. s/look/read/ For the record, I prefer the earlier stair-step format to this {xxx ->

Re: [PATCH v2 1/3] git-fetch.txt: document fetch output

On 2016-06-03 07:08 AM, Nguyễn Thái Ngọc Duy wrote: This documents the ref update status of fetch. The structure of this output is defined in [1]. The ouput content is refined a bit in [2] s/The ouput/The output/ [3] [4]. This patch is a copy from git-push.txt, modified a bit because the

Re: [PATCH] log: document the --decorate=auto option

On 2016-05-27 11:56 AM, Ramsay Jones wrote: Signed-off-by: Ramsay Jones --- Hi Junio, While reading an email from Linus earlier (RFC: dynamic "auto" date formats), I noticed that log.decorate was being set to 'auto'. Since I didn't recall that setting (even if

Re: [PATCH 1/2] fetch: better alignment in ref summary

On 2016-05-26 03:31 PM, Junio C Hamano wrote: Marc Branchaud <marcn...@xiplink.com> writes: The fact that something is buried in some odd part of the ref tree is less relevant, IMO. If I'm using custom fetch refspecs or other oddities, I'll have that in the back of my head. But what I

Re: [PATCH 1/2] fetch: better alignment in ref summary

On 2016-05-26 01:42 PM, Junio C Hamano wrote: True. One of the entries in Marc's example is easily misread as "pclouds/2nd-index branch at its refs/heads/pclouds/2nd-index was fetched to its usual place", when Marc wanted to say "they had 2nd-index branch at refs/heads/2nd-index, and it was

Re: [PATCH 1/2] fetch: better alignment in ref summary

On 2016-05-22 09:59 PM, Duy Nguyen wrote: On Mon, May 23, 2016 at 7:58 AM, Junio C Hamano wrote: That is, I wonder if the above can become something like: From github.com:pclouds/git * [new branch] { -> pclouds/}2nd-index * [new branch] { ->

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

On 2016-05-06 03:57 PM, Junio C Hamano wrote: Marc Branchaud <marcn...@xiplink.com> 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 readers that this "initialization" is not initializing but m

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

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 readers that this "initialization" is not initializing but merely squelching warnings from stupid compilers, and agree to use it consistently? Perhaps #define

Re: [PATCH] git-cvsserver: fix duplicate words

On 2016-05-06 08:09 AM, Li Peng wrote: Fix duplicate words in comments. Signed-off-by: Li Peng --- git-cvsserver.perl | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/git-cvsserver.perl b/git-cvsserver.perl index 02c0445..392e59e 100755 ---

Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*

On 2016-04-26 12:09 PM, Ævar Arnfjörð Bjarmason wrote: Basically you can look at patches to a project on a spectrum of: 1. You hacked something up locally 2. It's in someone's *.git repo as a POC 3. It's a third-party patch series used by a bunch of people 4. In an official release but

Re: RFC: Supporting .git/hooks/$NAME.d/* && /etc/git/hooks/$NAME.d/*

On 2016-04-26 06:58 AM, Ævar Arnfjörð Bjarmason wrote: > > Makes sense to have an experimental.* config tree for git for stuff like this. I disagree. * If the point is to express some kind of warning to users, I think the community has been much better served by leaving experimental settings

Re: Tabs in commit messages - de-tabify option in strbuf_stripspace()?

On 16-03-15 09:02 PM, Stefan Beller wrote: > On Tue, Mar 15, 2016 at 6:00 PM, Stefan Beller wrote: >> >> Instead of converting to whitespaces in Git, we could make use of the >> set_tabs capability for ttys and setup the terminal for having tabs align >> to 12,+8,+8,+8... > >

Re: [PATCH] strtoul_ui: reject negative values

On 15-09-17 11:34 AM, Matthieu Moy wrote: > Marc Branchaud <marcn...@xiplink.com> writes: > >>> --- a/git-compat-util.h >>> +++ b/git-compat-util.h >>> @@ -814,6 +814,9 @@ static inline int strtoul_ui(char const *s, int base, >>> unsigned int *

Re: [PATCH] strtoul_ui: reject negative values

On 15-09-17 10:37 AM, Matthieu Moy wrote: > strtoul_ui uses strtoul to get a long unsigned, then checks that casting > to unsigned does not lose information and return the casted value. > > On 64 bits architecture, checking that the cast does not change the value > catches most errors, but when

Re: proper remote ref namespaces

On 15-08-12 02:43 AM, Jacob Keller wrote: Hello, Recently there was some discussion about git-notes and how we do not fetch notes from remotes by default. The big problem with doing so is because refs/remotes/* hierarchy is only setup for branches (heads), so we don't have any clean

Re: A good time to pull from your gitk tree?

On 15-03-24 07:06 PM, Paul Mackerras wrote: On Mon, Mar 23, 2015 at 12:03:37PM -0700, Junio C Hamano wrote: Is it a good time for me to pull from you, or do you recommend me to wait for a bit, expecting more? We'll go in the pre-release freeze soon-ish, so I thought I should ping. Now is

[PATCH] gitk: Use translated version of Command line in getcommitlines.

Signed-off-by: Marc Branchaud marcn...@xiplink.com --- I noticed this today. I think this change is needed for getcommitlines to work properly with translated gitk's. M. gitk | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gitk b/gitk index 90419e3..fd5b50a

[PATCHv2] gitk: Show the current view's name in the window title.

If the current view is the Command line view, show the command line arguments instead of the view name. Signed-off-by: Marc Branchaud marcn...@xiplink.com --- This is v2 of my previous Show the command-line revs in the window title RFC patch. (I'm having trouble accessing gmane, or I'd include

Re: A good time to pull from your gitk tree?

On 15-03-24 07:06 PM, Paul Mackerras wrote: On Mon, Mar 23, 2015 at 12:03:37PM -0700, Junio C Hamano wrote: Is it a good time for me to pull from you, or do you recommend me to wait for a bit, expecting more? We'll go in the pre-release freeze soon-ish, so I thought I should ping. Now is

[PATCH 1/2] gitk: Rearrange window title to be more conventional.

Signed-off-by: Marc Branchaud marcn...@xiplink.com --- I did a bit of googling but couldn't find some standard that says the application name goes at the end of the title bar. But this is how all the browsers and other apps I use regularly do things. M. gitk | 2 +- 1 file

[PATCH 2/2] gitk: Show the rev(s) the user specified on the command line in the window title.

Signed-off-by: Marc Branchaud marcn...@xiplink.com --- I often open multiple gitk windows in the same working directory to examine other branches or refs in the repo. This change allows me to distinguish which window is showing what. M. gitk | 7 ++- 1 file changed, 6

Re: [PATCH 0/2] Tweaking the gitk window title.

On 15-01-06 12:51 PM, Marc Branchaud wrote: The first patch simply changes the title from gitk: dir to dir - gitk, which is the title layout used by most of the applications on my Kubuntu box. The second patch is the one that I'm more keen to see accepted. It relies on the first only

Re: [RFC/PATCH] branch: name detached HEAD analogous to status

On 15-02-22 02:21 PM, Junio C Hamano wrote: Michael J Gruber g...@drmicha.warpmail.net writes: git status carefully names a detached HEAD at resp. from a rev or ref depending on whether the detached HEAD has moved since. git branch always uses from, which can be confusing, because a

Re: [RFC/PATCH] branch: name detached HEAD analogous to status

On 15-02-22 12:38 PM, Michael J Gruber wrote: git status carefully names a detached HEAD at resp. from a rev or ref depending on whether the detached HEAD has moved since. git branch always uses from, which can be confusing, because a status-aware user would interpret this as moved detached

Re: [RFC/PATCH] branch: name detached HEAD analogous to status

On 15-02-23 11:24 AM, Michael J Gruber wrote: Marc Branchaud venit, vidit, dixit 23.02.2015 16:12: On 15-02-22 12:38 PM, Michael J Gruber wrote: git status carefully names a detached HEAD at resp. from a rev or ref depending on whether the detached HEAD has moved since. git branch always uses

Re: [PATCH 0/2] Tweaking the gitk window title.

On 15-01-06 12:51 PM, Marc Branchaud wrote: The first patch simply changes the title from gitk: dir to dir - gitk, which is the title layout used by most of the applications on my Kubuntu box. The second patch is the one that I'm more keen to see accepted. It relies on the first only

[PATCH 1/2] gitk: Rearrange window title to be more conventional.

Signed-off-by: Marc Branchaud marcn...@xiplink.com --- I did a bit of googling but couldn't find some standard that says the application name goes at the end of the title bar. But this is how all the browsers and other apps I use regularly do things. M. gitk | 2 +- 1 file

[RFC PATCH 2/2] gitk: Show the rev(s) the user specified on the command line in the window title.

Signed-off-by: Marc Branchaud marcn...@xiplink.com --- I often open multiple gitk windows in the same working directory to examine other branches or refs in the repo. This change allows me to distinguish which window is showing what. This is an RFC because it doesn't behave great with views. I

[PATCH 0/2] Tweaking the gitk window title.

The first patch simply changes the title from gitk: dir to dir - gitk, which is the title layout used by most of the applications on my Kubuntu box. The second patch is the one that I'm more keen to see accepted. It relies on the first only in that it follows the new title layout.

Re: Our cumbersome mailing list workflow

On 14-11-28 09:31 AM, Michael Haggerty wrote: On 11/27/2014 06:46 PM, Torsten Bögershausen wrote: On 2014-11-25 01.28, Michael Haggerty wrote: [] Let me list the aspects of our mailing list workflow that I find cumbersome as a contributor and reviewer: * Submitting patches to the mailing

[PATCH] RelNotes: Spelling grammar tweaks.

Signed-off-by: Marc Branchaud marcn...@xiplink.com --- Documentation/RelNotes/2.2.0.txt | 102 +++ 1 file changed, 51 insertions(+), 51 deletions(-) diff --git a/Documentation/RelNotes/2.2.0.txt b/Documentation/RelNotes/2.2.0.txt index d4001c5..9d9d5d5 100644

  1   2   3   >