Johannes Schindelin writes:
>> If we are talking about a drastic change, a few more days may not be
>> sufficient, but we are not in a hurry, as this already sounds like a
>> 2.18 material anyway.
>
> It is not at all a drastic change. It will actually make the current patch
> series better (simp
Johannes Schindelin writes:
>> Non-textual semantic conflicts are made (in the best case just once)
>> as a separate commit on top of mechanical auto-merge whose focus is
>> predictability (rather than cleverness) done by Git, and then that
>> separate commit is kept outside the history. When re
Tôi là shaye Lynne Haver
đến từ Mỹ
tôi muốn giao tiếp
với bạn. Trân trọng,
Shaye
---
I am shaye Lynne Haver
from the United States
i wish to communicate
with you. Sincerely,
Shaye
On Wed, Mar 07 2018, Johannes Schindelin jotted:
> Hi Dan,
>
> On Tue, 6 Mar 2018, Junio C Hamano wrote:
>
>> * dj/runtime-prefix (2017-12-05) 4 commits
>> . exec_cmd: RUNTIME_PREFIX on some POSIX systems
>> . Makefile: add Perl runtime prefix support
>> . Makefile: add support for "perllibdir
On Tue, Mar 06 2018, Michele Locati jotted:
> Recent versions of git filter-branch command introduced the --state-branch
> option.
> BTW I can't find any info about how this can be actually used.
>
> We have this repository on github:
> https://github.com/concrete5/concrete5
>
> When someone push
On Wed, Mar 07 2018, Dorab Patel jotted:
> Thanks for updating us with the status of git.el.
>
> The last time I looked at magit, it was too heavyweight for my needs.
> I like the simplicity of git.el. But perhaps it's time for me to take
> another look at magit.
You can also check out the VC mo
The git-blame.el mode has been superseded by Emacs's own
vc-annotate (invoked by C-x v g). Users of the git.el mode are now
much better off using either Magit or the Git backend for Emacs's own
VC mode.
These modes were added over 10 years ago when Emacs's own Git support
was much less mature, and
Currently C# async methods are not shown in diff hunk headers. I just
added the async keyword to the csharp method pattern so that they are
properly detected.
---
userdiff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/userdiff.c b/userdiff.c
index dbfb4e13cddce..b92caf42b27
On Thu, 2018-03-08 at 10:25 +0100, Ævar Arnfjörð Bjarmason wrote:
> > The first filter-branch call required 7168 steps, so did the second call...
> > I also tried without the --prune option of remote update (I had to add
> > --force to the second filter-branch), but nothing changed.
You can see a
On Thu, Mar 8, 2018 at 5:04 AM, Thomas Levesque
wrote:
> Currently C# async methods are not shown in diff hunk headers. I just
> added the async keyword to the csharp method pattern so that they are
> properly detected.
Thanks for the contribution. Please sign-off your patch (see
SubmittingPatche
Tas ir, lai informētu jūs, ka Ekofast finansē aizdevumus gan vecajiem,
gan jaunajiem klientiem, kuru minimālais diapazons ir 10 000,00 eiro un
maksimāli 10 000 000 eiro. Vai jums ir kādas finansiālas grūtības? Vai
jūs meklējat likumīgu aizdevumu? Noguris, meklējot aizdevumus un
hipotēkas? Vai j
Currently C# async methods are not shown in diff hunk headers. I just
added the async keyword to the csharp method pattern so that they are
properly detected.
Signed-off-by: Thomas Levesque
---
userdiff.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/userdiff.c b/userdiff.c
On 06/03/18 19:57, Junio C Hamano wrote:
> Phillip Wood writes:
>
>> From: Phillip Wood
>>
>> If the list of lines to be selected begins with '^' select all the
>> lines except the ones listed.
>
> There is "# Input that begins with '-'; unchoose" in list_and_choose
> helper. Does it make thin
On 06/03/18 18:12, Johannes Schindelin wrote:
> Hi Phillip,
>
> On Tue, 6 Mar 2018, Phillip Wood wrote:
>
>> On 03/03/18 00:29, Igor Djordjevic wrote:
>>>
>>> On 02/03/2018 12:31, Phillip Wood wrote:
> Thinking about it overnight, I now suspect that original proposal
> had a mistake
On 07/03/18 07:26, Johannes Schindelin wrote:
> Hi Buga,
>
> On Tue, 6 Mar 2018, Igor Djordjevic wrote:
>
>> On 06/03/2018 19:12, Johannes Schindelin wrote:
>>>
> And I guess being consistent is pretty important, too - if you add new
> content during merge rebase, it should always show up
This saves 8 bytes in sizeof(struct object_entry). On a large
repository like linux-2.6.git (6.5M objects), this saves us 52MB
memory.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 14 --
cache.h| 2 ++
object.h | 1 -
pack-objects.h
Notice that packing_data::nr_objects is uint32_t, we could only handle
maximum 4G objects and can address all of them with an uint32_t. If we
use a pointer here, we waste 4 bytes on 64 bit architecture.
Convert these delta pointers to indexes. Since we need to handle NULL
pointers as well, the ind
Instead of using 8 bytes (on 64 bit arch) to store a pointer to a
pack. Use an index isntead since the number of packs should be
relatively small.
This limits the number of packs we can handle to 16k. For now if you hit
16k pack files limit, pack-objects will simply fail [1].
This technically sav
The role of this comment block becomes more important after we shuffle
fields around to shrink this struct. It will be much harder to see what
field is related to what. This also documents the holes in this struct
according to pahole.
A couple of notes on shrinking the struct:
1) The reader may n
This does not give us any saving due to padding. But we will be able
to save once we cut 4 bytes out of this struct in a subsequent patch.
Because of struct packing from now on we can only handle max depth
4095 (or even lower when new booleans are added in this struct). This
should be ok since lon
This field is only need for pack-bitmap, which is an optional
feature. Move it to a separate array that is only allocated when
pack-bitmap is used (it's not freed in the same way that objects[] is
not). This saves us 8 bytes in struct object_entry.
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin
We only cache deltas when it's smaller than a certain limit. This limit
defaults to 1000 but save its compressed length in a 64-bit field.
Shrink that field down to 16 bits, so you can only cache 65kb deltas.
Larger deltas must be recomputed at when the pack is written down.
This saves us 8 bytes
v3 cleans up a bit to avoid the horrible macros that v2 adds, and
adds some more documentation for this struct since it's getting harder
to just look at the struct and see what field is related to what.
v3 also adds three more patches and reduces another 16 bytes (total
struct reduction now is 41%
Signed-off-by: Nguyễn Thái Ngọc Duy
---
builtin/pack-objects.c | 3 +++
pack-objects.h | 33 -
2 files changed, 23 insertions(+), 13 deletions(-)
diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c
index fd217cb51f..a4dbb40824 100644
--- a/builti
Signed-off-by: Nguyễn Thái Ngọc Duy
---
pack-objects.h | 6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git a/pack-objects.h b/pack-objects.h
index 1c0ad4c9ef..3c15cf7b23 100644
--- a/pack-objects.h
+++ b/pack-objects.h
@@ -77,12 +77,10 @@ struct object_entry {
uint32_t
Allowing a delta size of 64 bits is crazy. Shrink this field down to
31 bits with one overflow bit.
If we encounter an existing delta larger than 2GB, we do not cache
delta_size at all and will get the value from oe_size(), potentially
from disk if it's larger than 4GB.
Signed-off-by: Nguyễn Thái
It's very very rare that an uncompressd object is larger than
4GB (partly because Git does not handle those large files very well to
begin with). Let's optimize it for the common case where object size is
smaller than this limit.
Shrink size field down to 32 bits [1] and one overflow bit. If the s
Object header in a pack is packed really tight (see
pack-format.txt). Even with 8 bytes length, we need 9-10 bytes most,
plus a hash (20 bytes). Which means this field only needs to store a
number as big as 32 (5 bits).
This is trickier to pack tight though since a new hash algorithm is
coming, th
In repository having large number of refs, lstat for non-existing loose
objects makes `git fetch` slow.
This patch stores existing loose objects in hashmap beforehand and use
it to check existence instead of using lstat.
With this patch, the number of lstat calls in `git fetch` is reduced
from 41
On 08/03/18 11:20, Phillip Wood wrote:
> On 07/03/18 07:26, Johannes Schindelin wrote:
>> Hi Buga,
>>
>> On Tue, 6 Mar 2018, Igor Djordjevic wrote:
>>
>>> On 06/03/2018 19:12, Johannes Schindelin wrote:
>> And I guess being consistent is pretty important, too - if you add new
>> conten
> Adds testcases dealing with file collisions for the following types of
> conflicts:
> * add/add
> * rename/add
> * rename/rename(2to1)
> These tests include expectations for proposed smarter behavior which has
> not yet been implemented and thus are currently expected to fail.
> Subsequent
> On Sat, Feb 24, 2018 at 12:39 AM, SZEDER Gábor wrote:
> > This patch series makes '-x' tracing of tests work reliably even when
> > running them with /bin/sh, and setting TEST_SHELL_PATH=bash will be
> > unnecessary.
> >
> > make GIT_TEST_OPTS='-x --verbose-log' test
> >
> > passes on my setup
Four 'cvs diff' related tests in 't9402-git-cvsserver-refs.sh' fail
when the test script is run with '-x' tracing (and using a shell other
than a Bash version supporting BASH_XTRACEFD). The reason for those
failures is that the tests check the emptiness of a subshell's stderr,
which includes the t
The test 'cvs update (-p)' redirects and checks 'test_cmp's stdout and
even its stderr. The commit introducing this test in 6e8937a084
(cvsserver: Add test for update -p, 2008-03-27) doesn't discuss why,
in fact its log message only consists of that subject line. Anyway,
weird as it is, it kind o
> It would be great to have this rebooted now that my perl cleanup efforts
> have un-blocked this. Will be happy to help review & test the next
> iteration.
Yes, I was just thinking the same thing. I wanted to make sure the Perl
changes had landed, and I'm pleased to see that they have. I should h
> But stepping back a bit, why do you even need stash save/pop around
> "checkout -b new-feature-branch" (that implicitly branches at the
> tip) in the first place?
Sorry about that, I meant something like
git stash && git checkout develop && git pull && git checkout -b
new-feature-branch && g
Add a mention of the security mailing list to the "Reporting Bugs"
section. There's a mention of this list at
https://git-scm.com/community but none in git.git itself.
The copy is pasted from the git-scm.com website. Let's use the same
wording in both places.
Signed-off-by: Ævar Arnfjörð Bjarmaso
Hi Dscho,
On 07/03/2018 08:26, Johannes Schindelin wrote:
>
> > So, it could be something like:
> >
> > merge -C deadbee 123abc:cafecafe 234bcd:bedbedbed
>
> I like where this is heading, too, but I do not think that we can do this
> on a per-MERGE_HEAD basis. The vast majority of merge comm
Hi,
Just to let you know, I get the following error compiling Git in master
branch:
$ make prefix=/usr NO_GETTEXT=YesPlease all doc info
...
GEN git-remote-testgit
GEN perl/build/man/man3/Git.3pm
Can't write-open perl/build/man/man3/Git.3pm: Permission denied at
/usr/bin/pod2man line 70
Hi Phillip and Johannes,
On 08/03/2018 12:20, Phillip Wood wrote:
>
> I did wonder about using 'pick ' for rebasing merges and
> keeping 'merge ...' for recreating them but I'm not sure if that is a
> good idea. It has the advantage that the user cannot specify the wrong
> parents for the merge
I'm on Windows and core.ignorecase is set to 'true' when I clone/init
a repository. I've got a branch where I started making changes to a
file AND renamed it only to change its case. The changes I've made
were significant enough that git no longer detects a rename, instead
the files show up as "D"
On 08/03/2018 13:16, Phillip Wood wrote:
>
> > Side note: I wonder whether we really need to perform the additional check
> > that ensures that the refers to the rewritten version of the
> > original merge commit's parent.
> >
> > [...]
>
> Oops that was referring to the first side note. I thin
On Thu, Mar 8, 2018 at 3:20 AM, Phillip Wood wrote:
> On 07/03/18 07:26, Johannes Schindelin wrote:
>> Hi Buga,
>>
>> On Tue, 6 Mar 2018, Igor Djordjevic wrote:
>>
>>> On 06/03/2018 19:12, Johannes Schindelin wrote:
>> And I guess being consistent is pretty important, too - if you add new
> Just to let you know, I get the following error compiling Git in master
> branch:
>
> $ make prefix=/usr NO_GETTEXT=YesPlease all doc info
> ...
> GEN git-remote-testgit
> GEN perl/build/man/man3/Git.3pm
> Can't write-open perl/build/man/man3/Git.3pm: Permission denied at
> /usr/bin/p
On 08/03/2018 16:16, Igor Djordjevic wrote:
>
> > Unless we reimplement the octopus merge (which works quite a bit
> > differently from the "rebase merge commit" strategy, even if it is
> > incremental, too), which has its own challenges: if there are merge
> > conflicts before merging the last ME
On 08/03/18 13:17, SZEDER Gábor wrote:
Just to let you know, I get the following error compiling Git in master
branch:
$ make prefix=/usr NO_GETTEXT=YesPlease all doc info
...
GEN git-remote-testgit
GEN perl/build/man/man3/Git.3pm
Can't write-open perl/build/man/man3/Git.3pm: Permiss
On 06/03/2018 12:45, Sergey Organov wrote:
>
> > > The only thing I wonder of here is how would we check if the
> > > "rebased" merge M' was "clean", or should we stop for user amendment?
> > > With that other approach Sergey described, we have U1'==U2' to test with.
> >
> > I think (though I ha
Am 08.03.2018 um 13:06 schrieb Takuto Ikuta:
> In repository having large number of refs, lstat for non-existing loose
> objects makes `git fetch` slow.
>
> This patch stores existing loose objects in hashmap beforehand and use
> it to check existence instead of using lstat.
>
> With this patch,
Ævar Arnfjörð Bjarmason writes:
> On Tue, Mar 06 2018, Alexandre Julliard jotted:
> ...
>> I'd recommend that anybody still using it switch to Magit, which is
>> being actively maintained, and IMO superior to git.el in all respects.
>
> I think at this point it's best to remove both of these mod
Sweet! Thanks for taking a look, and for spotting lots of
improvements (and some really embarrassing errors). I'll keep the
fixes queued up while waiting for other feedback. A few comments...
On Thu, Mar 8, 2018 at 4:25 AM, SZEDER Gábor wrote:
> This setup test is enormous, and the conditions
Phillip Wood writes:
> and use a leading '-' for inversion. I'm tempted to keep supporting 'n-'
> to mean everything from 'n' to the last line though.
Thanks for double checking. It would be a better endgame to follow
up with an update to existing "range selection" code to also support
"n-", if
Ævar Arnfjörð Bjarmason writes:
[...]
> These days these modes have very few if users, and users of git aren't
s/if// or s/if/if any/ ?
--
Kyle
Takuto Ikuta writes:
> In repository having large number of refs, lstat for non-existing loose
> objects makes `git fetch` slow.
It is not immediately clear how "large number of refs" and "lstat
for loose objects" interact with each other to create a problem.
"In repository having large number o
On Thu, Mar 8, 2018 at 7:38 AM, SZEDER Gábor wrote:
> The test 'cvs update (-p)' redirects and checks 'test_cmp's stdout and
> even its stderr. The commit introducing this test in 6e8937a084
> (cvsserver: Add test for update -p, 2008-03-27) doesn't discuss why,
> in fact its log message only cons
Hi Paul-Sebastian
On 6 March 2018 at 20:31, Paul-Sebastian Ungureanu
wrote:
> Usually, the usage should be shown only if the user does not know what
> options are available. If the user specifies an invalid value, the user
> is already aware of the available options. In this case, there is no
> p
2018-03-06 22:21 GMT+02:00 Jonathan Nieder :
>
> (cc list snipped)
> Hi,
>
> Eddy Petrișor wrote:
>
> > Cc: [a lot of people]
>
> Can you say a little about how this cc list was created? E.g. should
> "git send-email" get a feature to warn about long cc lists?
I did it as advised by the documen
Ævar Arnfjörð Bjarmason writes:
> Add a mention of the security mailing list to the "Reporting Bugs"
> section. There's a mention of this list at
> https://git-scm.com/community but none in git.git itself.
This is quite a sensible thing to do.
>
> The copy is pasted from the git-scm.com websit
2018-03-08 21:29 GMT+02:00 Eddy Petrișor :
> 2018-03-06 22:21 GMT+02:00 Jonathan Nieder :
>>
>> (cc list snipped)
>> Hi,
>>
>> Eddy Petrișor wrote:
>>
>> > Cc: [a lot of people]
>>
>> Can you say a little about how this cc list was created? E.g. should
>> "git send-email" get a feature to warn abo
Hello,
I came across an odd behavior in Git related to case sensitivity when
deleting a checked out branch.
I was not able to find much information about it.
$ git checkout -b foo
$ git branch -d foo # error: Cannot delete branch 'foo' checked
out => this is expected, nothing happens si
Hi Johannes,
On 07/03/2018 15:08, Johannes Schindelin wrote:
>
> > > Didn't we settle on Phillip's "perform successive three-way merges
> > > between the original merge commit and the new tips with the old tips
> > > as base" strategy?
> >
> > It seems you did, dunno exactly why.
>
> That is not
On 08/03/2018 20:58, Igor Djordjevic wrote:
>
> git merge-recursive U1' -- M U2'
> tree="$(git write-tree)"
> # in case of original merge being octopus, we would continue like:
> # git merge-recursive $tree -- M U3'
> # tree="$(git write-tree)"
> # git merge-rec
Hi,
Jaben reports that git-send-email is suddenly failing to expand the
"*.patch" glob for him, at the Windows CMD prompt:
-
E:\...>git send-email --suppress-cc=author --suppress-cc=self
--suppress-cc=cc --suppress-cc=sob --dry-run *.patch
No patch files specified!
-
Whereas, mo
On Thu, Mar 8, 2018 at 7:51 PM, Eric Sunshine wrote:
> On Thu, Mar 8, 2018 at 7:38 AM, SZEDER Gábor wrote:
>> Unroll that for loop, so we can check the files' contents the usual
>> way and rely on 'test_cmp's exit code failing the && chain. Extract
>> updating a file via CVS and verifying its c
On Thu, Mar 8, 2018 at 4:49 PM, SZEDER Gábor wrote:
> On Thu, Mar 8, 2018 at 7:51 PM, Eric Sunshine wrote:
>> An alternative approach used elsewhere in the test suite[1] would be
>> simply to 'exit' if test_cmp fails:
>>
>> for i in merge no-lf empty really-empty; do
>> GIT_CONFIG="$g
+git-for-windows
Hi,
Laszlo Ersek wrote:
> Jaben reports that git-send-email is suddenly failing to expand the
> "*.patch" glob for him, at the Windows CMD prompt:
>
> -
> E:\...>git send-email --suppress-cc=author --suppress-cc=self
> --suppress-cc=cc --suppress-cc=sob --dry-run *.patch
On 08/03/2018 21:27, Igor Djordjevic wrote:
>
> > git merge-recursive U1' -- M U2'
> > tree="$(git write-tree)"
> > # in case of original merge being octopus, we would continue like:
> > # git merge-recursive $tree -- M U3'
> > # tree="$(git write-tree)"
> > # git merge-rec
On Thu, Mar 8, 2018 at 5:01 PM, Eric Sunshine wrote:
> Sorry for the confusion. I meant "return 1" as used elsewhere in the
> test suite[1].
> [1]: For example, the "setup" test of t4151-am-abort.sh.
Additional context: e6821d09e4 (t: fix some trivial cases of ignored
exit codes in loops, 2015-03
On Thu, Mar 8, 2018 at 11:01 PM, Eric Sunshine wrote:
> On Thu, Mar 8, 2018 at 4:49 PM, SZEDER Gábor wrote:
>> On Thu, Mar 8, 2018 at 7:51 PM, Eric Sunshine
>> wrote:
>>> An alternative approach used elsewhere in the test suite[1] would be
>>> simply to 'exit' if test_cmp fails:
>>>
>>> for
The test 'cvs update (-p)' redirects and checks 'test_cmp's stdout and
even its stderr. The commit introducing this test in 6e8937a084
(cvsserver: Add test for update -p, 2008-03-27) doesn't discuss why,
in fact its log message only consists of that subject line. Anyway,
weird as it is, it kind o
Hello dear,
I am Miss Rachel Jelani. I have very important thing to discuss with
you please, this information is very vital. Contact me with my
privarte email so we can talk ( rachelrachel...@hotmail.com )
Rachel.
Duy Nguyen writes:
>> extern int starts_with(const char *str, const char *prefix);
>> +extern int startscase_with(const char *str, const char *prefix);
>
> This name is a bit hard to read. Boost [1] goes with istarts_with. I
> wonder if it's better. If not I guess either starts_with_case or
> st
On 08/03/2018 20:58, Igor Djordjevic wrote:
>
> > Phillip's method is essentially merging the new tips into the original
> > merge, pretending that the new tips were not rebased but merged into
> > upstream.
>
> [...]
>
> Here`s a starting point, two commits A and B, merged into M:
>
> (3) ---A
} I had a few proposals over the years, but I won't even bother to dig
} them up, because there's quite recent and promising work in this
} area from Derrick Stolee:
It sounds like the best thing to do is to wait for this, then.
We managed to convert a bunch of our branches to tags, so our
immedi
SZEDER Gábor writes:
> diff --git a/t/t9400-git-cvsserver-server.sh b/t/t9400-git-cvsserver-server.sh
> index c30660d606..5ff3789199 100755
> --- a/t/t9400-git-cvsserver-server.sh
> +++ b/t/t9400-git-cvsserver-server.sh
> @@ -449,10 +449,9 @@ test_expect_success 'cvs update (-p)' '
> GIT_CON
On Fri, Mar 9, 2018 at 12:33 AM, Junio C Hamano wrote:
> SZEDER Gábor writes:
>
>> diff --git a/t/t9400-git-cvsserver-server.sh
>> b/t/t9400-git-cvsserver-server.sh
>> index c30660d606..5ff3789199 100755
>> --- a/t/t9400-git-cvsserver-server.sh
>> +++ b/t/t9400-git-cvsserver-server.sh
>> @@ -449
SZEDER Gábor writes:
> On Fri, Mar 9, 2018 at 12:33 AM, Junio C Hamano wrote:
>> SZEDER Gábor writes:
>>
>>> diff --git a/t/t9400-git-cvsserver-server.sh
>>> b/t/t9400-git-cvsserver-server.sh
>>> index c30660d606..5ff3789199 100755
>>> --- a/t/t9400-git-cvsserver-server.sh
>>> +++ b/t/t9400-gi
Use Case
==
Jeremy is a developer for Debian and Ubuntu. The same repository is
used for both Debian and Ubuntu packaging but with different branches.
For commits to the debian/master branch, Jeremy wants to use his
@debian.org email address. For commits to the ubuntu/master branch,
Jeremy want
On Thu, Mar 08, 2018 at 07:23:00PM -0500, Jeremy Bicha wrote:
> Use Case
> ==
> Jeremy is a developer for Debian and Ubuntu. The same repository is
> used for both Debian and Ubuntu packaging but with different branches.
> For commits to the debian/master branch, Jeremy wants to use his
> @debi
On 7 March 2018 at 00:34, Junio C Hamano wrote:
> * ma/config-page-only-in-list-mode (2018-02-21) 3 commits
> - config: change default of `pager.config` to "on"
> - config: respect `pager.config` in list/get-mode only
> - t7006: add tests for how git config paginates
>
> In a way similar to h
79 matches
Mail list logo
