Hi all,
I have a single workspace where executing merges
occasionally leads to a left-over .git/index.lock file
that prevents me from adding resolved conflicted files.
I'm running a sped-up integration/feature branch process,
and the merges and conflict resolution are automated.
But the index.loc
On Tue, Feb 09, 2016 at 12:47:39AM +0200, Mikko Rapeli wrote:
> On Mon, Feb 08, 2016 at 05:36:50PM -0500, Matt McCutchen wrote:
> > On Mon, 2016-02-08 at 14:22 -0800, Junio C Hamano wrote:
> > > Matt McCutchen writes:
> > >
> > > > I found no evidence of such behavior in the source code.
> > > >
Ovidiu Gheorghioiu wrote:
> Hi git guys,
>
> The bug is fairly simple: if we have a conflicted merge, AND all the
> conflicts have been resolved to the version in HEAD, the commit
> --dry-run error code says nothing to commit. As expected, git commit
> goes through.
>
> The commit message IS cor
Hi Jeff,
unfortunately, `--tree-filter true` doesn't solve the problem with the
repo at my work: not all old blobs are replaced with the new ones. I've
made a test repository to demonstrate it; it's a huge one (115M), but I
couldn't make it much smaller, because the bug fails to reproduce if the
Matt McCutchen writes:
> On Mon, 2016-02-08 at 14:22 -0800, Junio C Hamano wrote:
>> Matt McCutchen writes:
>>
>> > I found no evidence of such behavior in the source code.
>> >
>> > Signed-off-by: Matt McCutchen
>> > ---
>>
>> That was added last year at bcd57cb9 (Documentation/git-clean.tx
David Turner writes:
> Changes to this version:
> re-rolled on top of pu as-of 9db66d9f1aa.
>
> Bug fixes include:
> For submodules: memory leaks; segfault on bad config. (thanks to Peff)
> In symref splitting: check that would always succeed (thanks to Peff)
> A bogus double-declaration of a var
On Mon, Feb 08, 2016 at 11:07:26PM +, Eric Wong wrote:
> Jeff King wrote:
> > Repost of <20160114202608.ga8...@sigill.intra.peff.net> from a few weeks
> > ago (sorry, gmane is down so I can't generate a link).
>
> I prefer we use links derived from Message-IDs anyways. This
> prevents relia
Jeff King writes:
> This shouldn't overflow, as we are copying a sha1 hex into a
> 41-byte buffer. But it does not hurt to use a bound-checking
> function, which protects us and makes auditing for overflows
> easier.
>
> Signed-off-by: Jeff King
> ---
> These strcpy calls go away in jc/rerere-mu
Jeff King wrote:
> Repost of <20160114202608.ga8...@sigill.intra.peff.net> from a few weeks
> ago (sorry, gmane is down so I can't generate a link).
I prefer we use links derived from Message-IDs anyways. This
prevents reliance on gmane article numbers being a central point
of failure:
http://m
Kazutoshi Satoda wrote:
> I'm sorry not coming with test scripts, but I couldn't figure out how to
> write tests to reproduce problems happen only with non-UTF-8 paths while
> the tests seems to be run on UTF-8 locale.
Thank you. I will try to work on some tests throughout the week
(help appreci
On Mon, Feb 08, 2016 at 05:36:50PM -0500, Matt McCutchen wrote:
> On Mon, 2016-02-08 at 14:22 -0800, Junio C Hamano wrote:
> > Matt McCutchen writes:
> >
> > > I found no evidence of such behavior in the source code.
> > >
> > > Signed-off-by: Matt McCutchen
> > > ---
> >
> > That was added la
Jeff King writes:
> This strcpy will never overflow because it's copying from
> baked-in test data. But we would prefer to avoid strcpy
> entirely, as it makes it harder to audit for real security
> bugs.
>
> Signed-off-by: Jeff King
> ---
> Repost of <20160114202608.ga8...@sigill.intra.peff.net
Jeff King writes:
> But having looked at this, I can't help but wonder if the rule should
> not be "does the file exist" in the first place, but "is the file in the
> index". This dwimmery is about commands like "log" that are reading
> existing commits. I cannot think of a case where we would wa
On Mon, 2016-02-08 at 14:22 -0800, Junio C Hamano wrote:
> Matt McCutchen writes:
>
> > I found no evidence of such behavior in the source code.
> >
> > Signed-off-by: Matt McCutchen
> > ---
>
> That was added last year at bcd57cb9 (Documentation/git-clean.txt:
> document that -f may need to b
This shouldn't overflow, as we are copying a sha1 hex into a
41-byte buffer. But it does not hurt to use a bound-checking
function, which protects us and makes auditing for overflows
easier.
Signed-off-by: Jeff King
---
These strcpy calls go away in jc/rerere-multi, so I was holding onto
this to
Matt McCutchen writes:
> I found no evidence of such behavior in the source code.
>
> Signed-off-by: Matt McCutchen
> ---
That was added last year at bcd57cb9 (Documentation/git-clean.txt:
document that -f may need to be given twice, 2015-02-26). It would
be better to know what got changed sin
This strcpy will never overflow because it's copying from
baked-in test data. But we would prefer to avoid strcpy
entirely, as it makes it harder to audit for real security
bugs.
Signed-off-by: Jeff King
---
Repost of <20160114202608.ga8...@sigill.intra.peff.net> from a few weeks
ago (sorry, gman
Jeff King writes:
> FWIW, as the person who wrote that section, I think that is a good
> addition. We do have a link to Simon Tatham's bug-reporting guide, but
> this is a good place to put project-specific advice.
>
> In addition to "try it on next" you may want to also mention "try it on
> the
On 8.2.2016 18:28, Junio C Hamano wrote:
> Petr Stodulka writes:
>
>> On 4.2.2016 20:15, Junio C Hamano wrote:
>>> Petr Stodulka writes:
>>>
I found that license file COPYING is different as compared with
http://www.gnu.org/licenses/gpl-2.0.txt If I pass over with
Linus's preamb
Nguyễn Thái Ngọc Duy writes:
> This series brings three new options to shallow clone/fetch, to let
> you specify cut point by time, or by excluding some refs, or to let
> you extend shallow boundary by commits.
>
> The series is now complete. Changes since v1 [1]
>
> - smart http support
> -
Eric Sunshine writes:
>> @@ -746,6 +757,13 @@ static void receive_needs(void)
>> struct object *o = want_obj.objects[i].item;
>> argv_array_push(&av, oid_to_hex(&o->oid));
>> }
>> + if (deepen_not.nr) {
>> +
Nguyễn Thái Ngọc Duy writes:
> This is basically dwim_ref() without @{} support. To be used on the
> server side where we want to expand abbreviated to full ref names and
> nothing else.
It is unclear why we want to have such an expansion on the server,
though. That is something this commit ne
Nguyễn Thái Ngọc Duy writes:
> + cd shallow-since &&
> + GIT_COMMITTER_DATE="1 +0700" git commit --allow-empty -m one &&
> + GIT_COMMITTER_DATE="2 +0700" git commit --allow-empty -m two &&
> + GIT_COMMITTER_DATE="3 +0700" git commit --allow-empty -m three
Nguyễn Thái Ngọc Duy writes:
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
It is kind of surprising that 16 & 17 can be so simple and does not
have to update the way the cut-off points at the client side are
computed or recorded. We must have done something right when we
designed the initial "-
Nguyễn Thái Ngọc Duy writes:
> This should allow the user to say "create a shallow clone containing the
> work from last year" (once the client side is fixed up, of course).
>
> In theory deepen-since and deepen (aka --depth) can be used together to
> draw the shallow boundary (whether it's inte
Nguyễn Thái Ngọc Duy writes:
> Instead of a custom commit walker like get_shallow_commits(), this new
> function uses rev-list to mark NOT_SHALLOW to all reachable commits,
> except borders. The definition of reachable is to be defined by the
> protocol later. This makes it more flexible to defi
On Mon, Feb 08, 2016 at 03:20:43PM -0500, Jeff King wrote:
> On Mon, Feb 08, 2016 at 02:52:30PM -0500, Jeff King wrote:
>
> > Here is my patch again, with that part removed, and the tests fixed up.
> > Though on reflection, I do think it would be better if we could simply
> > expand the wildcard
Duy Nguyen writes:
> On Fri, Feb 5, 2016 at 6:22 AM, Junio C Hamano wrote:
>> Nguyễn Thái Ngọc Duy writes:
>>
>>> Signed-off-by: Nguyễn Thái Ngọc Duy
>>> ---
>>
>> This is even more strange. Are the current callers broken and some
>> sends value==NULL for an option that is not is_bool, resul
Nguyễn Thái Ngọc Duy writes:
> Even if it is easier to write HEAD~2000, it is legal to write
> HEAD^^^... (repeats "^" 2000 times in total). However, such a string is
> too long to be a legal filename (and on Windows, by default even much,
> much shorter strings are still illegal because they ex
Hi,
Stefan Beller wrote:
> 1) You work on the superproject and don't care about the submodules.
> In this case you want the superproject non-shallow and the submodules
> may be just fine with depth 1. (Think of libraries pulled in via Git instead
> of via the build system)
>
> 2) The superproject
On Mon, Feb 08, 2016 at 02:52:30PM -0500, Jeff King wrote:
> Here is my patch again, with that part removed, and the tests fixed up.
> Though on reflection, I do think it would be better if we could simply
> expand the wildcard globs to say "does this match anything in the file
> system". That mak
Stefan Beller writes:
> ... Instead of the branch, you can just pass
> a sha1 to git fetch and it sometimes works (if the server permits fetching
> arbitrary or hidden sha1s. Though Jonathan noted this check may be in
> the client only and the server trusts the client on not wanting arbitrary
> s
Johannes Schindelin writes:
> write_script is a semantically unambiguous way to specify what we *want*.
> And it would allow us to handle chmod specifically for Windows *in one
> place only*.
Correct. write_script, for the intended target of the helper, is a
way to write a script that can later
Hi Peff,
On Mon, 8 Feb 2016, Jeff King wrote:
> On Mon, Feb 08, 2016 at 08:31:54PM +0100, Johannes Schindelin wrote:
>
> > On Mon, 8 Feb 2016, Jeff King wrote:
> >
> > > Assuming your patch works on Windows
> >
> > If it re-introduces that chmod +x, it won't.
> >
> > Please note that my *orig
On Mon, Feb 08, 2016 at 11:43:19AM -0800, Junio C Hamano wrote:
> > But then what is write_script buying us?
>
> The correct way to write a script for a specific interpreter is to
> give a second parameter to write_script, i.e.
>
> write_script exec.sh /bin/sh
> and the answer to
On Mon, Feb 08, 2016 at 11:35:10AM -0800, Junio C Hamano wrote:
> To be bluntly honest, I do not see the current "string containing
> wildcard characters are taken as path, not rev, unless you use the
> double dash to disambiguate." all bad. Isn't it sort of crazy to
> have square brackets in pat
Daniel Egger writes:
> I stumbled across a problem with worktrees recently; I incorrectly
> opened a ticket a GitHub for that and it was suggested that it
> might be fixed in 2.7.1 so I held off reporting it here but as it
> turned out it is still broken in 2.7.1 so here we go.
Instead of holdin
Jeff King writes:
> I'm confused why it matters. write_script() unconditionally calls "chmod
> +x", doesn't it?
Yeah, that was exactly my thought, too. Sorry for not noticing that
this depended the "interpreter" exactly be /bin/sh, though (it is
not even executed).
> I just double-checked its
Jeff King writes:
> The patch for that might look like this. I like it for its relative
> simplicity, though it does make the rules even harder to explain to a
> user...
True.
To be bluntly honest, I do not see the current "string containing
wildcard characters are taken as path, not rev, unles
On Mon, Feb 08, 2016 at 08:31:54PM +0100, Johannes Schindelin wrote:
> On Mon, 8 Feb 2016, Jeff King wrote:
>
> > Assuming your patch works on Windows
>
> If it re-introduces that chmod +x, it won't.
>
> Please note that my *original* patch actually only guarded the chmod +x,
> but Junio sugges
Hi,
On Mon, 8 Feb 2016, Jeff King wrote:
> Assuming your patch works on Windows
If it re-introduces that chmod +x, it won't.
Please note that my *original* patch actually only guarded the chmod +x,
but Junio suggested switching to write_script and since it passed the test
suite here, I though i
Thanks.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On Mon, Feb 08, 2016 at 01:00:50PM -0500, Eric Sunshine wrote:
> On Mon, Feb 8, 2016 at 10:08 AM, Jeff King wrote:
> > On Mon, Feb 08, 2016 at 02:41:44PM +, Markus Kuhn wrote:
> >> Suggested rephrasing:
> >>
> >>If not set, the value of transfer.fsckObjects is used
> >>
On Sun, Feb 7, 2016 at 5:32 AM, Lars Schneider wrote:
>
> On 06 Feb 2016, at 01:05, Junio C Hamano wrote:
>
>> Stefan Beller writes:
>>
>>> Currently when cloning a project, including submodules, the --depth argument
>>> is passed on recursively, i.e. when cloning with "--depth 2", both the
>>>
tbo...@web.de writes:
> From: Torsten Bögershausen
>
> When core.autocrlf is set to false, and no attributes are set, the file
> is treated as binary.
This, and also on the title, I know by "binary" you mean "no
conversion is attempted", and it is the word used in the code around
there, but it s
tbo...@web.de writes:
> From: Torsten Bögershausen
> Subject: Re: [PATCH v3 1/7] t0027: Add tests for get_stream_filter()
s/: Add/: add/ (no need to resend this)
> When a filter is configured, a different code-path is used in convert.c
> and entry.c via get_stream_filter(), but there are no tes
On Mon, Feb 8, 2016 at 10:08 AM, Jeff King wrote:
> On Mon, Feb 08, 2016 at 02:41:44PM +, Markus Kuhn wrote:
>> Suggested rephrasing:
>>
>>If not set, the value of transfer.fsckObjects is used
>>instead, which defaults to false.
>
> Yeah, I agree your phrasing is much c
Hi. I understand what you mean, but if that's the case, I don't get
how every file was merged successfully despite the encryption, except
two of them. I thought the smudge filter was supposed to be applied to
every blob before any git operation, thus exposing the clean source
code. Well, in the end
Leonardo writes:
> Hi, everybody. I'm new to git and I'd like to keep track of some codes
> we have here in our company. They have some sensitive information I
> would like to keep private. After some googling, I found some
> solutions that encrypt/decrypt the files using filters as they're
> com
Petr Stodulka writes:
> On 4.2.2016 20:15, Junio C Hamano wrote:
>> Petr Stodulka writes:
>>
>>> I found that license file COPYING is different as compared with
>>> http://www.gnu.org/licenses/gpl-2.0.txt If I pass over with
>>> Linus's preamble, change is only about whitespaces - tabs
>>> vs.
On Mon, Feb 08, 2016 at 05:27:30PM +0100, Michael J Gruber wrote:
> > I think this just re-breaks things on Windows. That first setup test
> > used "chmod +x" (which is brought back by your patch), without having
> > the POSIXPERM prerequisite.
> >
> > We probably do not want to mark the whole set
[warning: experimenting with forwarding to and replying from gmail...]
2016-02-08 14:50 GMT+01:00 Jeff King :
> On Sun, Feb 07, 2016 at 08:11:37PM +0100, Michael J Gruber wrote:
>
>> bcb11f1 (mingw: mark t9100's test cases with appropriate prereqs, 2016-01-27)
>> replaced "/bin/sh" in exec.sh by th
On Mon, Feb 08, 2016 at 10:28:58AM -0500, Jeff King wrote:
> On Mon, Feb 08, 2016 at 02:33:17PM +, John Keeping wrote:
>
> > I have just noticed that with DATE_STRFTIME, the timezone in the output
> > is likely to be incorrect.
> >
> > For all other time formats, we print the string ourselves
On Mon, Feb 08, 2016 at 10:28:58AM -0500, Jeff King wrote:
> So I think the fix is probably just that we need to feed the zone
> information to strftime via the "struct tm".
Ugh, I forgot how horrible the strftime interface is.
There is no zone information in "struct tm". It gets pulled from the
Without the initialization of $self->{pathnameencoding}, conversion in
repo_path() is always skipped as $self->{pathnameencoding} is undefined
even if "svn.pathnameencoding" is configured.
The lack of conversion results in mysterious failure of dcommit (e.g.
"Malformed XML") which happen only when
These are small fixes to problems I encountered using git-svn with
svn.pathnameencoding configuration (cp932 in my case). The problems
happen only when sending changes on non-ASCII paths.
I'm sorry not coming with test scripts, but I couldn't figure out how to
write tests to reproduce problems hap
The conversion from "svn.pathnameencoding" to UTF-8 should be applied
first, and then URL encoding should be applied on the resulting UTF-8
path. The reversed order of these transforms (used before this fix)
makes non-UTF-8 URL which causes error from Subversion such as
"Filesystem has no item: '..
On Mon, Feb 08, 2016 at 02:33:17PM +, John Keeping wrote:
> I have just noticed that with DATE_STRFTIME, the timezone in the output
> is likely to be incorrect.
>
> For all other time formats, we print the string ourselves and use the
> correct timezone from the input, but with DATE_STRFTIME
On Mon, Feb 08, 2016 at 02:41:44PM +, Markus Kuhn wrote:
> https://www.kernel.org/pub/software/scm/git/docs/git-config.html
>
> The git-config(1) man page entries for "fetch.fsckObjects" and
> "receive.fsckObjects" both end with the lines
>
>Defaults to false. If not set, the val
On Mon, Feb 08, 2016 at 09:15:52AM -0500, Jeff King wrote:
> I wonder if we could fix this pretty simply, though, by skipping the
> "does it have a wildcard" check when we see a colon in the path. That is
> a good indication that we are using one of git's special rev syntaxes
> (either "tree:path"
https://www.kernel.org/pub/software/scm/git/docs/git-config.html
The git-config(1) man page entries for "fetch.fsckObjects" and
"receive.fsckObjects" both end with the lines
Defaults to false. If not set, the value of transfer.fsckObjects is
used instead.
These two sentenc
I have just noticed that with DATE_STRFTIME, the timezone in the output
is likely to be incorrect.
For all other time formats, we print the string ourselves and use the
correct timezone from the input, but with DATE_STRFTIME strftime(3) will
always use the system timezone.
--
To unsubscribe from t
On Mon, Feb 08, 2016 at 09:15:52AM -0500, Jeff King wrote:
> I wonder if we could fix this pretty simply, though, by skipping the
> "does it have a wildcard" check when we see a colon in the path. That is
> a good indication that we are using one of git's special rev syntaxes
> (either "tree:path"
On Mon, Feb 08, 2016 at 12:06:44PM +0700, Duy Nguyen wrote:
> On Sun, Feb 7, 2016 at 10:11 PM, Kirill Likhodedov
> wrote:
> > Hi Duy,
> >
> >> It's from 28fcc0b (pathspec: avoid the need of "--" when wildcard is
> >> used - 2015-05-02)
> >
> > v2.5.0 is the first release which contains 28fcc0b.
>
On Tue, Feb 02, 2016 at 01:45:50PM -0500, Eric Sunshine wrote:
> On Tue, Feb 2, 2016 at 6:51 AM, Patrick Steinhardt wrote:
> > When setting the 'core.worktree' option for a newly cloned
> > submodule we ignore the return value of `git_config_set_in_file`.
> > As this leaves the submodule in an inc
On Mon, Feb 08, 2016 at 02:42:32PM +0100, Patrick Steinhardt wrote:
> On Tue, Feb 02, 2016 at 12:49:26PM -0800, Junio C Hamano wrote:
> > Patrick Steinhardt writes:
> >
> > > The setup_tracking function calls install_branch_config, which
> > > may fail writing the configuration due to a locked co
On Sun, Feb 07, 2016 at 08:04:38PM -0500, Matt McCutchen wrote:
> > it is very much
> > appreciated when reporting bugs people check if a presumed fix is
> > already cooking in 'next', try it to verify if it really fixes their
> > problem, and send in a "OK fix is good" / "No that does not fix my
On Sun, Feb 07, 2016 at 08:11:37PM +0100, Michael J Gruber wrote:
> bcb11f1 (mingw: mark t9100's test cases with appropriate prereqs, 2016-01-27)
> replaced "/bin/sh" in exec.sh by the shell specified in SHELL_PATH, but
> that breaks the subtest which checks for a specific checksum of a tree
> con
On Tue, Feb 02, 2016 at 12:49:26PM -0800, Junio C Hamano wrote:
> Patrick Steinhardt writes:
>
> > The setup_tracking function calls install_branch_config, which
> > may fail writing the configuration due to a locked configuration
> > file or other error conditions. setup_tracking can also fail w
Signed-off-by: Brilliantov Kirill Vladimirovich
---
builtin/apply.c | 4 ++--
builtin/blame.c | 2 +-
builtin/cat-file.c | 8
builtin/checkout.c | 18 +-
builtin/commit-tree.c | 6 +++---
builtin/commit.c| 6 +++---
builtin/describ
On Mon, Feb 08, 2016 at 09:59:18AM +0100, larsxschnei...@gmail.com wrote:
> From: Lars Schneider
>
> The global Travis-CI environment variable CFLAGS did not override the
> CFLAGS variable in the makefile. Pass CFLAGS as make variable to
> override it properly.
Makes sense.
> In addition to th
On Sun, Feb 7, 2016 at 4:23 PM, Jagan Teki wrote:
> Do we have any git config options to add Cc and Tested-by list like
> Signed-off-by is fetched from git config.
>
> example:
>
> $ git commit -s
>
> Cc: Arjun Ani
> Tested-by: Jagan Teki
> Signed-off-by: Jagan Teki
>
> Please share if we have
On Sun, Feb 07, 2016 at 08:44:50PM +0100, Lars Schneider wrote:
> > Are there any other reasons why current_config_filename() would return
> > NULL, besides command-line config? I don't think so. It looks like we
> > can read config from stdin, but we use the token "" there for the
> > name field
On Sun, Feb 07, 2016 at 08:28:26PM +0100, Lars Schneider wrote:
> > I think he inherited the "--sources" name from me. :) I agree it could
> > be better. I think "--show-filename" is not right as there are
> > non-filename cases. Just "--origin" sounds funny to me, perhaps because
> > of git's no
On Mon, Feb 08, 2016 at 12:25:58PM +0100, Sebastian Schuberth wrote:
> On 2/5/2016 14:58, Jeff King wrote:
>
> >Yeah, I agree it's unlikely. And the output is already ambiguous, as the
> >first field could be a blob (though I guess the caller knows if they
> >passed "--blob" or not). If we really
On 2/5/2016 14:58, Jeff King wrote:
Yeah, I agree it's unlikely. And the output is already ambiguous, as the
first field could be a blob (though I guess the caller knows if they
passed "--blob" or not). If we really wanted an unambiguous output, we
could have something like "file:...", "blob:...
On Sun, Feb 7, 2016 at 8:28 PM, Lars Schneider wrote:
>>> However, the naming of the '--sources' option sounds a bit misleading to me.
>>> It has nothing to do with source code. So maybe better name it '--origin',
>>> or even more verbose '--show-origin' or '--show-filename'?
>>
>> I think he inh
On 4.2.2016 20:15, Junio C Hamano wrote:
> Petr Stodulka writes:
>
>> I found that license file COPYING is different as compared with
>> http://www.gnu.org/licenses/gpl-2.0.txt If I pass over with
>> Linus's preamble, change is only about whitespaces - tabs
>> vs. space. Probably it's minor no
2016-02-06 0:52 GMT+03:00 Junio C Hamano :
> "brian m. carlson" writes:
>
>> On Fri, Feb 05, 2016 at 01:02:58PM -0800, Junio C Hamano wrote:
>>> Hmph, so documenting that :@
>>> as a supported way might be an ugly-looking solution to the original
>>> problem. A less ugly-looking solution might be
From: Lars Schneider
The global Travis-CI environment variable CFLAGS did not override the
CFLAGS variable in the makefile. Pass CFLAGS as make variable to
override it properly.
In addition to that, add '-Wdeclaration-after-statement' to make a
Travis-CI build fail (because of '-Werror') if the
Hi guys,
I stumbled across a problem with worktrees recently; I incorrectly opened a
ticket a GitHub for that and it was suggested that it might be fixed in 2.7.1
so I held off reporting it here but as it turned out it is still broken in
2.7.1 so here we go.
The problem is that the paths of th
81 matches
Mail list logo
