Gruß
In einer kurzen Einführung bin ich Barrister Clark Harrison, aus
Portugal, aber jetzt lebe ich in London, ich habe Ihnen eine E-Mail
über Ihre verstorbene Verwandte Familie geschickt, aber ich habe keine
Antwort von Ihnen erhalten, verstorben ist ein Bürger Ihres Landes mit
derselbe Nachname
On Fri, Jan 05, 2018 at 02:37:25PM -0800, Junio C Hamano wrote:
> Well, MaintNotes on the 'todo' branch needs a bit of updating, as it
> says something somewhat misleading.
>
> -- >8 --
> Subject: MaintNotes: clarify the purpose of maint->master upmerge
Yup, this makes sense. Thanks for clarifyi
Loan Offer at 3% Lowest Rate Get Now.
> On 06 Jan 2018, at 00:22, Junio C Hamano wrote:
>
> Lars Schneider writes:
>
>>> On 31 Dec 2017, at 09:05, tbo...@web.de wrote:
>>>
>>> From: Torsten Bögershausen
>>>
>>> When calling convert_to_git(), the checksafe parameter has been used to
>>> check if commit would give a non-roundtrip
From: Lars Schneider
Since 3733e69464 (use xmallocz to avoid size arithmetic, 2016-02-22) we
allocate the buffer for the lower case string with xmallocz(). This
already ensures a NUL at the end of the allocated buffer.
Remove the unnecessary assignment.
Signed-off-by: Lars Schneider
---
strbu
From: Lars Schneider
Git recognizes files encoded with ASCII or one of its supersets (e.g.
UTF-8 or ISO-8859-1) as text files. All other encodings are usually
interpreted as binary and consequently built-in Git text processing
tools (e.g. 'git diff') as well as most Git web front ends do not
visu
From: Lars Schneider
Create a copy of an existing string and make all characters upper case.
Similar xstrdup_tolower().
This function is used in a subsequent commit.
Signed-off-by: Lars Schneider
---
strbuf.c | 12
strbuf.h | 1 +
2 files changed, 13 insertions(+)
diff --git a/
From: Lars Schneider
Add the GIT_TRACE_CHECKOUT_ENCODING environment variable to enable
tracing for content that is reencoded with the checkout-encoding
attribute.
Signed-off-by: Lars Schneider
---
convert.c| 28
t/t0028-checkout-encoding.sh |
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 Unicode standard instructs to assume big-endian if there in no BOM
From: Torsten Bögershausen
When calling convert_to_git(), the checksafe parameter defined what
should happen if the EOL conversion (CRLF --> LF --> CRLF) does not
roundtrip cleanly. In addition, it also defined if line endings should
be renormalized (CRLF --> LF) or kept as they are.
checksafe w
From: Lars Schneider
Whenever a data stream is declared to be UTF-16BE, UTF-16LE, UTF-32BE
or UTF-32LE a BOM must not be used [1]. The function returns true if
this is the case.
This function is used in a subsequent commit.
[1] http://unicode.org/faq/utf_bom.html#bom10
Signed-off-by: Lars Schn
From: Lars Schneider
Hi,
Patches 1-5 and 6 are helper functions and preparation.
Patch 6 is the actual change.
I am still torn between "checkout-encoding" and "working-tree-encoding"
as attribute name. I am happy to hear arguments for/against one or the
other.
Changes since v2:
* Added Torste
Currently when 'git stash push -- ' is used, untracked files
that match the pathspec will be deleted, even though they do not end up
in a stash anywhere.
This is because the original commit introducing the pathspec feature in
git stash push (df6bba0937 ("stash: teach 'push' (and 'create_stash') to
Hi,
Robert Dailey wrote:
> Not sure if this is intended or a bug, but with the following configuration:
>
> $ git config --global merge.ff false
>
> I am not able to merge my topic branch into master with squash option:
>
> $ git checkout master
> $ git merge --squash topic
> fatal: You cannot co
On 01/03, Stefan Beller wrote:
> On Tue, Jan 2, 2018 at 4:18 PM, Brandon Williams wrote:
> > +
> > +#define FETCH_CHECK_LOCAL 0
> > +#define FETCH_SEND_REQUEST 1
> > +#define FETCH_PROCESS_ACKS 2
> > +#define FETCH_SEND_HAVES 3
> > +#define FETCH_GET_PACK 4
> > +#define FETCH_DONE 5
> > +
> > +sta
On 01/03, Stefan Beller wrote:
> On Tue, Jan 2, 2018 at 4:18 PM, Brandon Williams wrote:
> > Introduce the ls-refs server command. In protocol v2, the ls-refs
> > command is used to request the ref advertisement from the server. Since
> > it is a command which can be requested (as opposed to man
On 01/03, Stefan Beller wrote:
> On Tue, Jan 2, 2018 at 4:18 PM, Brandon Williams wrote:
> > The current pkt-line API encodes the status of a pkt-line read in the
> > length of the read content. An error is indicated with '-1', a flush
> > with '0' (which can be confusing since a return value of
A release candidate Git v2.16.0-rc1 is now available for testing
at the usual places. It is comprised of 455 non-merge commits
since v2.15.0, contributed by 79 people, 23 of which are new faces.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/testing/
The following pu
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The tip of 'master' has been tagge
Lars Schneider writes:
>> On 31 Dec 2017, at 09:05, tbo...@web.de wrote:
>>
>> From: Torsten Bögershausen
>>
>> When calling convert_to_git(), the checksafe parameter has been used to
>> check if commit would give a non-roundtrip conversion of EOL.
>>
>> When checksafe was introduced, 3 value
--
Hello Dear,
Its me Ruth, did you receive my previous email? please write me back
immediately to let me know, i wait to hear back from you, kisses.
Ævar Arnfjörð Bjarmason writes:
> Skip the newly added file creation tests on Windows proper, these
> already work under Cygwin, but as that involves a significant
> emulation layer the results are different under Windows proper with
> MinGW.
> ...
> diff --git a/t/t3070-wildmatch.sh b/t/t3070-w
Jeff King writes:
> On Fri, Jan 05, 2018 at 12:45:03PM -0800, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > Out of curiosity, did this change at some point? I thought the process
>> > used to be to merge to maint, and then pick up topics in master by
>> > merging maint to master.
>>
>>
Ævar Arnfjörð Bjarmason writes:
>> Judging by the way the other side uses "test_perf $prereq ..."
>> without quotes around it, I suspect you do expect it to be empty in
>> some cases. It means you expect test_have_prereq is prepared to
>> skip an empty prerequisite in a prereq list, but I do not
Johannes Schindelin writes:
>> diff --git a/diff-lib.c b/diff-lib.c
>> index 8104603a3..13ff00d81 100644
>> --- a/diff-lib.c
>> +++ b/diff-lib.c
>> @@ -95,6 +95,9 @@ int run_diff_files(struct rev_info *revs, unsigned int
>> option)
>>
>> diff_set_mnemonic_prefix(&revs->diffopt, "i/", "w/"
Yasushi SHOJI writes:
> The patch (actually, I've tested the one in pu, 2e9fdc795cb27) avoids
> the seg fault for sure, but the question is:
>
> When does the list allowed to contain NULLs?
A very legitimate question. With the proposed log message alone, it
is even tempting to declare that the
Skip the newly added file creation tests on Windows proper, these
already work under Cygwin, but as that involves a significant
emulation layer the results are different under Windows proper with
MinGW.
Ideally we'd get exhaustive coverage for this area on all platforms,
but having any increase in
Beautiful!
Pulled down that commit, was able to build and can confirm the issue
is fixed in git gui!
This has been a thorn in my side, so I appreciate your help! I look
forward to it being included in the next release for git in Homebrew!
:)
On Fri, Jan 5, 2018 at 4:41 PM, Johannes Schindelin w
On Fri, Jan 5, 2018 at 2:54 PM, Bryan Turner wrote:
> The two _aren't_ distinctly separate, though. "git merge --squash
> --ff-only" has very different semantics to "git merge --squash --ff",
> in that it will only create a new squashed commit (or fast-forward a
> single commit) if the incoming co
Hi Peff,
On Fri, 5 Jan 2018, Jeff King wrote:
> On Fri, Jan 05, 2018 at 09:22:07PM +0100, Johannes Schindelin wrote:
>
> > On Fri, 5 Jan 2018, Isaac Shabtay wrote:
> >
> > > Done: https://github.com/git-for-windows/git/pull/1421
> > >
> > > I added credit to Jeff in the PR's description.
> >
On Thu, Jan 04 2018, Junio C. Hamano jotted:
> Ævar Arnfjörð Bjarmason writes:
>
>> Ever since 5b594f457a ("Threaded grep", 2010-01-25) the number of
>> threads git-grep uses under PTHREADS has been hardcoded to 8, but
>> there's no performance test to check whether this is an optimal
>> settin
Hi Elijah,
On Fri, 5 Jan 2018, Elijah Newren wrote:
> 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 t
Hi Elijah,
On Fri, 5 Jan 2018, Elijah Newren wrote:
> t3501 had a testcase originally added in 05f2dfb965 (cherry-pick:
> demonstrate a segmentation fault, 2016-11-26) to ensure cherry-pick
> wouldn't segfault when working with a dirty file involved in a rename.
>
> While the segfault was fixed,
Hi Elijah,
On Fri, 5 Jan 2018, Elijah Newren wrote:
> 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
>
On Fri, 2018-01-05 at 12:12 -0800, Bryan Turner wrote:
> On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey
> wrote:
> > Not sure if this is intended or a bug, but with the following
> > configuration:
> >
> > $ git config --global merge.ff false
> >
> > I am not able to merge my topic branch into
Hi Junio,
On Fri, 5 Jan 2018, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
> > git-rebase--interactive.sh | 9 ++---
> > t/t3418-rebase-continue.sh | 14 ++
> > 2 files changed, 20 insertions(+), 3 deletions(-)
> >
> > diff --git a/git-rebase--interactive.sh b/git-reb
Hi Matthew,
On Fri, 5 Jan 2018, Matthew Orres wrote:
> I'd be glad to give it a try - but am unfamiliar with how portable a
> manual build of Git can be used along side the version I have
> installed via Homebrew - do I just use full paths to reference the
> compiled executable from within my rep
Hi,
On Fri, 5 Jan 2018, Junio C Hamano wrote:
> Jeff King writes:
>
> > On Wed, Jan 03, 2018 at 02:42:51PM -0800, Isaac Shabtay wrote:
> >
> >> Indeed interesting... this one's for the books...
> >> Thanks for the patches. Any idea when these are going to make it to the
> >> official Git clien
On Fri, Jan 5, 2018 at 12:35 PM, Robert Dailey wrote:
> On Fri, Jan 5, 2018 at 2:26 PM, Paul Smith wrote:
>> On Fri, 2018-01-05 at 12:12 -0800, Bryan Turner wrote:
>>> On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey
>>> wrote:
>>>
>>> As for why the two aren't allowed together, my assumption wou
On Fri, Jan 05, 2018 at 12:45:03PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > Out of curiosity, did this change at some point? I thought the process
> > used to be to merge to maint, and then pick up topics in master by
> > merging maint to master.
>
> If you look at "Sync with main
Hi Ævar,
On Fri, 5 Jan 2018, Ævar Arnfjörð Bjarmason wrote:
> On Fri, Jan 05 2018, Johannes Schindelin jotted:
>
> > [...]
> >
> > In short: the Unix shell script t3070 manages to write what it thinks is a
> > file called 'foo*', but Git only sees 'foo'.
> >
> > I tried to address this problem w
Jeff King writes:
> Out of curiosity, did this change at some point? I thought the process
> used to be to merge to maint, and then pick up topics in master by
> merging maint to master.
If you look at "Sync with maint" merges made to 'master', you'd
notice that most of them are only updating Do
On Fri, Jan 05, 2018 at 09:22:07PM +0100, Johannes Schindelin wrote:
> On Fri, 5 Jan 2018, Isaac Shabtay wrote:
>
> > Done: https://github.com/git-for-windows/git/pull/1421
> >
> > I added credit to Jeff in the PR's description.
>
> Sadly, the PR's description won't make it into the commit hist
Johannes Schindelin writes:
> Hi Isaac,
>
> On Fri, 5 Jan 2018, Isaac Shabtay wrote:
>
>> Done: https://github.com/git-for-windows/git/pull/1421
>>
>> I added credit to Jeff in the PR's description.
>
> Sadly, the PR's description won't make it into the commit history, and the
> authorship reall
On Fri, Jan 5, 2018 at 2:26 PM, Paul Smith wrote:
> On Fri, 2018-01-05 at 12:12 -0800, Bryan Turner wrote:
>> On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey
>> wrote:
>> > Not sure if this is intended or a bug, but with the following
>> > configuration:
>> >
>> > $ git config --global merge.ff f
On Fri, Jan 5, 2018 at 12:31 PM, Thomas Gummerer wrote:
> On 01/04, Elijah Newren wrote:
>> On Wed, Jan 3, 2018 at 5:52 PM, SZEDER Gábor wrote:
>>
>> >> + test $(git rev-parse :0:y/b) = $(git rev-parse O:z/b) &&
>> >
>> > There is a test helper for that :)
>> >
>> > test_cmp_rev :0:
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 f36493289..239819f2d 100755
--- a/t/t6043-merge-rename-
Signed-off-by: Ramsay Jones
---
Hi Brandon,
If you need to re-roll your 'bw/protocol-v2' branch, could you please
squash this (or something like it) into the relevant patches. The first
hunk would go in commit 6ec1105192, "upload-pack: convert to a builtin",
2018-01-02), whereas the second hunk
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 c68ae87f1..f36493289 100755
--- a/t/t6043-merge-rename-
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
gains
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 5a2a4449d..d69d26951 100755
--- a/t/t6043-merge-rename-
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 239819f2d..c61ecb9b7 100755
--- a/t/t6043-merge-rename-
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 +++---
1 file change
Johannes Schindelin writes:
> git-rebase--interactive.sh | 9 ++---
> t/t3418-rebase-continue.sh | 14 ++
> 2 files changed, 20 insertions(+), 3 deletions(-)
>
> diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
> index e3f5a0abf3c..085aa068cbb 100644
> --- a/
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 | 86
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 re
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.
Signed-
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 f9d75c83c..dc3fc66e5 100755
--- a/t/t6043-merge-rename-
On 01/04, Elijah Newren wrote:
> On Wed, Jan 3, 2018 at 5:52 PM, SZEDER Gábor wrote:
>
> >> + test $(git rev-parse :0:y/b) = $(git rev-parse O:z/b) &&
> >
> > There is a test helper for that :)
> >
> > test_cmp_rev :0:y/b O:z/b
> >
> > Note, that this is not only a matter of useful
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 717cf1483..5a2a4449d 100755
--- a/t/t6043-merge-rename-
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 u
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
---
merge-recursive.
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 su
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.
Signed-of
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,
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
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 w
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 cdf8588c7..e77d2b043 100644
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 whic
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 importa
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 insertions(+), 3 deletions(-)
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 +++-
t/t6043-merg
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 | 35 +++
merge-recursive.h | 8
2 files changed, 43 insertions(+)
diff --git a/merge-
Signed-off-by: Elijah Newren
---
t/t6043-merge-rename-directories.sh | 442
1 file changed, 442 insertions(+)
create mode 100755 t/t6043-merge-rename-directories.sh
diff --git a/t/t6043-merge-rename-directories.sh
b/t/t6043-merge-rename-directories.sh
new f
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 2b8a5ca03..fe42cabad 100644
--- a/me
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 38ca791e9..470c9a79f 100755
--- a/t/t6043-merge-rename-
This patchset introduces directory rename detection to merge-recursive. See
https://public-inbox.org/git/20171110190550.27059-1-new...@gmail.com/
for the first series (including design considerations, etc.), and follow-up
series can be found at
https://public-inbox.org/git/20171120220209.15111
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
---
merge-recursive.c | 11 +
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
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 dc3fc66e5..38ca791e9 100755
--- a/t/t6043-merge-rename-
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 c61ecb9b7..f9d75c83c 100755
--- a/t/t6043-merge-rename-
I'd be glad to give it a try - but am unfamiliar with how portable a
manual build of Git can be used along side the version I have
installed via Homebrew - do I just use full paths to reference the
compiled executable from within my repository folder?
Thanks!
On Wed, Nov 1, 2017 at 5:58 PM, Johan
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 overlo
These three patches were the first three from
en/rename-directory-detection[1], but as Stefan suggested[2], I'm submitting
them separately as they are independent fixes.
Change from PATCHv5-rename-directory-detection:
* Split from the rest of the series.
* Added Stefan's Reviewed-By.
[1] http
Hi Isaac,
On Fri, 5 Jan 2018, Isaac Shabtay wrote:
> Done: https://github.com/git-for-windows/git/pull/1421
>
> I added credit to Jeff in the PR's description.
Sadly, the PR's description won't make it into the commit history, and the
authorship really should have been retained.
I found Peff's
t3501 had a testcase originally added in 05f2dfb965 (cherry-pick:
demonstrate a segmentation fault, 2016-11-26) 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 g
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.
Reviewed-By: Stefan Beller
Signed-o
Matthieu Moy writes:
> Alex Bennée writes:
>
>> I think you need to apply Eric's suggestions from:
>>
>> From: Eric Sunshine
>> Date: Sat, 18 Nov 2017 21:54:46 -0500
>> Message-ID:
>>
>
> Indeed. I'm squashing this into the patch:
>
> diff --git a/t/t9001-send-email.sh b/t/t9001-send-em
On Fri, Jan 5, 2018 at 11:59 AM, Robert Dailey wrote:
> Not sure if this is intended or a bug, but with the following configuration:
>
> $ git config --global merge.ff false
>
> I am not able to merge my topic branch into master with squash option:
>
> $ git checkout master
> $ git merge --squash
Martin Fick writes:
> These scenarios seem to come up most for me at Gerrit hack-
> a-thons where we collaborate a lot in short time spans on
> changes. We (the Gerrit maintainers) too have wanted and
> sometimes discussed ways to track the relation of "amended"
> commits (which is generally
When there is a one way merge, each submodule needs to be one way merged
as well, if we're asked to recurse into submodules.
In case of a submodule, check if it is up-to-date, otherwise set the
flag CE_UPDATE, which will trigger an update of it in the phase updating
the tree later.
Signed-off-by:
When using hard reset or forced checkout with the option to recurse into
submodules, the submodules need to be reset, too.
It turns out that we need to omit the duplicate old argument to read-tree
in all forced cases to omit the 2 way merge and use the more assertive
behavior of reading the specif
It turns out that the test replacing a submodule with a file with
the submodule containing an ignored file is incorrectly titled,
because the test put the file in place, but never ignored that file.
When having an untracked file Instead of an ignored file in the
submodule, git should refuse to remo
Keep the local branch name as the upstream branch name to avoid confusion.
Signed-off-by: Stefan Beller
Signed-off-by: Junio C Hamano
---
t/lib-submodule-update.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/lib-submodule-update.sh b/t/lib-submodule-update.sh
index
v4:
* dropped the patch "t/helper/test-lazy-name-hash: fix compilation"
(that snuck into v3 by accident, it is already present at
remotes/origin/jh/memihash-opt, but I am carrying it locally in
most branches currently.)
* Junio pointed out the micro-optimisation below, both in terms of read
On 12/18, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > Ah interesting, what you have below looks good to me indeed, it
> > matches what I'd expect it to do and fixes the bug that was reported.
> > Thanks!
> >
> > I've taken the liberty to take what you have below and turned into a
> > p
Not sure if this is intended or a bug, but with the following configuration:
$ git config --global merge.ff false
I am not able to merge my topic branch into master with squash option:
$ git checkout master
$ git merge --squash topic
fatal: You cannot combine --squash with --no-ff.
I'm not sure
On Fri, Jan 05, 2018 at 11:53:50AM -0800, Junio C Hamano wrote:
> > They haven't even been reviewed yet. If they get good feedback, then the
> > maintainer will pick them up, then merge them to 'next', and then
> > eventually to 'master', after which they'd become part of the next
> > major releas
Jeff Hostetler writes:
> I kinda trying to serve 2 masters here. As we discussed earlier, we
> don't want config options to change porcelain formats, hence the
> true/false thing only affecting non-porcelain formats. On the other
> hand, VS and git.exe are on different release schedules. Norma
Jeff King writes:
> On Wed, Jan 03, 2018 at 02:42:51PM -0800, Isaac Shabtay wrote:
>
>> Indeed interesting... this one's for the books...
>> Thanks for the patches. Any idea when these are going to make it to the
>> official Git client builds? (specifically the Windows one)
>
> They haven't even
1 - 100 of 137 matches
Mail list logo
