On Sun, Oct 14, 2018 at 03:16:36AM +0100, Ramsay Jones wrote:
> diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
> index b059b86aee..3b5f2c38b3 100644
> --- a/builtin/pack-objects.c
> +++ b/builtin/pack-objects.c
> @@ -269,12 +269,12 @@ static void copy_pack_data(struct hashfile *f,
>
On 14/10/18 03:16, Ramsay Jones wrote:
>
>
> On 13/10/18 06:00, Torsten Bögershausen wrote:
>> []
>>> Neither v1 nor v2 of this patch compiles on 32 bit Linux; see
>>>
>>> https://travis-ci.org/git/git/jobs/440514375#L628
>>>
>>> The fixup patch below makes it compile on 32 bit and the test
On 13/10/18 06:00, Torsten Bögershausen wrote:
> []
>> Neither v1 nor v2 of this patch compiles on 32 bit Linux; see
>>
>> https://travis-ci.org/git/git/jobs/440514375#L628
>>
>> The fixup patch below makes it compile on 32 bit and the test suite
>> passes as well, but I didn't thoroughly
On 11 Oct 2018, at 06:08, Ævar Arnfjörð Bjarmason wrote:
>Our matching function comes from rsync originally, whose manpage says:
>
> use ’**’ to match anything, including slashes.
>
>I believe this is accurate as far as the implementation goes. You can
>also see the rather exhaustive tests
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
Add testcases dealing with file collisions for the following types of
conflicts:
* add/add
* rename/add
* rename/rename(2to1)
All these conflict types simplify down to two files "colliding"
and should thus be handled similarly. This means that rename/add and
rename/rename(2to1) conflicts
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
This RFC series depends on this series submitted yesterday:
https://public-inbox.org/git/20181012212551.7689-1-new...@gmail.com/
(which in turn depends on en/merge-cleanup in next).
Although this is an "update" to my previous RFC series from six months
ago:
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:
* Instead of storing files at collide_path~HEAD and
When a single file is renamed, it can also be modified, yielding the
possibility of that renamed file having content conflicts. If two
different such files are renamed into the same location, then two-way
merging those files may result in nested conflicts. Add a testcase that
makes sure we get
When we have a rename/rename(1to2) conflict, each of the renames can
collide with a file addition. Each of these rename/add conflicts suffered
from the same kinds of problems that normal rename/add suffered from.
Make the code use handle_file_conflicts() as well so that we get all the
same fixes
This results in no-net change of behavior, it simply ensures that all
file-collision conflict handling types are being handled the same by
calling the same function.
Signed-off-by: Elijah Newren
---
merge-recursive.c | 29 +
1 file changed, 21 insertions(+), 8
Ok,
my bad. I had a global pre-commit hook which had a lingering etckeeper command
for another repository.
Not quite sure why it only runs when commit has the '-a' option...
Thanks for pointing to the hooks possibility.
Naja Melan
Am 13.10.18 um 04:46 schrieb Jeff King:
But no, right before that we have this line:
offset -= win->offset;
So offset is in fact no longer its original meaning of "offset into the
packfile", but is now an offset of the specific request into the window
we found.
So I think it's
Sergey Andreenko writes:
> git.exe diff --numstat "C:\diff" "C:\base"
> ...
> output will be:
>
> 0 1 {iff => ase}/1.txt
>
> So (folder_name_length) symbols were cut from the path (“C:\\d” and “C:\\b”).
>
> Is any way to avoid that? I have checked several git versions
Hi, I am learning `builtin/branch.c`. I find that it will call `branch_get`
before create and [un]set upstream, and die with "no such branch" if failed.
but `branch_get` seems never fail, it is a get_or_create. Also, it was
confused that getting a branch before it has created.
builtin/branch.c
Hello,
I'm writing a remote helper and decided implement the `fetch` and `push`
capabilities,
but one thing still remains a mystery for me. Namely, is my helper supposed
to instantiate and pin git objects in `GIT_DIR` upon `fetch `?
In general I'm trying to determine how exactly I need to
Johannes Sixt writes:
> Am 12.10.18 um 08:33 schrieb Junio C Hamano:
>> "Derrick Stolee via GitGitGadget" writes:
>>> +struct topo_walk_info {};
>>> +
>>> +static void init_topo_walk(struct rev_info *revs)
>>> +{
>>> + struct topo_walk_info *info;
>>> + revs->topo_walk_info =
Lily Ballard writes:
> I haven’t checked any other commands that the glossary lists as
> taking pathspecs (except `git add`, which does properly list it as
> taking pathspecs), so I don’t know if any of the other commands
> incorrectly list themselves as taking files when they take
> pathspecs.
Jonathan Nieder writes:
> Josh Steadmon wrote:
>> On 2018.10.12 16:32, Jonathan Nieder wrote:
>>> Josh Steadmon wrote:
>
For now, I'm going to try adding an --allowed_versions flag for the
remote helpers, but if anyone has a better idea, let me know.
>>>
>>> I forgot to mention: the
Ævar Arnfjörð Bjarmason writes:
> Yeah, that's me :) I have some WIP gc cleanup, but want to sit on it a
> bit before I submit it to think about the best way to do things.
>
> So in the meantime I was sending out a few WIP bits that I expected
> could be reviewed stand-alone.
I dunno. Unless
Hello my dear.
Did you receive my email message to you? Please, get back to me ASAP as the
matter is becoming late. Expecting your urgent response.
Sean.
22 matches
Mail list logo
