Re: Creating sparse checkout in a new linked git worktree

> On Wed, Jan 24, 2018 at 11:11 AM, Jessie Hernandez > wrote: >> I am trying to get a sparse checkout in a linked worktree but cannot get >> it working. I have tried the following >> * git worktree add /some/new/path/new-branch --no-checkout >> * git config

Re: [PATCH/RFC v5 7/7] Careful with CRLF when using e.g. UTF-16 for working-tree-encoding

> On 30 Jan 2018, at 15:40, Torsten Bögershausen wrote: > > On Tue, Jan 30, 2018 at 12:23:47PM +0100, Lars Schneider wrote: >> >>> On 29 Jan 2018, at 21:19, tbo...@web.de wrote: >>> >>> From: Torsten Bögershausen >>> >>> UTF-16 encoded files are treated as

Re: Location limits on development, staging and production environments

On 01/29/2018 10:02 PM, Bryan Turner wrote: > On Mon, Jan 29, 2018 at 11:08 AM, H wrote: >> I am a newcomer to git looking to set up a web development environment where >> individual computers are used for development, the development.git, >> staging.git and

2.15.1 - merge with submodule output issue

Dear git, I use since few weeks now git 2.15.1. I did few trials but please find here my outputs. To reproduce: Use a top module git which include a submodule First step: from a work area, I changed selected version of submodule in master branch. Then git add + git commit + git push  A

Re: [PATCH/RFC v5 7/7] Careful with CRLF when using e.g. UTF-16 for working-tree-encoding

On Tue, Jan 30, 2018 at 12:23:47PM +0100, Lars Schneider wrote: > > > On 29 Jan 2018, at 21:19, tbo...@web.de wrote: > > > > From: Torsten Bögershausen > > > > UTF-16 encoded files are treated as "binary" by Git, and no CRLF > > conversion is done. > > When the UTF-16 encoded

Re: [PATCH v2 1/1] setup: recognise extensions.objectFormat

On 30/01/2018 02:38, Jeff King wrote: On Sun, Jan 28, 2018 at 01:36:17AM +0100, Patryk Obara wrote: This extension selects which hashing algorithm from vtable should be used for reading and writing objects in the object store. At the moment supports only single value (sha-1). In case value

Re: Shawn Pearce has died

On Mon, Jan 29, 2018 at 11:15:55PM -0800, Chris DiBona wrote: > That's a fantastic idea. When is the contrib summit and is it open to > others? I could send someone ... It's March 7th in Barcelona. Details are here: https://public-inbox.org/git/20180119001034.ga29...@sigill.intra.peff.net/

Re: [PATCH v2 1/1] setup: recognise extensions.objectFormat

On Tue, Jan 30, 2018 at 05:30:04PM +0100, Patryk Obara wrote: > > I don't have a strong opinion on this, but it does feel a little funny > > to add this extension now, before we quite know what the code that uses > > it is going to look like (or maybe we're farther along there than I > >

Re: Feature request: Improve diff algorithm

On Sat, Jan 27, 2018 at 5:08 AM, KES wrote: > One yet more: > > @@ -43,22 +44,25 @@ sub tariff_title { > 1; > > __DATA__ > -@@ control/tariff.css > -* { > -margin: 0; > -padding: 0; > -border: 0; > --webkit-box-sizing: border-box; > -box-sizing:

Re: Shawn Pearce has died

On Mon, Jan 29, 2018 at 2:55 PM, Christian Couder wrote: > On Mon, Jan 29, 2018 at 6:21 PM, Jeff King wrote: >> On Mon, Jan 29, 2018 at 10:33:08AM +0100, Johannes Schindelin wrote: >> >>> I found these sad news in my timeline today: >>> >>>

Re: [PATCH v2 00/10] rebase -i: offer to recreate merge commits

On Mon, Jan 29, 2018 at 2:54 PM, 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: Creating sparse checkout in a new linked git worktree

On Tue, Jan 30, 2018 at 9:25 AM, Jessie Hernandez wrote: >> The sparse-checkout file is specific to each worktree, which allows you > to control "sparsity" on a worktree by worktree basis. Therefore, you > should create $GIT_DIR/worktrees//info/sparse-checkout instead >

Re: [PATCH 0/2] Add "git rebase --show-patch"

Hi Duy, On Tue, 30 Jan 2018, Duy Nguyen wrote: > On Mon, Jan 29, 2018 at 10:09 PM, Johannes Schindelin > wrote: > > Hi Duy, > > > > On Fri, 26 Jan 2018, Nguyễn Thái Ngọc Duy wrote: > > > >> When a conflict happens during a rebase, you often need to look at the > >>

Re: [PATCH 00/37] removal of some c++ keywords

On Wed, Jan 31, 2018 at 6:01 AM, Stefan Beller wrote: > On Tue, Jan 30, 2018 at 2:36 PM, Junio C Hamano wrote: >> Duy Nguyen writes: >> >>> Is it simpler (though hacky) to just do >>> >>> #ifdef __cplusplus >>> #define new not_new >>>

Re: [PATCH 00/37] removal of some c++ keywords

On Tue, Jan 30, 2018 at 4:48 PM, Duy Nguyen wrote: > On Wed, Jan 31, 2018 at 6:01 AM, Stefan Beller wrote: >> On Tue, Jan 30, 2018 at 2:36 PM, Junio C Hamano wrote: >>> Duy Nguyen writes: >>> Is it simpler

Re: [RFC PATCH 0/2] alternate hash test

On Sun, Jan 28, 2018 at 9:06 AM, brian m. carlson wrote: > This series wires up an alternate hash implementation, namely > BLAKE2b-160. The goal is to allow us to identify tests which rely on > the hash algorithm in use so that we can fix those tests. > > For this

Re: [PATCH 00/37] removal of some c++ keywords

On Wed, Jan 31, 2018 at 7:57 AM, Stefan Beller wrote: >> There's also C99 designator in builtin/clean.c (I thought we avoided >> C99, I can start using this specific feature more now :D) > > That was a test balloon? See 512f41cfac > (clean.c: use designated initializer,

[ANNOUNCE] tig-2.3.3

Hello, A regression in 2.3.1 (and 2.3.2) related with the detection of busy loops has been revisited in version 2.3.3. Release notes - Bug fixes: - Revert "Handle \n like \r (#758)". (GH #769) - Fix GH #164 by catching SIGHUP. - Change `refs_tags` type to `size_t`. Change

Re: [PATCH v2 02/14] graph: add commit graph design document

On Tue, Jan 30, 2018 at 1:39 PM, Derrick Stolee wrote: > Add Documentation/technical/commit-graph.txt with details of the planned > commit graph feature, including future plans. > > Signed-off-by: Derrick Stolee > --- >

Re: [PATCH v2 06/14] commit-graph: implement git-commit-graph --read

> +static void free_commit_graph(struct commit_graph **g) > +{ > + if (!g || !*g) > + return; > + > + close_commit_graph(*g); > + > + free(*g); > + *g = NULL; nit: You may want to use FREE_AND_NULL(*g) instead.

Re: [PATCH 00/37] removal of some c++ keywords

Am 29.01.2018 um 23:36 schrieb Brandon Williams: A while back there was some discussion of getting our codebase into a state where we could use a c++ compiler if we wanted to (for various reason like leveraging c++ only analysis tools, etc.). Johannes Sixt had a very large patch that achieved

Re: [PATCH v2 1/1] setup: recognise extensions.objectFormat

Jeff King writes: > Putting code in master is OK; we can always refactor it. But once we > add and document a user-facing config option like this, we have to > support it forever. So that's really the step I was wondering about: are > we sure this is what the user-facing config is

Re: [PATCH] doc: mention 'git show' defaults to HEAD

Todd Zullinger writes: > When 'git show' is called without any object it defaults to HEAD. This > has been true since d4ed9793fd ("Simplify common default options setup > for built-in log family.", 2006-04-16). > > The SYNOPSIS suggests that the object argument is required.

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? Additionally, I have confirmed that this bug still exists with git version 2.16.1. Thanks On Thu, Jan 18, 2018 at 11:19 AM, Stephen R

Re: [PATCH v5 4/7] utf8: add function to detect a missing UTF-16/32 BOM

tbo...@web.de writes: > From: Lars Schneider > > If the endianness is not defined in the encoding name, then let's > be strict and require a BOM to avoid any encoding confusion. The > has_missing_utf_bom() function returns true if a required BOM is > missing. > > The

Re: [PATCH 0/2] Add "git rebase --show-patch"

Johannes Schindelin writes: > The pseudo ref certainly has an appeal. For people very familiar with > Git's peculiarities such as FETCH_HEAD. Such as myself. > > For users, it is probably substantially worse an experience than having a > cmdmode like --show-patch in

Re: [PATCH v1 0/5] Incremental rewrite of git-submodules: git-foreach

On Mon, Jan 29, 2018 at 11:34 AM, Prathamesh Chavan wrote: > Following series of patches focuses on porting submodule subcommand > git-foreach from shell to C. > An initial attempt for porting was introduced about 9 months back, > and since then then patches have undergone many

Re: git send-email sets date

Michal Suchánek writes: > git send-email sets the message date to author date. > > This is wrong because the message will most likely not get delivered > when the author date differs from current time. It might give slightly > better results with commit date instead of author

Re: [PATCH v5 5/7] convert: add 'working-tree-encoding' attribute

> On 30 Jan 2018, at 21:05, Junio C Hamano wrote: > > tbo...@web.de writes: > >> +if ((conv_flags & CONV_WRITE_OBJECT) && !strcmp(enc->name, >> "SHIFT-JIS")) { >> +char *re_src; >> +int re_src_len; > > I think it is a bad idea to > > (1) not

Re: git stash ; git stash pop unstages all staged changes

Hi Marten, On 30/01/2018 11:05, Martin Häcker wrote: > > I just lost quite some work, because `git stash; git stash pop` > doesn’t seem to understand the concept of the index correctly. I`m afraid it actually seems you`re not fully understanding how `git stash pop` works - but the good news

Re: [PATCH RFC 01/24] ref-filter: get rid of goto

Оля Тележная writes: >> one place improves readability. If better readability is the >> purpose, I would even say >> >> for (i = 0; i < used_atom_cnt; i++) { >> if (...) >> - goto need_obj; >> +

Re: [PATCH] git-svn: control destruction order to avoid segfault

Eric Wong writes: > Todd Zullinger wrote: >> I'm running the tests with and without your patch as well. >> So far I've run t9128 300 times with the patch and no >> failures. Without it, it's failed 3 times in only a few >> dozen runs. That's promising. > >

Re: [PATCH v2 02/10] sequencer: introduce new commands to reset the revision

On Mon, Jan 29, 2018 at 2:54 PM, Johannes Schindelin wrote: > 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

Re: git send-email sets date

Theodore Ts'o writes: > If there is a From: header in the beginning of the mail body, it is > used as the Author instead of the From: header in the mail header. It > would make sense if there is a Date: header in the beginning of the > mail body, it should be used instead of

Re: [PATCH v5 5/7] convert: add 'working-tree-encoding' attribute

tbo...@web.de writes: > + if ((conv_flags & CONV_WRITE_OBJECT) && !strcmp(enc->name, > "SHIFT-JIS")) { > + char *re_src; > + int re_src_len; I think it is a bad idea to (1) not check without CONV_WRITE_OBJECT here. (2) hardcode SJIS and do this always and to SJIS

git add --all does not respect submodule..ignore

Giving a submodule "ignore=all" or "ignore=dirty" in .gitmodule successfully removes that module from `git status` queries. However, these same diffs are automatically added by git-add, eg `git add .` or `git add --all` adds the submodules that we want ignored. This seems inconsistent and

Re: [PATCH v5 4/7] utf8: add function to detect a missing UTF-16/32 BOM

> On 30 Jan 2018, at 20:15, Junio C Hamano wrote: > > tbo...@web.de writes: > >> From: Lars Schneider >> >> If the endianness is not defined in the encoding name, then let's >> be strict and require a BOM to avoid any encoding confusion. The >>

Re: [RFC PATCH 0/2] alternate hash test

"brian m. carlson" writes: > This series wires up an alternate hash implementation, namely > BLAKE2b-160. The goal is to allow us to identify tests which rely on > the hash algorithm in use so that we can fix those tests. Yay. > Provoking discussion of which hash

[PATCH v5 05/10] wildmatch test: remove dead fnmatch() test code

Remove the unused fnmatch() test parameter from the wildmatch test. The code that used to test this was removed in 70a8fc999d ("stop using fnmatch (either native or compat)", 2014-02-15). As a --word-diff shows the only change to the body of the tests is the removal of the second out of four

[PATCH v5 01/10] wildmatch test: indent with tabs, not spaces

Replace the 4-width mixed space & tab indentation in this file with indentation with tabs as we do in most of the rest of our tests. Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t3070-wildmatch.sh | 54 ++-- 1 file changed, 27

[PATCH v5 03/10] wildmatch test: don't try to vertically align our output

Don't try to vertically align the test output, which is futile anyway under the TAP output where we're going to be emitting a number for each test without aligning the test count. This makes subsequent changes of mine where I'm not going to be aligning this output as I add new tests easier.

[PATCH v5 00/10] increase wildmatch test coverage

v5 has been a long time coming (20 days since I said I'd re-roll this), but hopefully this is a version that works well for everyone, including Windows users. Changes: Ævar Arnfjörð Bjarmason (10): wildmatch test: indent with tabs, not spaces wildmatch test: use more standard shell style

Re: [PATCH 0/2] Add "git rebase --show-patch"

On Mon, Jan 29, 2018 at 10:09 PM, Johannes Schindelin wrote: > Hi Duy, > > On Fri, 26 Jan 2018, Nguyễn Thái Ngọc Duy wrote: > >> When a conflict happens during a rebase, you often need to look at the >> original patch to see what the changes are. This requires opening

[PATCH v5 07/10] wildmatch test: perform all tests under all wildmatch() modes

Rewrite the wildmatch() test suite so that each test now tests all combinations of the wildmatch() WM_CASEFOLD and WM_PATHNAME flags. Before this change some test inputs were not tested on e.g. WM_PATHNAME. Now the function is stress tested on all possible inputs, and for each input we declare

[PATCH v2 01/14] commit-graph: add format document

Add document specifying the binary format for commit graphs. This format allows for: * New versions. * New hash functions and hash lengths. * Optional extensions. Basic header information is followed by a binary table of contents into "chunks" that include: * An ordered list of commit object

[PATCH v2 11/14] commit: integrate commit graph with commit parsing

Teach Git to inspect a commit graph file to supply the contents of a struct commit when calling parse_commit_gently(). This implementation satisfies all post-conditions on the struct commit, including loading parents, the root tree, and the commit date. The only loosely-expected condition is that

[PATCH v2 06/14] commit-graph: implement git-commit-graph --read

Teach git-commit-graph to read commit graph files and summarize their contents. Use the --read option to verify the contents of a commit graph file in the tests. Signed-off-by: Derrick Stolee --- Documentation/git-commit-graph.txt | 7 ++ builtin/commit-graph.c

[PATCH v2 08/14] commit-graph: implement git-commit-graph --clear

Teach Git to delete the current 'graph_head' file and the commit graph it references. This is a good safety valve if somehow the file is corrupted and needs to be recalculated. Since the commit graph is a summary of contents already in the ODB, it can be regenerated. Signed-off-by: Derrick Stolee

[PATCH v2 03/14] commit-graph: create git-commit-graph builtin

Teach git the 'commit-graph' builtin that will be used for writing and reading packed graph files. The current implementation is mostly empty, except for a '--pack-dir' option. Signed-off-by: Derrick Stolee --- .gitignore | 1 +

[PATCH v2 00/14] Serialized Git Commit Graph

Thanks to everyone who gave comments on v1. I tried my best to respond to all of the feedback, but may have missed some while I was doing several renames, including: * builtin/graph.c -> builtin/commit-graph.c * packed-graph.[c|h] -> commit-graph.[c|h] * t/t5319-graph.sh ->

Re: [PATCH v5 5/7] convert: add 'working-tree-encoding' attribute

Lars Schneider writes: >> On 30 Jan 2018, at 21:05, Junio C Hamano wrote: >> >> tbo...@web.de writes: >> >>> + if ((conv_flags & CONV_WRITE_OBJECT) && !strcmp(enc->name, >>> "SHIFT-JIS")) { >>> + char *re_src; >>> + int

Re: [PATCH 00/37] removal of some c++ keywords

Duy Nguyen writes: > Is it simpler (though hacky) to just do > > #ifdef __cplusplus > #define new not_new > #define try really_try > ... > > somewhere in git-compat-util.h? Very tempting, especially given that your approach automatically would cover topics in flight without

Re: Some rough edges of core.fsmonitor

On 1/27/2018 2:01 PM, Ævar Arnfjörð Bjarmason wrote: On Sat, Jan 27 2018, Duy Nguyen jotted: On Sat, Jan 27, 2018 at 07:39:27PM +0700, Duy Nguyen wrote: On Sat, Jan 27, 2018 at 6:43 PM, Ævar Arnfjörð Bjarmason wrote: a) no fsmonitor $ time GIT_TRACE_PERFORMANCE=1

Re: [PATCH 00/37] removal of some c++ keywords

On Tue, Jan 30, 2018 at 2:36 PM, Junio C Hamano wrote: > Duy Nguyen writes: > >> Is it simpler (though hacky) to just do >> >> #ifdef __cplusplus >> #define new not_new >> #define try really_try >> ... >> >> somewhere in git-compat-util.h? > > Very

Re: Bug Report: Subtrees and GPG Signed Commits

On Tue, Jan 30, 2018 at 6:24 PM, Junio C Hamano wrote: > Stefan Beller writes: >> There has not been feedback for a while on this thread. >> I think that is because subtrees are not in anyone's hot >> interest area currently. >> >> This is definitely the

[PATCH v7 16/31] merge-recursive: split out code for determining diff_filepairs

Create a new function, get_diffpairs() to compute the diff_filepairs between two trees. While these are currently only used in get_renames(), I want them to be available to some new functions. No actual logic changes yet. Signed-off-by: Elijah Newren --- merge-recursive.c |

[PATCH v7 11/31] directory rename detection: tests for handling overwriting dirty files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 458 1 file changed, 458 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index aa9af49edc..fbac664408 100755 ---

[PATCH v7 25/31] merge-recursive: apply necessary modifications for directory renames

This commit hooks together all the directory rename logic by making the necessary changes to the rename struct, it's dst_entry, and the diff_filepair under consideration. Signed-off-by: Elijah Newren --- merge-recursive.c | 187

[PATCH v7 22/31] merge-recursive: add computation of collisions due to dir rename & merging

directory renaming and merging can cause one or more files to be moved to where an existing file is, or to cause several files to all be moved to the same (otherwise vacant) location. Add checking and reporting for such cases, falling back to no-directory-rename handling for such paths.

[PATCH v7 30/31] merge-recursive: avoid spurious rename/rename conflict from dir renames

If a file on one side of history was renamed, and merely modified on the other side, then applying a directory rename to the modified side gives us a rename/rename(1to2) conflict. We should only apply directory renames to pairs representing either adds or renames. Making this change means that a

[PATCH v7 31/31] merge-recursive: ensure we write updates for directory-renamed file

When a file is present in HEAD before the merge and the other side of the merge does not modify that file, we try to avoid re-writing the file and making it stat-dirty. However, when a file is present in HEAD before the merge and was in a directory that was renamed by the other side of the merge,

[PATCH v7 10/31] directory rename detection: tests for handling overwriting untracked files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 367 1 file changed, 367 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index b730256653..aa9af49edc 100755 ---

[PATCH v7 28/31] merge-recursive: fix remaining directory rename + dirty overwrite cases

Signed-off-by: Elijah Newren --- merge-recursive.c | 26 +++--- t/t6043-merge-rename-directories.sh | 8 2 files changed, 27 insertions(+), 7 deletions(-) diff --git a/merge-recursive.c b/merge-recursive.c index

[PATCH v7 06/31] directory rename detection: testcases checking which side did the rename

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 336 1 file changed, 336 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index ac9c3e9974..fbeb8f4316 100755 ---

[PATCH v7 05/31] directory rename detection: files/directories in the way of some renames

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 330 1 file changed, 330 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index f0213f2bbd..ac9c3e9974 100755 ---

[PATCH v7 20/31] merge-recursive: check for directory level conflicts

Before trying to apply directory renames to paths within the given directories, we want to make sure that there aren't conflicts at the directory level. There will be additional checks at the individual file level too, which will be added later. Signed-off-by: Elijah Newren

[PATCH v7 23/31] merge-recursive: check for file level conflicts then get new name

Before trying to apply directory renames to paths within the given directories, we want to make sure that there aren't conflicts at the file level either. If there aren't any, then get the new name from any directory renames. Signed-off-by: Elijah Newren --- merge-recursive.c

[PATCH v7 24/31] merge-recursive: when comparing files, don't include trees

get_renames() would look up stage data that already existed (populated in get_unmerged(), taken from whatever unpack_trees() created), and if it didn't exist, would call insert_stage_data() to create the necessary entry for the given file. The insert_stage_data() fallback becomes much more

[PATCH v7 15/31] merge-recursive: make !o->detect_rename codepath more obvious

Previously, if !o->detect_rename then get_renames() would return an empty string_list, and then process_renames() would have nothing to iterate over. It seems more straightforward to simply avoid calling either function in that case. Signed-off-by: Elijah Newren ---

[PATCH v7 14/31] merge-recursive: fix leaks of allocated renames and diff_filepairs

get_renames() has always zero'ed out diff_queued_diff.nr while only manually free'ing diff_filepairs that did not correspond to renames. Further, it allocated struct renames that were tucked away in the return string_list. Make sure all of these are deallocated when we are done with them.

[PATCH v5 04/10] wildmatch test: use a paranoia pattern from nul_match()

Use a pattern from the nul_match() function in t7008-grep-binary.sh to make sure that we don't just fall through to the "else" if there's an unknown parameter. This is something I added in commit 77f6f4406f ("grep: add a test helper function for less verbose -f \0 tests", 2017-05-20) to grep

[PATCH v5 02/10] wildmatch test: use more standard shell style

Change the wildmatch test to use more standard shell style, usually we use "if test" not "if [". Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t3070-wildmatch.sh | 9 ++--- 1 file changed, 6 insertions(+), 3 deletions(-) diff --git a/t/t3070-wildmatch.sh

[PATCH v5 06/10] wildmatch test: use test_must_fail, not ! for test-wildmatch

Use of ! should be reserved for non-git programs that are assumed not to fail, see README. With this change only t/t0110-urlmatch-normalization.sh is still using this anti-pattern. Signed-off-by: Ævar Arnfjörð Bjarmason --- t/t3070-wildmatch.sh | 6 +++--- 1 file changed, 3

[PATCH v2 10/14] commit-graph: add core.commitgraph setting

The commit graph feature is controlled by the new core.commitgraph config setting. This defaults to 0, so the feature is opt-in. The intention of core.commitgraph is that a user can always stop checking for or parsing commit graph files if core.commitgraph=0. Signed-off-by: Derrick Stolee

[PATCH v2 02/14] graph: add commit graph design document

Add Documentation/technical/commit-graph.txt with details of the planned commit graph feature, including future plans. Signed-off-by: Derrick Stolee --- Documentation/technical/commit-graph.txt | 189 +++ 1 file changed, 189 insertions(+)

[PATCH v2 12/14] commit-graph: read only from specific pack-indexes

Teach git-commit-graph to inspect the objects only in a certain list of pack-indexes within the given pack directory. This allows updating the commit graph iteratively, since we add all commits stored in a previous commit graph. Signed-off-by: Derrick Stolee ---

[PATCH v2 09/14] commit-graph: teach git-commit-graph --delete-expired

Teach git-commit-graph to delete the graph previously referenced by 'graph_head' when writing a new graph file and updating 'graph_head'. This prevents data creep by storing a list of useless graphs. Be careful to not delete the graph if the file did not change. Signed-off-by: Derrick Stolee

[PATCH v2 05/14] commit-graph: implement git-commit-graph --write

Teach git-commit-graph to write graph files. Create new test script to verify this command succeeds without failure. Signed-off-by: Derrick Stolee --- Documentation/git-commit-graph.txt | 18 +++ builtin/commit-graph.c | 30

[PATCH v2 07/14] commit-graph: implement git-commit-graph --update-head

It is possible to have multiple commit graph files in a pack directory, but only one is important at a time. Use a 'graph_head' file to point to the important file. Teach git-commit-graph to write 'graph_head' upon writing a new commit graph file. Signed-off-by: Derrick Stolee

[PATCH v2 13/14] commit-graph: close under reachability

Teach construct_commit_graph() to walk all parents from the commits discovered in packfiles. This prevents gaps given by loose objects or previously-missed packfiles. Signed-off-by: Derrick Stolee --- commit-graph.c | 26 ++

[PATCH v2 04/14] commit-graph: implement construct_commit_graph()

Teach Git to write a commit graph file by checking all packed objects to see if they are commits, then store the file in the given pack directory. Signed-off-by: Derrick Stolee --- Makefile | 1 + commit-graph.c | 376

[PATCH v2 14/14] commit-graph: build graph from starting commits

Teach git-commit-graph to read commits from stdin when the --stdin-commits flag is specified. Commits reachable from these commits are added to the graph. This is a much faster way to construct the graph than inspecting all packed objects, but is restricted to known tips. For the Linux

Re: git add --all does not respect submodule..ignore

On Tue, Jan 30, 2018 at 12:25 PM, Michael Scott-Nelson wrote: > Giving a submodule "ignore=all" or "ignore=dirty" in .gitmodule > successfully removes that module from `git status` queries. However, > these same diffs are automatically added by git-add, eg `git add .` or >

Re: recommendations for log enhancement

On Sun, Jan 28, 2018 at 7:46 AM, 牛旭 wrote: > Our team studies the consistent edits of git during evolution. And we find > several missed edits in the latest release of git. For example, there are two > consist edits we have figured out from historical commits: Thanks for

Re: [PATCH 37/37] replace: rename 'new' variables

Stefan Beller writes: > On Mon, Jan 29, 2018 at 2:37 PM, Brandon Williams wrote: >> Rename C++ keyword in order to bring the codebase closer to being able >> to be compiled with a C++ compiler. >> >> Signed-off-by: Brandon Williams >>

Re: git add --all does not respect submodule..ignore

On Tue, Jan 30, 2018 at 1:56 PM, Stefan Beller wrote: > The assume-unchanged bit is a performance optimisation for powerusers, > but its documentation words it in a less dangerous way, such that it sounds > as if it is a UX feature instead of a performance thing. I'd stay away

[PATCH v7 27/31] merge-recursive: fix overwriting dirty files involved in renames

This fixes an issue that existed before my directory rename detection patches that affects both normal renames and renames implied by directory rename detection. Additional codepaths that only affect overwriting of directy files that are involved in directory rename detection will be added in a

[PATCH v7 26/31] merge-recursive: avoid clobbering untracked files with directory renames

Signed-off-by: Elijah Newren --- merge-recursive.c | 42 +++-- t/t6043-merge-rename-directories.sh | 6 +++--- 2 files changed, 43 insertions(+), 5 deletions(-) diff --git a/merge-recursive.c b/merge-recursive.c index

[PATCH v7 12/31] merge-recursive: move the get_renames() function

I want to re-use some other functions in the file without moving those other functions or dealing with a handful of annoying split function declarations and definitions. Signed-off-by: Elijah Newren --- merge-recursive.c | 139

[PATCH v7 09/31] directory rename detection: miscellaneous testcases to complete coverage

I came up with the testcases in the first eight sections before coding up the implementation. The testcases in this section were mostly ones I thought of while coding/debugging, and which I was too lazy to insert into the previous sections because I didn't want to re-label with all the testcase

[PATCH v7 07/31] directory rename detection: more involved edge/corner testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 396 1 file changed, 396 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index fbeb8f4316..68bd86f555 100755 ---

[PATCH v7 08/31] directory rename detection: testcases exploring possibly suboptimal merges

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 404 1 file changed, 404 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 68bd86f555..e2db5d0ac1 100755 ---

[PATCH v7 21/31] merge-recursive: add a new hashmap for storing file collisions

Directory renames with the ability to merge directories opens up the possibility of add/add/add/.../add conflicts, if each of the N directories being merged into one target directory all had a file with the same name. We need a way to check for and report on such collisions; this hashmap will be

[PATCH v7 02/31] directory rename detection: directory splitting testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 143 1 file changed, 143 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index d045f0e31e..b22a9052b3 100755 ---

[PATCH v7 04/31] directory rename detection: partially renamed directory testcase/discussion

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 107 1 file changed, 107 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 8049ed5fc9..f0213f2bbd 100755 ---

[PATCH v7 19/31] merge-recursive: add get_directory_renames()

This populates a list of directory renames for us. The list of directory renames is not yet used, but will be in subsequent commits. Signed-off-by: Elijah Newren --- merge-recursive.c | 155 -- 1 file changed, 152

[PATCH v7 18/31] merge-recursive: make a helper function for cleanup for handle_renames

In anticipation of more involved cleanup to come, make a helper function for doing the cleanup at the end of handle_renames. Rename the already existing cleanup_rename[s]() to final_cleanup_rename[s](), name the new helper initial_cleanup_rename(), and leave the big comment in the code about why

[PATCH v7 13/31] merge-recursive: introduce new functions to handle rename logic

The amount of logic in merge_trees() relative to renames was just a few lines, but split it out into new handle_renames() and cleanup_renames() functions to prepare for additional logic to be added to each. No code or logic changes, just a new place to put stuff for when the rename detection

[PATCH v7 03/31] directory rename detection: testcases to avoid taking detection too far

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 153 1 file changed, 153 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index b22a9052b3..8049ed5fc9 100755 ---

[PATCH v7 29/31] directory rename detection: new testcases showcasing a pair of bugs

Add a testcase showing spurious rename/rename(1to2) conflicts occurring due to directory rename detection. Also add a pair of testcases dealing with moving directory hierarchies around that were suggested by Stefan Beller as "food for thought" during his review of an earlier patch series, but

  1   2   >