Re: [PATCH] repository: pre-initialize hash algo pointer

On Thu, Jan 18, 2018 at 11:18 PM, brian m. carlson wrote: > There are various git subcommands (among them, clone) which don't set up > the repository (that is, they lack RUN_SETUP or RUN_SETUP_GENTLY) but > end up needing to have information about the hash algorithm

Re: git 2.16.0 segfaults on clone of specific repo

On Fri, Jan 19, 2018 at 12:31:58PM +0700, Duy Nguyen wrote: > On Fri, Jan 19, 2018 at 10:40 AM, brian m. carlson > > I'm still extremely puzzled as to why this doesn't fail on Linux. If > > it's failing in this case, it should very, very clearly fail all the > > time we access an empty blob or an

Re: git 2.16.0 segfaults on clone of specific repo

On Fri, Jan 19, 2018 at 10:40 AM, brian m. carlson wrote: > On Thu, Jan 18, 2018 at 10:06:10PM -0500, Eric Sunshine wrote: >> > I have a guess about what the problem might be. Can you try this patch >> > and see if it fixes things? >> >> That does fix the crash.

It's all about 14

Hello , facebook is given out 14,000,000.USD (Fourteen Million Dollars) its all about 14 Please, respond with your Unique Code (FB/BF14-13M5250UD) using your registration email, to the Verification Department at; dustinmoskovitz.faceb...@gmail.com Dustin Moskovitz Facebook Team Copyright

[PATCH] repository: pre-initialize hash algo pointer

There are various git subcommands (among them, clone) which don't set up the repository (that is, they lack RUN_SETUP or RUN_SETUP_GENTLY) but end up needing to have information about the hash algorithm in use. Because the hash algorithm is part of struct repository and it's only initialized in

Re: git 2.16.0 segfaults on clone of specific repo

On Thu, Jan 18, 2018 at 10:06:10PM -0500, Eric Sunshine wrote: > > I have a guess about what the problem might be. Can you try this patch > > and see if it fixes things? > > That does fix the crash. Thanks for the quick diagnosis. > > Can the commit message go into more detail as to why this

RE: git 2.16.0 segfaults on clone of specific repo

On January 18, 2018 10:06 PM, Eric Sunshine wrote: > On Thu, Jan 18, 2018 at 9:47 PM, brian m. carlson > wrote: > > On Thu, Jan 18, 2018 at 07:15:56PM -0500, Eric Sunshine wrote: > >> On Thu, Jan 18, 2018 at 3:55 PM, Александр Булаев > >>

Re: git 2.16.0 segfaults on clone of specific repo

On Thu, Jan 18, 2018 at 9:47 PM, brian m. carlson wrote: > On Thu, Jan 18, 2018 at 07:15:56PM -0500, Eric Sunshine wrote: >> On Thu, Jan 18, 2018 at 3:55 PM, Александр Булаев >> wrote: >> > I found that git 2.16.0 segfaults on clone of

Re: git 2.16.0 segfaults on clone of specific repo

On Thu, Jan 18, 2018 at 07:15:56PM -0500, Eric Sunshine wrote: > [+cc:brian] > > On Thu, Jan 18, 2018 at 3:55 PM, Александр Булаев > wrote: > > I found that git 2.16.0 segfaults on clone of vim-colorschemes repo. > > > > (lldb) run > > Process 25643 launched:

RE: [RFC PATCH] NonStop port changes for git 2.16.0.

On January 18, 2018 7:11 PM, Ævar Arnfjörð Bjarmason wrote: > On Thu, Jan 18 2018, Stefan Beller jotted: > > On Thu, Jan 18, 2018 at 2:42 PM, wrote: > >> Further: there are 6 known breakages that have been reported. The > >> perl issues relating to completion codes

Re: [PATCH 06/11] git fetch doc: add a new section to explain the ins & outs of pruning

On Thu, Jan 18, 2018 at 7:00 PM, Ævar Arnfjörð Bjarmason wrote: > Add a new section to canonically explain how remote reference pruning > works, and how users should be careful about using it in conjunction > with tag refspecs in particular. > > A subsequent commit will update

Re: [PATCH 3/3] read-cache: don't write index twice if we can't write shared index

On Fri, Jan 19, 2018 at 5:32 AM, SZEDER Gábor wrote: > On Thu, Jan 18, 2018 at 10:37 PM, Jeff King wrote: >> On Thu, Jan 18, 2018 at 10:00:14PM +0700, Duy Nguyen wrote: >> >>> The test suite was run as root, no wonder why my removing write access >>> has no

[PATCH v2 0/2] Cookie redaction during GIT_TRACE_CURL

Thanks, Eric. Changes in v2: - documented all environment variables introduced - made test more clear by ensuring that no cookie keys are suffixes or prefixes of others - tested empty value As far as I can tell, it does not seem possible that Git generates a cookie with no equals sign (like

[PATCH v2 2/2] http: support omitting data from traces

GIT_TRACE_CURL provides a way to debug what is being sent and received over HTTP, with automatic redaction of sensitive information. But it also logs data transmissions, which significantly increases the log file size, sometimes unnecessarily. Add an option "GIT_TRACE_CURL_NO_DATA" to allow the

[PATCH v2 1/2] http: support cookie redaction when tracing

When using GIT_TRACE_CURL, Git already redacts the "Authorization:" and "Proxy-Authorization:" HTTP headers. Extend this redaction to a user-specified list of cookies, specified through the "GIT_REDACT_COOKIES" environment variable. Signed-off-by: Jonathan Tan ---

Re: [PATCH v2] diff: add --compact-summary option to complement --stat

On Fri, Jan 19, 2018 at 5:48 AM, Jeff King wrote: > On Thu, Jan 18, 2018 at 05:05:46PM +0700, Nguyễn Thái Ngọc Duy wrote: > >> This is partly inspired by gerrit web interface which shows diffstat >> like this, e.g. with commit 0433d533f1 (notice the "A" column on the >> third

Re: git 2.16.0 segfaults on clone of specific repo

[+cc:brian] On Thu, Jan 18, 2018 at 3:55 PM, Александр Булаев wrote: > I found that git 2.16.0 segfaults on clone of vim-colorschemes repo. > > (lldb) run > Process 25643 launched: '/usr/local/bin/git' (x86_64) > Cloning into 'vim-colorschemes'... > remote: Counting

Re: [RFC PATCH] NonStop port changes for git 2.16.0.

On Thu, Jan 18 2018, Stefan Beller jotted: > On Thu, Jan 18, 2018 at 2:42 PM, wrote: >> Further: there are 6 known breakages that have been reported. The perl >> issues relating to completion codes are being examined at present by the >> platform support teams so

[ANNOUNCE] Git Merge Contributor's Summit Mar 7, 2018, Barcelona

Git Merge 2018 is happening on March 8th; there will be a Contributor's Summit the day before. Here are the details: When: Wednesday, March 7, 2018. 10am-5pm. Where: Convent Dels Àngels[1], Barcelona, Spain What: Round-table discussion about Git Who: All contributors to Git or related

Re: [PATCH v2] diff: add --compact-summary option to complement --stat

On Fri, Jan 19, 2018 at 4:23 AM, Ævar Arnfjörð Bjarmason wrote: > Wait, isn't there a bug here in the existing --summary code, its > documentation says it'll show information "such as creations, renames > and mode changes". > > But even though your --compact-summary shows that

[PATCH 02/11] fetch tests: arrange arguments for future readability

Re-arrange the arguments to the test_configured_prune() function used in this test to pass the arguments to --fetch last. A subsequent change will test for more elaborate fetch arguments, including long refspecs. It'll be more readable to be able to wrap those on a new line of their own.

[PATCH 06/11] git fetch doc: add a new section to explain the ins & outs of pruning

Add a new section to canonically explain how remote reference pruning works, and how users should be careful about using it in conjunction with tag refspecs in particular. A subsequent commit will update the git-remote documentation to refer to this section, and details the motivation for writing

[RFC/PATCH 11/11] WIP fetch: add a --fetch-prune option and fetch.pruneTags config

[WIP: This doesn't (yet) work as advertised, see further WIP note below] Add a --fetch-prune option to git-fetch along with fetch.pruneTags config option. This allows for doing: git fetch origin -p -P Or simply: git config fetch.prune true && git config fetch.pruneTags true &&

[PATCH 00/11] document & test fetch pruning + WIP fetch.pruneTags

Michael Giuffrida noted that the git-remote docs were very confusing, and upthread I said I wanted this shiny related thing in 11/11. Along the way I fixed up fetch tests & documentation to hopefully be a lot less confusing. I think 1-10/11 of this makes sense for inclusion as-is (pending review

[PATCH 01/11] fetch tests: refactor in preparation for testing tag pruning

In a subsequent commit this function will learn to test for tag pruning, prepare for that by making space for more variables, and making it clear that "expected" here refers to branches. Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t5510-fetch.sh | 9 ++--- 1 file changed,

[PATCH 08/11] git-fetch & config doc: link to the new PRUNING section

Amend the documentation for fetch.prune, fetch..prune and --prune to link to the recently added PRUNING section. I'd have liked to link directly to it with "<>" from fetch-options.txt, since it's included in git-fetch.txt (git-pull.txt also includes it, but doesn't include that option). However

Re: [PATCH v2] diff: add --compact-summary option to complement --stat

On Fri, Jan 19, 2018 at 1:57 AM, Eric Sunshine wrote: >> diff --git a/Documentation/diff-options.txt b/Documentation/diff-options.txt >> @@ -188,6 +188,17 @@ and accumulating child directory counts in the parent >> directories: >> +--compact-summary:: >> + Output a

[PATCH 07/11] git remote doc: correct dangerous lies about what prune does

The "git remote prune " command uses the same machinery as "git fetch --prune", and shares all the same caveats, but its documentation has suggested that it'll just "delete stale remote-tracking branches under ". This isn't true, and hasn't been true since at least v1.8.5.6 (the oldest version I

[PATCH 05/11] fetch tests: test --prune and refspec interaction

Add a test for the interaction between explicitly provided refspecs and fetch.prune. There's no point in adding this boilerplate to every combination of unset/false/true, it's instructive and sufficient to show that no matter if the variable is unset, false or true the refspec on the command-line

[PATCH 09/11] fetch: don't redundantly null something calloc() gave us

Stop redundantly NULL-ing the last element of the refs structure, which was retrieved via calloc() and is thus guaranteed to be pre-NULL'd. This code dates back to b888d61c83 ("Make fetch a builtin", 2007-09-10), where wasn't any reason to do this back then either, it's just something left over

[PATCH 04/11] fetch tests: double quote a variable for interpolation

If the $cmdline variable contains multiple arguments they won't be interpolated correctly since the body of the test is single quoted. I don't know what part of test-lib.sh is expanding variables within single-quoted strings, but interpolating this inline is the desired behavior here. This will

[PATCH 10/11] fetch tests: add scaffolding for the new fetch.pruneTags

The fetch.pruneTags configuration doesn't exist yet, but will be added in a subsequent commit. Since testing for it requires adding new parameters to the test_configured_prune function it's easier to review this patch first to assert that no functional changes are introduced yet. Signed-off-by:

[PATCH 03/11] fetch tests: add a tag to be deleted to the pruning tests

Add a tag to be deleted to the fetch --prune tests. The tag is always kept for now, which is the expected behavior, but now I can add a test for tag pruning in a later commit. Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t5510-fetch.sh | 93

Re: [PATCH] describe: use strbuf_add_unique_abbrev() for adding short hashes

> On 18 Jan 2018, at 23:40, SZEDER Gábor wrote: > > On Thu, Jan 18, 2018 at 10:40 PM, René Scharfe wrote: >> Am 16.01.2018 um 18:11 schrieb SZEDER Gábor: >>> Unfortunately, most of the changes coming from 'strbuf.cocci' don't >>> make any sense, they appear

Re: [RFC PATCH] NonStop port changes for git 2.16.0.

On Thu, Jan 18, 2018 at 2:42 PM, wrote: > From: "Randall S. Becker" > > Explanation: I'm looking for comments on how best to handle the changes > below that are needed for the NonStop port. Ideally you'd send them as single patches, each of

Re: [PATCH v2] diff: add --compact-summary option to complement --stat

On Thu, Jan 18, 2018 at 05:05:46PM +0700, Nguyễn Thái Ngọc Duy wrote: > This is partly inspired by gerrit web interface which shows diffstat > like this, e.g. with commit 0433d533f1 (notice the "A" column on the > third line): > > Documentation/merge-config.txt | 4 + >

[RFC PATCH] NonStop port changes for git 2.16.0.

From: "Randall S. Becker" Explanation: I'm looking for comments on how best to handle the changes below that are needed for the NonStop port. The hashmap.h and transport-helper.c will not be included in the final patch as they have already been communicated but did not

Re: [PATCH] describe: use strbuf_add_unique_abbrev() for adding short hashes

On Thu, Jan 18, 2018 at 10:40 PM, René Scharfe wrote: > Am 16.01.2018 um 18:11 schrieb SZEDER Gábor: >> Unfortunately, most of the changes coming from 'strbuf.cocci' don't >> make any sense, they appear to be the mis-application of the "use >> strbuf_addstr() instead of

RE: [Question] format-patch along a specific path

On January 18, 2018 2:17 PM, I wrote: > What I’m trying to do is to format a patch based on a single commit from > 2.16.0 representing the NonStop port, for review and comments to the team. > Here is a partial (somewhat familiar) tree: > > *   f1a482cd8 (HEAD -> randall_2.16, ituglib_release)

Re: [PATCH 3/3] read-cache: don't write index twice if we can't write shared index

On Thu, Jan 18, 2018 at 10:37 PM, Jeff King wrote: > On Thu, Jan 18, 2018 at 10:00:14PM +0700, Duy Nguyen wrote: > >> The test suite was run as root, no wonder why my removing write access >> has no effect. I got the test to pass with this, but then it fails >> with >> >> Can't

Re: What's cooking in git.git (Jan 2018, #02; Tue, 9)

On Thu, 18 Jan 2018 09:56:50 +0100 Christian Couder wrote: > I am still not very happy with fetch_object() not returning anything. > I wonder what happens when that function is used to fetch from a repo > that cannot provide the requested object. My idea was to save

[ANNOUNCE] Git for Windows 2.16.0(2)

Dear Git users, It is my pleasure to announce that Git for Windows 2.16.0(2) is available from: https://git-for-windows.github.io/ Changes since Git for Windows v2.15.1(2) (November 30th 2017) Git for Windows now has a new homepage: https://gitforwindows.org/ (it is still graciously

Re: [PATCH 10/8] [DO NOT APPLY, but improve?] rebase--interactive: introduce "stop" command

On Thu, Jan 18, 2018 at 2:08 PM, Philip Oakley wrote: > From: "Jacob Keller" >> >> On Thu, Jan 18, 2018 at 10:36 AM, Stefan Beller >> wrote: >>> >>> Jake suggested using "x false" instead of "edit" for some corner cases. >>> >>>

Re: [PATCH 10/8] [DO NOT APPLY, but improve?] rebase--interactive: introduce "stop" command

On Thu, Jan 18, 2018 at 2:00 PM, Johannes Schindelin wrote: >> + TODO_STOP, > > I see that your original idea was "stop", but then you probably realized > that there would be no good abbreviation for that, and changed your mind. > > Personally, I would have called

Re: [PATCH 10/8] [DO NOT APPLY, but improve?] rebase--interactive: introduce "stop" command

From: "Jacob Keller" On Thu, Jan 18, 2018 at 10:36 AM, Stefan Beller wrote: Jake suggested using "x false" instead of "edit" for some corner cases. I do prefer using "x false" for all kinds of things such as stopping before a commit (edit only

Re: [PATCH 8/8] rebase -i: introduce --recreate-merges=no-rebase-cousins

From: "Johannes Schindelin" This one is a bit tricky to explain, so let's try with a diagram: C / \ A - B - E - F \ / D To illustrate what this new mode is all about, let's consider what happens upon `git rebase -i --recreate-merges B`, in

Re: [PATCH 10/8] [DO NOT APPLY, but improve?] rebase--interactive: introduce "stop" command

Hi Stefan, On Thu, 18 Jan 2018, Stefan Beller wrote: > Jake suggested using "x false" instead of "edit" for some corner cases. > > I do prefer using "x false" for all kinds of things such as stopping > before a commit (edit only let's you stop after a commit), and the > knowledge that "x false"

Re: [PATCH 9/8] [DO NOT APPLY, but squash?] git-rebase--interactive: clarify arguments

On Thu, Jan 18, 2018 at 1:36 PM, Johannes Schindelin wrote: > Good idea! I would rather do it as an introductory patch (that only > converts the existing list). That makes sense. > > As to `merge`: it is a bit more complicated ;-) > > m, merge ( | "..." )

Re: [PATCH v3 0/3] fixes for split index mode

Friendly ping on this series now that 2.16 is out :) Is there anything in this series (up to 3/3, 4/3 can be dropped now that Duy fixed it in a nicer way) that still needs updating? It fixes a few bugs in split index mode with submodules/worktrees, so it would be nice to get this reviewed/merged.

Re: [PATCH] describe: use strbuf_add_unique_abbrev() for adding short hashes

Am 16.01.2018 um 18:11 schrieb SZEDER Gábor: > Unfortunately, most of the changes coming from 'strbuf.cocci' don't > make any sense, they appear to be the mis-application of the "use > strbuf_addstr() instead of strbuf_addf() to add a single string" rule: > >- strbuf_addf(_repo,

Re: [PATCH 4/8] rebase-helper --make-script: introduce a flag to recreate merges

From: "Johannes Schindelin" The sequencer just learned a new commands intended to recreate branch structure (similar in spirit to --preserve-merges, but with a substantially less-broken design). Let's allow the rebase--helper to generate todo lists making use of

Re: [PATCH 3/3] read-cache: don't write index twice if we can't write shared index

On Thu, Jan 18, 2018 at 10:00:14PM +0700, Duy Nguyen wrote: > The test suite was run as root, no wonder why my removing write access > has no effect. I got the test to pass with this, but then it fails > with > > Can't write .prove (Permission denied) at > /usr/share/perl/5.22/App/Prove.pm

Re: [PATCH 9/8] [DO NOT APPLY, but squash?] git-rebase--interactive: clarify arguments

Hi Stefan, On Thu, 18 Jan 2018, Stefan Beller wrote: > Up to now each command took a commit as its first argument and ignored > the rest of the line (usually the subject of the commit) > > Now that we have commands that take different arguments, clarify each > command by giving the argument

Re: [PATCH 6/8] sequencer: handle autosquash and post-rewrite for merge commands

>> Same for the test here, I can't figure out why this is necessary in >> this patch as opposed to the patch which first introduced the >> refs/rewritten/ refs. > > Woops. This was its own commit, and must have been accidentally squashed > during one of my rebases. Will re-introduce it; Yep that

Re: [PATCH 6/8] sequencer: handle autosquash and post-rewrite for merge commands

Hi Jake, On Thu, 18 Jan 2018, Jacob Keller wrote: > On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin > wrote: > > In the previous patches, we implemented the basic functionality of the > > `git rebase -i --recreate-merges` command, in particular the `merge` > >

Re: [PATCH 1/8] sequencer: introduce new commands to reset the revision

On Thu, Jan 18, 2018 at 1:24 PM, Philip Oakley wrote: > From: "Jacob Keller" > >> On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin >> wrote: >>> >>> This commit implements the commands to label, and to reset to, given

Re: [PATCH 2/8] sequencer: introduce the `merge` command

On Thu, Jan 18, 2018 at 1:22 PM, Johannes Schindelin wrote: >> Would it be possible to open the editor with the supplied text when >> there's no commit? The text after must be oneline only.. > > I actually want to avoid that because my main use case is

Re: [PATCH 1/8] sequencer: introduce new commands to reset the revision

From: "Jacob Keller" On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin wrote: This commit implements the commands to label, and to reset to, given revisions. The syntax is: label reset As a convenience shortcut, also

Re: [PATCH v2] diff: add --compact-summary option to complement --stat

On Thu, Jan 18 2018, Nguyễn Thái Ngọc Duy jotted: > This is partly inspired by gerrit web interface which shows diffstat > like this, e.g. with commit 0433d533f1 (notice the "A" column on the > third line): > > > Documentation/merge-config.txt | 4 + > builtin/merge.c

Re: [PATCH 2/8] sequencer: introduce the `merge` command

Hi Jake, On Thu, 18 Jan 2018, Jacob Keller wrote: > On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin > wrote: > > This patch is part of the effort to reimplement `--preserve-merges` with > > a substantially improved design, a design that has been developed in the

Re: [PATCH 1/8] sequencer: introduce new commands to reset the revision

On Thu, Jan 18, 2018 at 1:13 PM, Johannes Schindelin wrote: > Hi Jake, > > On Thu, 18 Jan 2018, Jacob Keller wrote: > >> On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin >> wrote: >> > This commit implements the commands to label, and

Re: [PATCH 10/8] [DO NOT APPLY, but improve?] rebase--interactive: introduce "stop" command

On Thu, Jan 18, 2018 at 10:36 AM, Stefan Beller wrote: > Jake suggested using "x false" instead of "edit" for some corner cases. > > I do prefer using "x false" for all kinds of things such as stopping > before a commit (edit only let's you stop after a commit), and the >

Re: [PATCH 9/8] [DO NOT APPLY, but squash?] git-rebase--interactive: clarify arguments

On Thu, Jan 18, 2018 at 10:36 AM, Stefan Beller wrote: > Up to now each command took a commit as its first argument and ignored > the rest of the line (usually the subject of the commit) > > Now that we have commands that take different arguments, clarify each > command by

Re: [PATCH 1/8] sequencer: introduce new commands to reset the revision

Hi Jake, On Thu, 18 Jan 2018, Jacob Keller wrote: > On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin > wrote: > > This commit implements the commands to label, and to reset to, given > > revisions. The syntax is: > > > > label > > reset > > > >

RE: git 2.16.0 segfaults on clone of specific repo

On January 18, 2018 3:56 PM, Aleks wrote: > I found that git 2.16.0 segfaults on clone of vim-colorschemes repo. Just tested on NonStop NSE and works fine here. Just an FYI now that we're on 2.16.0. Cheers, Randall -- Brief whoami: NonStop developer since approximately

git 2.16.0 segfaults on clone of specific repo

I found that git 2.16.0 segfaults on clone of vim-colorschemes repo. See the log below. alexbool@alexbool-osx ~/Documents> lldb -- git clone https://github.com/flazz/vim-colorschemes.git (lldb) target create "git" Current executable set to 'git' (x86_64). (lldb) settings set -- target.run-args

Re: Git For Aix 6 and 7

On 2018-01-18 09:47 AM, Ævar Arnfjörð Bjarmason wrote: > > On Thu, Jan 18 2018, raikrishna jotted: > >> Hi Team, >> >> I have an urgent requirement to install Git client for Aix 6 and 7, could >> you please help send me or navigate me to the correct url. >> My present infrastructure comprise of

[Question] format-patch along a specific path

Hi all, What I’m trying to do is to format a patch based on a single commit from 2.16.0 representing the NonStop port, for review and comments to the team. Here is a partial (somewhat familiar) tree: *   f1a482cd8 (HEAD -> randall_2.16, ituglib_release) NonStop port changes for git 2.16.0. |\ |

Re: [PATCH v2] diff: add --compact-summary option to complement --stat

On Thu, Jan 18, 2018 at 5:05 AM, Nguyễn Thái Ngọc Duy wrote: > [...] > The new option --compact-summary implements this with a tweak to support > mode change, which is shown in --summary too. > > For mode changes, executable bit is denoted as "M+x" or "M-x" when it's > added or

[PATCH 9/8] [DO NOT APPLY, but squash?] git-rebase--interactive: clarify arguments

Up to now each command took a commit as its first argument and ignored the rest of the line (usually the subject of the commit) Now that we have commands that take different arguments, clarify each command by giving the argument list. Signed-off-by: Stefan Beller ---

[PATCH 9, 10/8] interactive rebase feedback

I thought of writing a reply, but instead I wrote it in patch form. Stefan Beller (2): [DO NOT APPLY, but squash?] git-rebase--interactive: clarify arguments [DO NOT APPLY, but improve?] rebase--interactive: introduce "stop" command git-rebase--interactive.sh | 23

[PATCH 10/8] [DO NOT APPLY, but improve?] rebase--interactive: introduce "stop" command

Jake suggested using "x false" instead of "edit" for some corner cases. I do prefer using "x false" for all kinds of things such as stopping before a commit (edit only let's you stop after a commit), and the knowledge that "x false" does the least amount of actions behind my back. We should have

Re: [RFC PATCH 2/2] http: support omitting data from traces

On Wed, Jan 17, 2018 at 7:34 PM, Jonathan Tan wrote: > GIT_TRACE_CURL provides a way to debug what is being sent and received > over HTTP, with automatic redaction of sensitive information. But it > also logs data transmissions, which significantly increases the log file

Re: [RFC PATCH 1/2] http: support cookie redaction when tracing

On Wed, Jan 17, 2018 at 7:34 PM, Jonathan Tan wrote: > When using GIT_TRACE_CURL, Git already redacts the "Authorization:" and > "Proxy-Authorization:" HTTP headers. Extend this redaction to a > user-specified list of cookies, specified through the > "GIT_REDACT_COOKIES"

Re: [PATCH 00/11] Some fixes and bunch of object_id conversions

On Thu, 18 Jan 2018 15:50:52 +0100 Patryk Obara wrote: > Patch 1 is not directly related to object_id conversions but helped with > debugging t5540, which kept failing on master for me (spoiler: it was Fedora > fault). It helps with debugging of failing git-push over

Re: [PATCH 0/8] rebase -i: offer to recreate merge commits

On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin wrote: > Once upon a time, I dreamt of an interactive rebase that would not > flatten branch structure, but instead recreate the commit topology > faithfully. > > My original attempt was --preserve-merges, but that

Re: [PATCH 6/8] sequencer: handle autosquash and post-rewrite for merge commands

On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin wrote: > In the previous patches, we implemented the basic functionality of the > `git rebase -i --recreate-merges` command, in particular the `merge` > command to create merge commits in the sequencer. > > The

Re: [PATCH 2/8] sequencer: introduce the `merge` command

On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin wrote: > This patch is part of the effort to reimplement `--preserve-merges` with > a substantially improved design, a design that has been developed in the > Git for Windows project to maintain the dozens of

Re: [PATCH] enable core.fsyncObjectFiles by default

[adding Chris to the Cc list - this is about the awful ext3 data=ordered behavior of syncing the whole file system data and metadata on each fsync] On Wed, Jan 17, 2018 at 03:57:53PM -0800, Linus Torvalds wrote: > On Wed, Jan 17, 2018 at 3:52 PM, Theodore Ts'o wrote: > > > > Well,

Re: [PATCH 1/8] sequencer: introduce new commands to reset the revision

On Thu, Jan 18, 2018 at 7:35 AM, Johannes Schindelin wrote: > This commit implements the commands to label, and to reset to, given > revisions. The syntax is: > > label > reset > > As a convenience shortcut, also to improve readability of the

Re: Bug Report: Subtrees and GPG Signed Commits

Hi, just following up on this bug report. I have not heard back. Is there additional information that's needed? Is there a better place to file bug reports? Thanks On Sat, Jan 6, 2018 at 5:45 PM, Stephen R Guglielmo wrote: > Hi all, > > I've noticed an issue regarding the

[PATCH 8/8] rebase -i: introduce --recreate-merges=no-rebase-cousins

This one is a bit tricky to explain, so let's try with a diagram: C / \ A - B - E - F \ / D To illustrate what this new mode is all about, let's consider what happens upon `git rebase -i --recreate-merges B`, in particular to the commit `D`. In the default mode, the new

[PATCH 6/8] sequencer: handle autosquash and post-rewrite for merge commands

In the previous patches, we implemented the basic functionality of the `git rebase -i --recreate-merges` command, in particular the `merge` command to create merge commits in the sequencer. The interactive rebase is a lot more these days, though, than a simple cherry-pick in a loop. For example,

[PATCH 5/8] rebase: introduce the --recreate-merges option

Once upon a time, this here developer thought: wouldn't it be nice if, say, Git for Windows' patches on top of core Git could be represented as a thicket of branches, and be rebased on top of core Git in order to maintain a cherry-pick'able set of patch series? The original attempt at an answer

[PATCH 3/8] sequencer: fast-forward merge commits, if possible

Just like with regular `pick` commands, if we are trying to recreate a merge commit, we now test whether the parents of said commit match HEAD and the commits to be merged, and fast-forward if possible. This is not only faster, but also avoids unnecessary proliferation of new objects.

[PATCH 4/8] rebase-helper --make-script: introduce a flag to recreate merges

The sequencer just learned a new commands intended to recreate branch structure (similar in spirit to --preserve-merges, but with a substantially less-broken design). Let's allow the rebase--helper to generate todo lists making use of these commands, triggered by the new --recreate-merges option.

[PATCH 1/8] sequencer: introduce new commands to reset the revision

In the upcoming commits, we will teach the sequencer to recreate merges. This will be done in a very different way from the unfortunate design of `git rebase --preserve-merges` (which does not allow for reordering commits, or changing the branch topology). The main idea is to introduce new todo

[PATCH 2/8] sequencer: introduce the `merge` command

This patch is part of the effort to reimplement `--preserve-merges` with a substantially improved design, a design that has been developed in the Git for Windows project to maintain the dozens of Windows-specific patch series on top of upstream Git. The previous patch implemented the `label`,

[PATCH 0/8] rebase -i: offer to recreate merge commits

Once upon a time, I dreamt of an interactive rebase that would not flatten branch structure, but instead recreate the commit topology faithfully. My original attempt was --preserve-merges, but that design was so limited that I did not even enable it in interactive mode. Subsequently, it *was*

Re: [PATCH 3/3] read-cache: don't write index twice if we can't write shared index

On Thu, Jan 18, 2018 at 08:36:32PM +0700, Duy Nguyen wrote: > On Thu, Jan 18, 2018 at 8:29 PM, Jeff King wrote: > > On Thu, Jan 18, 2018 at 07:47:50PM +0700, Duy Nguyen wrote: > > > >> I may need help getting that log (or even better the trash directory > >> of t1700). I tried -m32

[PATCH 03/11] sha1_file: convert pretend_sha1_file to object_id

Convert the declaration and definition of pretend_sha1_file to use struct object_id and adjust all usages of this function. Signed-off-by: Patryk Obara --- blame.c | 2 +- cache.h | 3 ++- sha1_file.c | 8 3 files changed, 7 insertions(+), 6 deletions(-)

[PATCH 05/11] sha1_file: convert hash_sha1_file to object_id

Convert the declaration and definition of hash_sha1_file to use struct object_id and adjust all function calls. Signed-off-by: Patryk Obara --- apply.c | 4 ++-- builtin/index-pack.c | 3 +-- builtin/replace.c| 2 +-

[PATCH 08/11] commit: convert commit_tree* to object_id

Convert the definitions and declarations of commit_tree and commit_tree_extended to use struct object_id and adjust all usages of these functions. Signed-off-by: Patryk Obara --- builtin/am.c | 4 ++-- builtin/commit-tree.c | 4 ++-- builtin/commit.c | 5

[PATCH 00/11] Some fixes and bunch of object_id conversions

This patch series puts some mundane groundwork for experimentation with a new hashing algorithm in git-hash-object. Some time has passed since my last patches, and I see, that work on new hashing algorithm progressed nicely since then: * brian m. carlson implemented vtable for hash algorithm

[PATCH 10/11] notes: convert write_notes_tree to object_id

Convert the definition and declaration of write_notes_tree to struct object_id and adjust usage of this function. Additionally, improve style of small part of this function, as old formatting made it hard to understand at glance what this part of code is doing. Signed-off-by: Patryk Obara

[PATCH 09/11] notes: convert combine_notes_* to object_id

Convert the definition and declarations of combine_notes_* functions to struct object_id and adjust usage of these functions. Signed-off-by: Patryk Obara --- notes.c | 46 +++--- notes.h | 25 +++-- 2 files

[PATCH 02/11] clang-format: adjust penalty for return type line break

The penalty of 5 makes clang-format very eager to put even short type declarations (e.g. "extern int") into a separate line, even when breaking parameters list is sufficient. Signed-off-by: Patryk Obara --- .clang-format | 2 +- 1 file changed, 1 insertion(+), 1

[PATCH 11/11] sha1_file: convert write_sha1_file to object_id

Convert the definition and declaration of write_sha1_file to struct object_id and adjust usage of this function. This commit also converts static function write_sha1_file_prepare, as it is closely related. Replace sha1_to_hex, hashcpy and hashclr with their oid equivalents wherever possible.

[PATCH 01/11] http-push: improve error log

When git push fails due to server-side WebDAV error, it's not easy to point to the main culprit. Additional information about exact cURL error and HTTP server response is helpful for debugging purpose. New error log helped me pinpoint failing test t5540-http-push-webdav to a missing Apache

[PATCH 04/11] dir: convert struct sha1_stat to use object_id

Convert the declaration of struct sha1_stat. Adjust all usages of this struct and replace hash{clr,cmp,cpy} with oid{clr,cmp,cpy} wherever possible. Remove macro EMPTY_BLOB_SHA1_BIN, as it's no longer used. Signed-off-by: Patryk Obara --- cache.h

  1   2   >