Re: [RFD] Long term plan with submodule refs?

On Fri, Nov 10, 2017 at 12:01 PM, Stefan Beller wrote: >> Basically, a workflow where it's easier to have each submodule checked out at master, and we can still keep track of historical relationship of what commit was the submodule at some time ago, but without

Re: Unify annotated and non-annotated tags

On 11/11/2017 03:06, Junio C Hamano wrote: > Igor Djordjevic writes: > >> If you would like to mimic output of "git show-ref", repeating >> commits for each tag pointing to it and showing full tag name as >> well, you could do something like this, for example: >>

Re: use of PWD

Jeff King writes: > So totally orthogonal to your bug, I wonder if we ought to be doing: > > diff --git a/sha1_file.c b/sha1_file.c > index 057262d46e..0b76233aa7 100644 > --- a/sha1_file.c > +++ b/sha1_file.c > @@ -530,11 +530,11 @@ void prepare_alt_odb(void) > if

Re: Unify annotated and non-annotated tags

Igor Djordjevic writes: > If you would like to mimic output of "git show-ref", repeating > commits for each tag pointing to it and showing full tag name as > well, you could do something like this, for example: > > for tag in $(git for-each-ref

Hello,

-- Good day! What is the best way to reach you for business? I am writing you because I have an opportunity to present to you. I have a business that I would like to discuss with you. Waiting to read from you soon. Thank you

Re: Unify annotated and non-annotated tags

Hi Anatoly, On 10/11/2017 11:58, anatoly techtonik wrote: > It is hard to work with Git tags, because on low level hash > of non-annotated tag is pointing to commit, but hash for > annotated tag is pointing to tag metadata. > > On low level that means that there is no way to get commit > hash

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

On Wed, Nov 08, 2017 at 02:50:24PM +0900, Junio C Hamano wrote: > * bc/submitting-patches-in-asciidoc (2017-10-30) 2 commits > - Documentation: convert SubmittingPatches to AsciiDoc > - Documentation: enable compat-mode for Asciidoctor > > The SubmittingPatches document has been converted to

[PATCH] t/3512: demonstrate unrelated submodule/file conflict as cherry-pick failure

Signed-off-by: Stefan Beller --- I rewrote your script to integrate with our test suite, potentially acting as a regression test once we solve the Directory/File conflict issue. Thanks, Stefan t/t3512-cherry-pick-submodule.sh | 36 1

Re: [PATCH 2/4] Remove silent clamp of renameLimit

On Fri, Nov 10, 2017 at 10:36:17AM -0800, Elijah Newren wrote: > Thanks for taking a look! > > On Fri, Nov 10, 2017 at 10:26 AM, Stefan Beller wrote: > > From a technical perspective, I would think that if > > (num_create <= rename_limit || num_src <= rename_limit) > > holds

Re: cherry-pick very slow on big repository

On Fri, Nov 10, 2017 at 6:05 AM, Peter Krefting wrote: > Derrick Stolee: > >> Git is spending time detecting renames, which implies you probably renamed >> a folder or added and deleted a large number of files. This rename detection >> is quadratic (# adds times #

Re: [PATCH 00/30] Add directory rename detection to git

On Fri, Nov 10, 2017 at 2:27 PM, Philip Oakley wrote: > From: "Elijah Newren" >> >> In this patchset, I introduce directory rename detection to >> merge-recursive, >> predominantly so that when files are added to directories on one side of >> history and

[PATCH 2/2] stash: implement builtin stash helper

Start moving stash functions over to builtin c code and call them in the shell script, instead of converting it all at once. Signed-off-by: Joel Teichroeb --- Makefile| 1 + builtin.h | 1 + builtin/stash--helper.c | 516

[PATCH 1/2] merge: close the index lock when not writing the new index

If the merge does not have anything to do, it does not unlock the index, causing any further index operations to fail. Thus, always unlock the index regardless of outcome. Signed-off-by: Joel Teichroeb --- merge-recursive.c | 9 ++--- 1 file changed, 6 insertions(+), 3

[PATCH 0/2] Convert some stash functionality to a builtin

I've been working on converting all of git stash to be a builtin, however it's hard to get it all working at once with limited time, so I've moved around half of it to a new stash--helper builtin and called these functions from the shell script. Once this is stabalized, it should be easier to

[PATCH] builtin/describe.c: describe a blob

Sometimes users are given a hash of an object and they want to identify it further (ex.: Use verify-pack to find the largest blobs, but what are these? or [1]) When describing commits, we try to anchor them to tags or refs, as these are conceptually on a higher level than the commit. And if there

[PATCH 0/1] describe a blob: with better docs

This replaces the last patch of origin/sb/describe-blob. Interdiff is below. I chose to not mention options at all, as currently none are applicable; Check for options and tell the user by die()ing that we don't know about the options for blobs. Thanks, Stefan builtin/describe.c: describe a

Re: [PATCH 00/30] Add directory rename detection to git

From: "Elijah Newren" [This series is entirely independent of my rename detection limits series. However, I have a separate rename detection performance series that depends on both this series and the rename detection limits series.] In this patchset, I introduce directory

[RFC PATCH 8/9] merge-recursive: Accelerate rename detection

If a file is unmodified on one side of history (no content changes, no name change, and no mode change) and is renamed on the other side, then the correct merge result is to take both the file name and the file contents (and file mode) of the renamed file. merge-recursive detects this rename and

[RFC PATCH 5/9] merge-recursive: Fix rename/add conflict handling

This makes the rename/add conflict handling make use of the new handle_file_collision() function, which fixes several bugs and improves things for the rename/add case significantly. Previously, rename/add would: * Not leave any higher order stage entries in the index, making it appear as

[RFC PATCH 6/9] merge-recursive: Improve handling for rename/rename(2to1) conflicts

This makes the rename/rename(2to1) conflicts use the new handle_file_collision() function. Since that function was based originally on the rename/rename(2to1) handling code, the main differences here are in what was added. In particular: * If the two colliding files are similar, instead of

[RFC PATCH 7/9] merge-recursive: Improve handling for add/add conflicts

This makes add/add conflicts use the new handle_file_collision() function. This leaves the handling of the index the same, but modifies how the working tree is handled: instead of always doing a two-way merge of the file contents and recording them at the collision path name, we instead first

[RFC PATCH 9/9] diffcore-rename: Filter rename_src list when possible

We have to look at each entry in rename_src a total of rename_dst_nr times. When we're not detecting copies, any exact renames or ignorable rename paths will just be skipped over. While checking that these can be skipped over is a relatively cheap check, it's still a waste of time to do that

[RFC PATCH 1/9] diffcore-rename: No point trying to find a match better than exact

diffcore_rename() had some code to avoid having destination paths that already had an exact rename detected from being re-checked for other renames. Source paths, however, were re-checked because we wanted to allow the possibility of detecting copies. But if copy detection isn't turned on, then

[RFC PATCH 4/9] Add testcases for improved file collision conflict handling

Adds testcases dealing with file collisions for the following types of conflicts: * add/add * rename/add * rename/rename(2to1) These tests include expectations for new, smarter behavior provided by handle_file_collision(). Since that function is not in use yet, the tests are currently

[RFC PATCH 3/9] merge-recursive: New function for better colliding conflict resolutions

There are three conflict types that represent two (possibly entirely unrelated) files colliding at the same location: * add/add * rename/add * rename/rename(2to1) These three conflict types already share more similarity than might be immediately apparent from their description: (1) the

[RFC PATCH 0/9] Improve rename detection performance in merge recursive

This series depends on BOTH my rename-limits and directory-detection series (https://public-inbox.org/git/20171110173956.25105-1-new...@gmail.com/ and https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.com/). This series could be modified to be submitted with no dependencies on those

[RFC PATCH 2/9] merge-recursive: Avoid unnecessary string list lookups

Since we're taking entries from active_cache, which is already in sorted order with same-named entries adjacent, we can skip a lookup. Also, we can just use append instead of insert (avoiding the need to find where to put the new item) and still end up with a sorted list. Signed-off-by: Elijah

Re: [PATCH] bisect: mention "view" as an alternative to "visualize"

On Fri, Nov 10, 2017 at 4:13 PM, Robert P. J. Day wrote: > On Fri, 10 Nov 2017, Eric Sunshine wrote: > >> Thanks for the patch. Some comments below... >> >> On Fri, Nov 10, 2017 at 11:32 AM, Robert P. J. Day >> wrote: >> > Tweak a number of files to

Re: [PATCH] bisect: mention "view" as an alternative to "visualize"

On Fri, 10 Nov 2017, Eric Sunshine wrote: > Thanks for the patch. Some comments below... > > On Fri, Nov 10, 2017 at 11:32 AM, Robert P. J. Day > wrote: > > Tweak a number of files to mention "view" as an alternative to > > "visualize": > > You probably want to end this

Re: [PATCH] bisect: mention "view" as an alternative to "visualize"

Thanks for the patch. Some comments below... On Fri, Nov 10, 2017 at 11:32 AM, Robert P. J. Day wrote: > Tweak a number of files to mention "view" as an alternative to > "visualize": You probably want to end this sentence with a period, not a colon. >

[PATCH v1] fsmonitor: simplify determining the git worktree under Windows

I haven't tested the non Windows paths but the patch looks reasonable. This inspired me to get someone more familiar with perl (thanks Johannes) to revisit this code for the Windows side as well. The logic for determining the git worktree when running on Windows is more complex than necessary.

Re: [RFC] protocol version 2

On Fri, 20 Oct 2017 10:18:39 -0700 Brandon Williams wrote: > Some of the pain points with the current protocol spec are: After some in-office discussion, I think that the most important pain point is that we have to implement each protocol twice: once for HTTP(S), and once

Re: [RFD] Long term plan with submodule refs?

> >>> Basically, a workflow where it's easier to have each submodule checked >>> out at master, and we can still keep track of historical relationship >>> of what commit was the submodule at some time ago, but without causing >>> some of these headaches. >> >> So essentially a repo or otherwise

Re: [PATCH v2 0/9] sequencer: dont't fork git commit

Phillip Wood writes: > Here's the summary from the previous version > These patches teach the sequencer to create commits without forking > git commit when the commit message does not need to be edited. This > speeds up cherry picking 10 commits by 26% and picking 10

[PATCH 21/30] 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 | 146 ++ 1 file changed, 146

[PATCH 13/30] directory rename detection: tests for handling overwriting untracked files

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

[PATCH 19/30] 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 27/30] 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 | 195

[PATCH 02/30] merge-recursive: Fix logic ordering issue

merge_trees() did a variety of work, including: * Calling get_unmerged() to get unmerged entries * Calling record_df_conflict_files() with all unmerged entries to do some work to ensure we could handle D/F conflicts correctly * Calling get_renames() to check for renames. An easily

[PATCH 03/30] merge-recursive: Add explanation for src_entry and dst_entry

If I have to walk through the debugger and inspect the values found in here in order to figure out their meaning, despite having known these things inside and out some years back, then they probably need a comment for the casual reader to explain their purpose. Signed-off-by: Elijah Newren

[PATCH 04/30] directory rename detection: basic testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 391 1 file changed, 391 insertions(+) create mode 100755 t/t6043-merge-rename-directories.sh diff --git a/t/t6043-merge-rename-directories.sh

[PATCH 28/30] merge-recursive: Avoid clobbering untracked files with directory renames

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

[PATCH 20/30] merge-recursive: Add a new hashmap for storing directory renames

This just adds dir_rename_entry and the associated functions; code using these will be added in subsequent commits. Signed-off-by: Elijah Newren --- merge-recursive.c | 24 merge-recursive.h | 8 2 files changed, 32 insertions(+) diff --git

[PATCH 30/30] 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 18/30] 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 25/30] 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 17/30] 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 22/30] 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 15/30] 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 | 138

[PATCH 10/30] directory rename detection: more involved edge/corner testcases

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 347 1 file changed, 347 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 157299105f..115d0d2622 100755 ---

[PATCH 14/30] directory rename detection: tests for handling overwriting dirty files

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 401 1 file changed, 401 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 7af8962512..4066b08767 100755 ---

[RFC PATCH 29/30] 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 12/30] directory rename detection: miscellaneous testcases to complete coverage

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

[PATCH 05/30] directory rename detection: directory splitting testcases

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

[PATCH 07/30] directory rename detection: partially renamed directory testcase/discussion

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

[PATCH 26/30] 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 24/30] 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 23/30] 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 11/30] directory rename detection: testcases exploring possibly suboptimal merges

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

[PATCH 09/30] directory rename detection: testcases checking which side did the rename

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

[PATCH 08/30] directory rename detection: files/directories in the way of some renames

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

[PATCH 16/30] 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 06/30] directory rename detection: testcases to avoid taking detection too far

Signed-off-by: Elijah Newren --- t/t6043-merge-rename-directories.sh | 137 1 file changed, 137 insertions(+) diff --git a/t/t6043-merge-rename-directories.sh b/t/t6043-merge-rename-directories.sh index 00811f512a..021513ec00 100755 ---

[PATCH 00/30] Add directory rename detection to git

[This series is entirely independent of my rename detection limits series. However, I have a separate rename detection performance series that depends on both this series and the rename detection limits series.] In this patchset, I introduce directory rename detection to merge-recursive,

[PATCH 01/30] Tighten and correct a few testcases for merging and cherry-picking

t3501 had a testcase originally added to ensure cherry-pick wouldn't segfault when working with a dirty file involved in a rename. While the segfault was fixed, there was another problem this test demonstrated: namely, that git would overwrite a dirty file involved in a rename. Further, the test

Re: [PATCH v3 0/8] Create Git/Packet.pm

Christian Couder writes: > There are only a few small changes compared to v2: Please go incremental as v2 is already in 'next', and small changes are easier to reiew and understand when given as follow-up "polish this minor glitch in the initial effort" patches.

Re: [PATCH v2 2/9] commit: move empty message checks to libgit

On 10/11/17 11:09, Phillip Wood wrote: > From: Phillip Wood > > Move the functions that check for empty messages from bulitin/commit.c > to sequencer.c so they can be shared with other commands. The > functions are refactored to take an explicit cleanup mode and

Re: [PATCH v2 3/9] Add a function to update HEAD after creating a commit

Phillip Wood writes: > From: Phillip Wood > > Add update_head() based on the code that updates HEAD after committing > in builtin/commit.c that can be called by 'git commit' and other > commands. > > Signed-off-by: Phillip Wood

Re: [PATCH 2/4] Remove silent clamp of renameLimit

Thanks for taking a look! On Fri, Nov 10, 2017 at 10:26 AM, Stefan Beller wrote: >> - if (rename_limit <= 0 || rename_limit > 32767) >> - rename_limit = 32767; >> if ((num_create <= rename_limit || num_src <= rename_limit) && >> -

Re: [RFC] cover-at-tip

On Fri, 10 Nov 2017 16:37:49 +0100 Nicolas Morey-Chaisemartin wrote: > > Hi, > > > > I'm starting to look into the cover-at-tip topic that I found in the > > leftover bits (http://www.spinics.net/lists/git/msg259573.html) Thanks - I personally would find this very

Re: [PATCH 0/4] Fix issues with rename detection limits

On Fri, Nov 10, 2017 at 10:13 AM, Elijah Newren wrote: > In a repo with around 60k files with deep directory hierarchies (due to > Elijah Newren (4): > sequencer: Warn when internal merge may be suboptimal due to > renameLimit > Remove silent clamp of renameLimit >

Re: [PATCH 2/4] Remove silent clamp of renameLimit

On Fri, Nov 10, 2017 at 9:39 AM, Elijah Newren wrote: > In commit 0024a5492 (Fix the rename detection limit checking; 2007-09-14), > the renameLimit was clamped to 32767. This appears to have been to simply > avoid integer overflow in the following computation: > >

Re: [RFC] cover-at-tip

Nicolas Morey-Chaisemartin writes: > I would need to add "some" level of parsing to am.c to make sure > the patch content is just garbage and that there are no actual > hunks for that. > > I did not find any public API that would allow me to do that, > although

Re: Bug - Status - Space in Filename

Jeff King writes: > Are there callers who don't just print the result? If not, we could just > always emit. That's slightly more efficient since it drops the expensive > strbuf_insert (though there are already so many copies going on in > quote_path_relative that it hardly

[PATCH 0/4] Fix issues with rename detection limits

In a repo with around 60k files with deep directory hierarchies (due to being predominantly java code) and which had a few high level directories moved around (making it appear to git as dozens of thousands of individual file renames), attempts to cherry-pick commits across product versions

[PATCH 0/4] Fix issues with rename detection limits

In a repo with around 60k files with deep directory hierarchies (due to being predominantly java code) and which had a few high level directories moved around (making it appear to git as dozens of thousands of individual file renames), attempts to cherry-pick commits across product versions

Re: is there a stylistic preference for a trailing "--" on a command?

On Fri, Nov 10, 2017 at 5:57 AM, Robert P. J. Day wrote: > > just noticed these examples in "man git-bisect": > > EXAMPLES > $ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good > ... > $ git bisect start HEAD origin --# HEAD is bad, origin is good >

Re: [PATCH v1 5/8] sequencer: don't die in print_commit_summary()

Phillip Wood writes: > On 07/11/17 15:13, Junio C Hamano wrote: > ... >> Another possibility perhaps is that the function is safe to reuse >> already even without this patch, of course ;-). >> > Hmm, maybe it is. Looking at pick_commits() and do_pick_commit() if the >

Re: [Query] Separate hooks for Git worktrees

On Thu, Nov 9, 2017 at 9:00 PM, Junio C Hamano wrote: > Stefan Beller writes: > >> We have no worktree specific config yet, though patches for >> this were floated on the mailing list. >> >> Though recent versions of git learned to conditionally include >>

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

On Fri, Nov 10, 2017 at 03:02:50PM +, Adam Dinwoodie wrote: > The examples and common practice for adding markers such as "RFC" or > "v2" to the subject of patch emails is to have them within the same > brackets as the "PATCH" text, not after the closing bracket. Further, > the practice of

[PATCH 4/4] sequencer: Show rename progress during cherry picks

When trying to cherry-pick a change that has lots of renames, it is somewhat unsettling to wait a really long time without any feedback. Signed-off-by: Elijah Newren --- sequencer.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sequencer.c b/sequencer.c index

[PATCH 1/4] sequencer: Warn when internal merge may be suboptimal due to renameLimit

Having renamed files silently treated as deleted/modified conflicts instead of correctly resolving the renamed/modified case has caused lots of pain for some users. Eventually, some of them figured out to set merge.renameLimit to something higher, but without feedback about what value it should

[PATCH 3/4] progress: Fix progress meters when dealing with lots of work

The possibility of setting merge.renameLimit beyond 2^16 raises the possibility that the values passed to progress can exceed 2^32. For my usecase of interest, I only needed to pass a value a little over 2^31. If I were only interested in fixing my usecase, I could have simply changed last_value

[PATCH 2/4] Remove silent clamp of renameLimit

In commit 0024a5492 (Fix the rename detection limit checking; 2007-09-14), the renameLimit was clamped to 32767. This appears to have been to simply avoid integer overflow in the following computation: num_create * num_src <= rename_limit * rename_limit although it also could be viewed as a

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

Rafael Ascensão writes: > I agree that describe should receive the "normalize" treatment. However, > and following the same reasoning, why should describe users adopt the > rules imposed by --glob? I could argue they're also used to the way it > works now. > > That being

Re: cherry-pick very slow on big repository

Interesting timing. I have some performance patches specifically developed because rename detection during merges made a small cherry-pick in a large repo rather slow...in my case, I dropped the time for the cherry pick by a factor of about 30 (no guarantees you'll see the same; it's very

JPMorgan Chase & Co.

JPMorgan Chase & Co. 270 Park Avenue, Midtown Manhattan New York City, Attention: We are pleased to inform you about your fund which was seized by International Monetary Fund (IMF) due to your failure to provide necessary credentials which state the legitimacy of your fund, the fund was said

Urgent Message.

Dear Western Union Customer, You have been awarded with the sum of $50,000 USD by our office, as one of our customers who use Western Union in their daily business transaction. This award was been selected through the internet, where your e-mail address was indicated and notified. Please

RE: cherry-pick very slow on big repository

Since this is happening during a merge, you might need to use merge.renameLimit or the merge strategy option of -Xno-renames. Although the code does fallback to use the diff.renameLimit but there is still a lot that is done before even checking the rename limit so I would first try getting

Bug: cherry-pick & submodule

I faced an unexpected behaviour during cherry-picking a commit to a branch with a submodule. Git graph: A -- B [master] \ `- C -- D [test] Both branches have a file with name `a_file`. It has been added by commit A. Commits B and C add a folder with name `a_submodule` to the respective

[PATCH] bisect: mention "view" as an alternative to "visualize"

Tweak a number of files to mention "view" as an alternative to "visualize": Documentation/git-bisect.txt | 9 - Documentation/user-manual.txt | 3 ++- builtin/bisect--helper.c | 2 +- contrib/completion/git-completion.bash | 2 +- git-bisect.sh

proper patch prefix for tweaking both git-bisect.sh and git-bisect.txt?

digging through both git-bisect.sh and git-bisect.txt, and it seems pretty clear they're both a bit out of date WRT documenting the newer alternatives "old"/"new" as opposed to the older "good"/"bad" terms, and a few other things. first, trivially, neither the script nor the man page mention

Bug: cherry-pick & submodule

I faced an unexpected behaviour during cherry-picking a commit to a branch with a submodule. Git graph: A -- B [master] \ `- C -- D [test] Both branches have a file with name `a_file`. It has been added by commit A. Commits B and C add a folder with name `a_submodule` to the respective

Re: [RFC] cover-at-tip

Le 10/11/2017 à 11:24, Nicolas Morey-Chaisemartin a écrit : > Hi, > > I'm starting to look into the cover-at-tip topic that I found in the leftover > bits (http://www.spinics.net/lists/git/msg259573.html) > > Here's a first draft of a patch that adds support for format-patch > --cover-at-tip.

[PATCH v4] doc/SubmittingPatches: correct subject guidance

The examples and common practice for adding markers such as "RFC" or "v2" to the subject of patch emails is to have them within the same brackets as the "PATCH" text, not after the closing bracket. Further, the practice of `git format-patch` and the like, as well as what appears to be the more

Re: [PATCH v1 5/8] sequencer: don't die in print_commit_summary()

On 07/11/17 15:13, Junio C Hamano wrote: > Junio C Hamano writes: > >> And this step is going in the right direction, but I am not sure if >> this made the function safe enough to be called repeatedly from the >> rebase machinery and we are ready to unleash this to the end

Re: cherry-pick very slow on big repository

Derrick Stolee: Git is spending time detecting renames, which implies you probably renamed a folder or added and deleted a large number of files. This rename detection is quadratic (# adds times # deletes). Yes, a couple of directories with a lot of template files have been renamed (and

is there a stylistic preference for a trailing "--" on a command?

just noticed these examples in "man git-bisect": EXAMPLES $ git bisect start HEAD v1.2 -- # HEAD is bad, v1.2 is good ... $ git bisect start HEAD origin --# HEAD is bad, origin is good ... $ git bisect start HEAD HEAD~10 -- # culprit is among the last 10 is there some

Re: [PATCH v1 2/2] log: add option to choose which refs to decorate

On 07/11/17 00:18, Junio C Hamano wrote: > Jacob Keller writes: > > I would have to say that the describe's one is wrong if it does not > match what for_each_glob_ref() does for the log family of commands' > "--branches=" etc. describe.c::get_name() uses positive > and

[PATCH v3 8/8] Add Git/Packet.pm from parts of t0021/rot13-filter.pl

And while at it let's simplify t0021/rot13-filter.pl by using Git/Packet.pm. This will make it possible to reuse packet related functions in other test scripts. Signed-off-by: Christian Couder --- perl/Git/Packet.pm | 169

  1   2   >