On Fri, Feb 24, 2017 at 08:14:25PM +0700, Nguyễn Thái Ngọc Duy wrote:
> +static int include_condition_is_true(const char *cond, size_t cond_len)
> +{
> + /* no condition (i.e., "include.path") is always true */
> + if (!cond)
> + return 1;
> +
> + if (skip_prefix_mem(cond,
On Fri, Feb 24, 2017 at 09:46:17AM -0800, Junio C Hamano wrote:
> Duy Nguyen writes:
>
> >>> + if (skip_prefix_mem(cond, cond_len, "gitdir:", &cond, &cond_len))
> >>> + return include_by_gitdir(cond, cond_len, 0);
> >>> + else if (skip_prefix_mem(cond, cond_len, "gitdir/i:",
On Sun, Feb 26, 2017 at 01:13:59AM +, Jason Cooper wrote:
> On Fri, Feb 24, 2017 at 10:10:01PM -0800, Junio C Hamano wrote:
> > I was thinking we would need mixed mode support for smoother
> > transition, but it now seems to me that the approach to stratify the
> > history into old and new is
On Sat, Feb 25, 2017 at 5:08 AM, Philip Oakley wrote:
>> +Conditional includes
>> +
>> +
>> +You can include one config file from another conditionally by setting
>
>
> On first reading I thought this implied you can only have one `includeIf`
> within the config file.
> I think
On Sat, Feb 25, 2017 at 3:48 PM, Lars Schneider
wrote:
>
>> On 24 Feb 2017, at 18:29, Samuel Lijin wrote:
>>
>> It's worth noting that there seems to be a weird issue with scan-build
>> where it *will* generate a report for something locally, but won't do it
>> on Travis. See [2] for an example w
Hi Junio,
On Fri, Feb 24, 2017 at 10:10:01PM -0800, Junio C Hamano wrote:
> I was thinking we would need mixed mode support for smoother
> transition, but it now seems to me that the approach to stratify the
> history into old and new is workable.
As someone looking to deploy (and having previous
On Sat, Feb 25, 2017 at 11:35:27PM +0100, Lars Schneider wrote:
> > So we don't actually know how Git would behave in the face of a SHA-1
> > collision. It would be pretty easy to simulate it with something like:
> [...]
>
> That's a good idea! I wonder if it would make sense to setup an
> addit
Hi,
On Sat, Feb 25, 2017 at 01:31:32AM +0100, ankostis wrote:
> That is why I believe that some HASH (e.g. SHA-3) must be the blessed one.
> All git >= 3.x.x must support at least this one (for naming and
> cross-referencing between objects).
I would stress caution here. SHA3 has survived the NI
On 24 February 2017 at 18:23, Jason Cooper wrote:
> Hi Ian,
>
> On Fri, Feb 24, 2017 at 03:13:37PM +, Ian Jackson wrote:
>> Joey Hess writes ("SHA1 collisions found"):
>> > https://shattered.io/static/shattered.pdf
>> > https://freedom-to-tinker.com/2017/02/23/rip-sha-1/
>> >
>> > IIRC someone
> On 25 Feb 2017, at 23:31, Jeff King wrote:
>
> On Sat, Feb 25, 2017 at 10:48:52PM +0100, Lars Schneider wrote:
>
>>
>>> On 24 Feb 2017, at 18:29, Samuel Lijin wrote:
>>>
>>> Introduces the scan-build static code analysis tool from the Clang
>>> project to all Travis CI builds. Installs cla
> On 25 Feb 2017, at 00:06, Jeff King wrote:
>
> On Fri, Feb 24, 2017 at 11:47:46PM +0100, Jakub Narębski wrote:
>
>> I have just read on ArsTechnica[1] that while Git repository could be
>> corrupted (though this would require attackers to spend great amount
>> of resources creating their own
On Sat, Feb 25, 2017 at 10:48:52PM +0100, Lars Schneider wrote:
>
> > On 24 Feb 2017, at 18:29, Samuel Lijin wrote:
> >
> > Introduces the scan-build static code analysis tool from the Clang
> > project to all Travis CI builds. Installs clang (since scan-build
> > needs clang as a dependency) t
On Sat, Feb 25, 2017 at 02:26:56PM -0500, Jeff King wrote:
> On Sat, Feb 25, 2017 at 06:50:50PM +, brian m. carlson wrote:
>
> > > As long as the reader can tell from the format of object names
> > > stored in the "new object format" object from what era is being
> > > referred to in some way
On Sat, Feb 25, 2017 at 10:39:29PM +0100, René Scharfe wrote:
> > > + (len == 8 && !memcmp(field, "encoding", 8)));
> >
> > Unrelated, but this could probably be spelled with a macro and strlen()
> > to avoid the magic numbers. It would probably be measurably slower for a
> > compiler whi
> On 24 Feb 2017, at 18:29, Samuel Lijin wrote:
>
> Introduces the scan-build static code analysis tool from the Clang
> project to all Travis CI builds. Installs clang (since scan-build
> needs clang as a dependency) to make this possible (on macOS, also
> updates PATH to allow scan-build to be
Am 25.02.2017 um 21:15 schrieb Jeff King:
On Sat, Feb 25, 2017 at 08:27:40PM +0100, René Scharfe wrote:
Both standard_header_field() and excluded_header_field() check if
there's a space after the buffer that's handed to them. We already
check in the caller if that space is present. Don't both
Am 25.02.2017 um 11:13 schrieb Vegard Nossum:
For the patches in the added testcases, we were crashing with:
git-apply: apply.c:3665: check_preimage: Assertion `patch->is_new <= 0'
failed.
As it turns out, check_preimage() is prepared to handle these conditions,
so we can remove the assert
Am 25.02.2017 um 11:13 schrieb Vegard Nossum:
If we have a patch like the one in the new test-case, then we will
try to rename a non-existant empty file, i.e. patch->old_name will
be NULL. In this case, a NULL entry will be added to fn_table, which
is not allowed (a subsequent binary search will
[Re-sending, as I used an old address for Gábor on the original]
On Sat, Feb 25, 2017 at 07:12:38PM +, Robin H. Johnson wrote:
> TL;DR: git-clone ignores any fetch specs passed via --config.
I agree that this is a bug. There's some previous discussion and an RFC
patch from lat March (author
On Sat, Feb 25, 2017 at 11:02:28AM +0100, René Scharfe wrote:
> If a pack entry that's used as a delta base is corrupt, unpack_entry()
> marks it as unusable and then searches the object again in the hope that
> it can be found in another pack or in a loose file. The memory for this
> external ba
Now that we have stash_push, which accepts pathspec arguments, use
it instead of stash_save in git stash without any additional verbs.
Previously we allowed git stash -- -message, which is no longer allowed
after this patch. Messages starting with a hyphen was allowed since
3c2eb80f, ("stash: sim
While working on a repository, it's often helpful to stash the changes
of a single or multiple files, and leave others alone. Unfortunately
git currently offers no such option. git stash -p can be used to work
around this, but it's often impractical when there are a lot of changes
over multiple f
Introduce a new git stash push verb in addition to git stash save. The
push verb is used to transition from the current command line arguments
to a more conventional way, in which the message is given as an argument
to the -m option.
This allows us to have pathspecs at the end of the command line
Thanks Junio for more comments on the last round, and Peff for reading
through it as well.
Changes since v6:
- If no --include-untracked option is given to git stash push, and a
pathspec is not in the repository, error out instead of ignoring
it. This brings it in line with things like check
Now that stash_push is used in the no verb form of stash, allow
specifying the command line for this form as well. Always use -- to
disambiguate pathspecs from other non-option arguments.
Also make git stash -p an alias for git stash push -p. This allows
users to use git stash -p .
Signed-off-b
Refactor the internal stash_create function to use a -m flag for
specifying the message and -u flag to indicate whether untracked files
should be added to the stash.
This makes it easier to pass a pathspec argument to stash_create in the
next patch.
The user interface for git stash create stays t
Currently there is no test showing the expected behaviour of git stash
create's command line arguments. Add a test for that to show the
current expected behaviour and to make sure future refactorings don't
break those expectations.
Signed-off-by: Thomas Gummerer
---
t/t3903-stash.sh | 18 ++
On Sat, Feb 25, 2017 at 07:12:38PM +, Robin H. Johnson wrote:
> TL;DR: git-clone ignores any fetch specs passed via --config.
I agree that this is a bug. There's some previous discussion and an RFC
patch from lat March (author cc'd):
http://public-inbox.org/git/1457313062-10073-1-git-send
On Sat, Feb 25, 2017 at 08:27:40PM +0100, René Scharfe wrote:
> Both standard_header_field() and excluded_header_field() check if
> there's a space after the buffer that's handed to them. We already
> check in the caller if that space is present. Don't bother calling
> the functions if it's miss
On Sat, Feb 25, 2017 at 08:21:52PM +0100, René Scharfe wrote:
> Search for a space character only within the current line in
> read_commit_extra_header_lines() instead of searching in the whole
> buffer (and possibly beyond, if it's not NUL-terminated) and then
> discarding any results after the e
On Sat, Feb 25, 2017 at 05:00:33PM +0100, René Scharfe wrote:
> Add a function for appending the canonized absolute pathname of a given
> path to a strbuf. It keeps the existing contents intact, as expected of
> a function of the strbuf_add() family, while avoiding copying the result
> if the giv
Both standard_header_field() and excluded_header_field() check if
there's a space after the buffer that's handed to them. We already
check in the caller if that space is present. Don't bother calling
the functions if it's missing, as they are guaranteed to return 0 in
that case, and remove the no
On Sat, Feb 25, 2017 at 06:50:50PM +, brian m. carlson wrote:
> > As long as the reader can tell from the format of object names
> > stored in the "new object format" object from what era is being
> > referred to in some way [*1*], we can name new objects with only new
> > hash, I would think.
On 02/21, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > - git reset --hard ${GIT_QUIET:+-q}
>
> This hunk is probably the most important one to review in the whole
> series, in the sense that these are entirely new code that didn't
> exist in the original.
>
> > + if
Search for a space character only within the current line in
read_commit_extra_header_lines() instead of searching in the whole
buffer (and possibly beyond, if it's not NUL-terminated) and then
discarding any results after the end of the current line.
Signed-off-by: Rene Scharfe
---
commit.c | 4
On Sat, Feb 25, 2017 at 12:48:54PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 22 Feb 2017, Jeff King wrote:
>
> > [two beautiful patches]
>
> I applied them and verified that the reported issue is fixed. Thank you!
>
> Hopefully you do not mind that I cherry-picked them in preparation
This variable needs to be specified to make some types of
non-basic authentication work, but ideally this would just
work out of the box for everyone.
However, simply setting it to "1" by default introduces an
extra round-trip for cases where it _isn't_ useful. We end
up sending a bogus empty cred
TL;DR: git-clone ignores any fetch specs passed via --config.
The documentation for git-clone --config says:
| Set a configuration variable in the newly-created repository; this takes
| effect immediately __AFTER__ the repository is initialized, but __BEFORE__
| the remote history is fetched or an
On Fri, Feb 24, 2017 at 04:42:38PM +0700, Duy Nguyen wrote:
> On Thu, Feb 23, 2017 at 11:43 PM, Joey Hess wrote:
> > IIRC someone has been working on parameterizing git's SHA1 assumptions
> > so a repository could eventually use a more secure hash. How far has
> > that gotten? There are still many
On Fri, Feb 24, 2017 at 09:32:13AM -0800, Junio C Hamano wrote:
> Ian Jackson writes:
>
> > I have been thinking about how to do a transition from SHA1 to another
> > hash function.
>
> Good. I think many of us have also been, too, not necessarily just
> in the past few days in response to shat
MIME-Version: 1.0
Fcc: Sent
Dear Git users,
It is my pleasure to announce that Git for Windows 2.12.0 is available from:
https://git-for-windows.github.io/
Changes since Git for Windows v2.11.1 (February 3rd 2017)
New Features
• Comes with Git v2.12.0.
• The builtin difftool is n
Add a function for appending the canonized absolute pathname of a given
path to a strbuf. It keeps the existing contents intact, as expected of
a function of the strbuf_add() family, while avoiding copying the result
if the given strbuf is empty. It's more consistent with the rest of the
strbuf A
On Monday 20 February 2017 at 13:25:01 -0800, Junio C Hamano wrote:
> This almost makes me suspect that the place that checks lengths of
> one and two in order to refrain from running more expensive content
> comparison you found earlier need to ask would_convert_to_git()
> before taking the short-
On 02/20, Junio C Hamano wrote:
> Thomas Gummerer writes:
>
> > @@ -55,10 +53,13 @@ push [-p|--patch] [-k|--[no-]keep-index]
> > [-u|--include-untracked] [-a|--all] [-q
> >
> > Save your local modifications to a new 'stash', and run `git reset
> > --hard` to revert them. The part is
Selamlarım sana
Ben çavuşum. Rachel Washburn, umarım hepiniz iyi olur. Birleşmiş Milletler
barış muhafızları Afganistan'da terörle savaş için çalışmadan önce kadın bir
askerim ancak geçen yıl Eylül 2016'da askeri yönetim devrilmesine karşı özel
görev yapmak üzere Burkina Faso'ya taşındı. Afgani
for more details,contact me at my private email : agaddafi752(at)gmail.
com
Dr. Aisha Gaddafi, the daughter of late Libyan president, I need a
partner or an investor that will help me in investing the sum of $87.5
million USD in his or her country, the funds is deposited here in
Burkina Faso whe
From: "Vegard Nossum"
On 25/02/2017 12:59, Philip Oakley wrote:
From: "Vegard Nossum"
If we have a patch like the one in the new test-case, then we will
"the one in the new test-case" needs a clearer reference to the
particular case so that future readers will know what it refers to.
Notice
Hi Peff & Junio,
On Fri, 24 Feb 2017, Jeff King wrote:
> On Fri, Feb 24, 2017 at 11:51:22AM -0800, Junio C Hamano wrote:
>
> > > A slightly worse is that the upcoming Git will ship with a rewritten
> > > "difftool" that makes the above sequence segfault.
> >
> > The culprit seems to be these li
On 25/02/2017 12:59, Philip Oakley wrote:
From: "Vegard Nossum"
If we have a patch like the one in the new test-case, then we will
"the one in the new test-case" needs a clearer reference to the
particular case so that future readers will know what it refers to.
Noticed while browsing the com
From: "Vegard Nossum"
If we have a patch like the one in the new test-case, then we will
"the one in the new test-case" needs a clearer reference to the particular
case so that future readers will know what it refers to. Noticed while
browsing the commit message..
..reads further; Maybe it
Hi Peff,
On Thu, 23 Feb 2017, Jeff King wrote:
> For Git for Windows, [PATCH 2/2] seems like the auto behavior would be a
> strict improvement over the "true" default they've been shipping.
Absolutely. Thank you for your tremendous help!
Ciao,
Dscho
Hi,
On Wed, 22 Feb 2017, Jeff King wrote:
> [two beautiful patches]
I applied them and verified that the reported issue is fixed. Thank you!
Hopefully you do not mind that I cherry-picked them in preparation for
Git for Windows v2.12.0?
I added a small fixup (https://github.com/dscho/git/commi
Add a semantic patch for using ALLOC_ARRAY to allocate arrays and apply
the transformation on the current source tree. The macro checks for
multiplication overflow and infers the element size automatically; the
result is shorter and safer code.
Signed-off-by: Rene Scharfe
---
contrib/coccinelle
If we have a patch like the one in the new test-case, then we will
try to rename a non-existant empty file, i.e. patch->old_name will
be NULL. In this case, a NULL entry will be added to fn_table, which
is not allowed (a subsequent binary search will die with a NULL
pointer dereference).
The patch
Dear Git group,
I use Git at a web hosting service, where my user account has a memory
limit of 768 MB:
(uiserver):p7715773:~$ uname -a
Linux infongp-de15 3.14.0-ui16322-uiabi1-infong-amd64 #1 SMP Debian
3.14.79-2~ui80+4 (2016-11-17) x86_64 GNU/Linux
(uiserver):p7715773:~$ git --version
git
For the patches in the added testcases, we were crashing with:
git-apply: apply.c:3665: check_preimage: Assertion `patch->is_new <= 0'
failed.
As it turns out, check_preimage() is prepared to handle these conditions,
so we can remove the assertion.
Found using AFL.
Signed-off-by: Vegard No
This test just checks that old clients can clone and fetch
from a newer git-daemon. The opposite should also be true,
but it's hard to test ancient versions of git-daemon because
they lack basic options like "--listen".
Note that we have to make a slight tweak to the
lib-git-daemon helper from the
If a pack entry that's used as a delta base is corrupt, unpack_entry()
marks it as unusable and then searches the object again in the hope that
it can be found in another pack or in a loose file. The memory for this
external base object is never released. Free it after use.
Signed-off-by: Rene S
The current test suite is good at letting you test a
particular version of Git. But it's not very good at letting
you test _two_ versions and seeing how they interact (e.g.,
one cloning from the other).
This commit adds a test harness that will build two
arbitrary versions of git and make it easy
This series adds a small test harness for interoperability tests. The
heavy lifting is done by the normal test-lib.sh; this just makes it easy
for you to have access to two git versions at the same time.
This is something I've wanted a few times in the past when we make a
fix that can only be test
On Sat, Feb 25, 2017 at 12:31:21AM -0800, Junio C Hamano wrote:
> Willy Tarreau writes:
>
> > Hi Junio,
> >
> > On Fri, Feb 24, 2017 at 11:28:58AM -0800, Junio C Hamano wrote:
> >> * Use of an empty string that is used for 'everything matches' is
> >>still warned and Git asks users to use a
Willy Tarreau writes:
> Hi Junio,
>
> On Fri, Feb 24, 2017 at 11:28:58AM -0800, Junio C Hamano wrote:
>> * Use of an empty string that is used for 'everything matches' is
>>still warned and Git asks users to use a more explicit '.' for that
>>instead. The hope is that existing users wil
62 matches
Mail list logo
