On Sat, May 20, 2017 at 05:52:16AM +, Дилян Палаузов wrote:
> Signed-off-by: Дилян Палаузов
I assume this is just going through the results of clang's static
analyzer and quieting it. I think most of these are not the right fix,
though, as I discussed in
http://public-inbox.org/git/20170
Am 19.05.2017 um 23:55 schrieb Atousa Duprat:
I have tried to repro this issue but git goes out of its way to store
the commit messages using unix end-of-line format.
I think that git itself cannot create a repo exhibiting this problem.
Here is a recipe to reproduce the error:
git init
git
Fetching from a remote using a native Windows path produces these warnings:
C:\Temp\gittest>git fetch C:\Temp\gittest
warning: unable to access '.git/remotes/C:\Temp\gittest': Invalid argument
warning: unable to access '.git/branches/C:\Temp\gittest': Invalid argument
>From C:\Temp\gittest
* bran
The implementation of is_dir_sep in git-compat-util.h uses an inline
function. Use one also for the implementation in compat/mingw.h to support
non-trivial argument expressions.
Signed-off-by: Johannes Sixt
---
compat/mingw.h | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git
This small series fixes these warnings on Windows:
C:\Temp\gittest>git fetch C:\Temp\gittest
warning: unable to access '.git/remotes/C:\Temp\gittest': Invalid argument
warning: unable to access '.git/branches/C:\Temp\gittest': Invalid argument
>From C:\Temp\gittest
* branchHEAD
Signed-off-by: Дилян Палаузов
diff --git a/archive.c b/archive.c
index 60b889198..e2534d186 100644
--- a/archive.c
+++ b/archive.c
@@ -503,7 +503,7 @@ int write_archive(int argc, const char **argv, const char
*prefix,
init_tar_archiver();
init_zip_archiver();
- argc = par
Earlier dddbad72 ("timestamp_t: a new data type for timestamps",
2017-04-26) updated all in-core variables, fields and function
return values that are used to store "seconds since epoch" to a new
type timestamp_t. Unfortunately one variable "cutoff", which is
used to keep track of the oldest times
Michael J Gruber writes:
> I think I should change 3/4 to display exactly those bits that name-rev
> actually uses for weighing different possible descriptions; they are
> differents from the "describe-bits". So please withhold 3/4 and 4/4.
OK, I think 1&2/4 from this series can progress before
Stefan Beller writes:
> That could be added in ws.c:ws_check_emit, as these certain words
> are similar to coloring whitespace.
I actually was envisioning of highlighting a part of a line, like
-Very poor SCM
+Very nice SCM
which would be done by finding semi-matching removed and added
Todd Zullinger writes:
> I believe a patch for this is on the ah/log-decorate-default-to-auto
> branch, courtesy of Brian Carlson (Cc:d):
>
>https://github.com/gitster/git/commit/c74271aae7
>
> The relevant list thread is here:
>
>
> https://public-inbox.org/git/20170512213407.46251-1-san
Hi Caleb,
Caleb Evans wrote:
I recently updated to Git v2.13.0 (macOS Sierra via Homebrew), and I
noticed that the default --decorate option for `git log` has changed
from --decorate=no to --decorate=auto. I'd prefer to keep decoration
disabled to minimize clutter in the logs, so I try disabli
Hi,
I recently updated to Git v2.13.0 (macOS Sierra via Homebrew), and I noticed
that the default --decorate option for `git log` has changed from --decorate=no
to --decorate=auto. I'd prefer to keep decoration disabled to minimize clutter
in the logs, so I try disabling it in my global .gitcon
No problem, thanks for taking the time to help me.
I managed to create a minimal repository that shows the bug.
(I was able to deploy gitlab-ce-v8.15.8-ce.0 from docker locally and
create the repo, create the merge request and merge it)
I created a github repository so everybody interested can us
On Fri, 2017-05-19 at 23:43 +0200, Dennis Kaarsemaker wrote:
> On Fri, 2017-05-19 at 14:57 -0500, Elliott Cable wrote:
> > Set up `persistent-https` as described in the [README][]; including the
> > ‘rewrite https urls’ feature in `.gitconfig`:
> >
> > [url "persistent-https"]
> > inst
Sorry for the noise with previous response...
I have tried to repro this issue but git goes out of its way to store
the commit messages using unix end-of-line format.
I think that git itself cannot create a repo exhibiting this problem.
Most helpful would be if you could create a mini repo using
Hi,
I have tried to repro this issue but git goes out of its way to store
the commit messages using unix end-of-line format.
I think that git itself cannot create a repo exhibiting this problem.
Most helpful would be if you could create a mini repo using gitlab.
All it would need is one file, two
On Fri, 2017-05-19 at 14:57 -0500, Elliott Cable wrote:
> Set up `persistent-https` as described in the [README][]; including the
> ‘rewrite https urls’ feature in `.gitconfig`:
>
> [url "persistent-https"]
> insteadof = https
> [url "persistent-http"]
> insteadof = http
>
Second ping. This problem is not going away, so if this solution is not
acceptable, I'd like to know what needs to be improved.
On Thu, 2017-05-04 at 09:01 +0200, Dennis Kaarsemaker wrote:
> Ping. It's a little over a month since I sent this, but I haven't seen
> any comments. Is this commit good
Set up `persistent-https` as described in the [README][]; including the
‘rewrite https urls’ feature in `.gitconfig`:
[url "persistent-https"]
insteadof = https
[url "persistent-http"]
insteadof = http
Unfortunately, this breaks `git submodule add`:
> git submodule ad
On Fri, May 19, 2017 at 11:40 AM, Stefan Beller wrote:
>>> +static unsigned get_line_hash(struct buffered_patch_line *line, unsigned
>>> ignore_ws)
>>> +{
>>> + static struct strbuf sb = STRBUF_INIT;
>>> +
>>> + if (ignore_ws) {
>>> + strbuf_reset(&sb);
>>> + get_w
On Fri, May 19, 2017 at 11:23 AM, Jonathan Tan wrote:
> On Thu, 18 May 2017 12:37:46 -0700
> Stefan Beller wrote:
>
> [snip]
>
>> Instead this provides a dynamic programming greedy algorithm that
>
> Not sure if this is called "dynamic programming".
https://loveforprogramming.quora.com/Backtrack
Glad to see you tackling this. This is definitely a step in the right
direction.
I realize that it will take a lot of work and that intermediate steps
may just be pushing it the global state one level higher but eventually
it would be great to see an entire code path global state free!
I'm
On Thu, May 18, 2017 at 4:23 PM, Stephen Rothwell wrote:
>
> Just a reminder that if you are merging Linus' tree (or any tree
> really) via a tag, git was changed some time ago so that merging a tag
> will not do a fast forward (there is a good reason for this - I just
> can't recall it ATM).
The
On Thu, 18 May 2017 12:37:46 -0700
Stefan Beller wrote:
[snip]
> Instead this provides a dynamic programming greedy algorithm that
Not sure if this is called "dynamic programming".
> finds the largest moved hunk and then switches color to the
> alternative color for the next hunk. By doing thi
Bear with me here, I hit this in a real repo.
If you have an annotated tag of an annotated tag, and `remote update`
elects not to fetch this tag (perhaps because it has a name collision
locally), then the repo ends up corrupt: you can't gc it, but fsck
doesn't notice.
Two repos, named "bad" and "
Greetings
It’s my pleasure to write you today, I am Awawu Issa, am a Personal
Assistant to Late Mr. Lorna Laboso the former Assistant Minister of
Home Affairs in Kenya. Mr.Lorna Laboso and the former Kenyan Road
minister Dr. Kipkalya Kones has been on board the Cessna 210, which
was headed to Keri
After sending this, I noticed that using a different compiler generated
a couple of warnings I should fix. I'm assuming I'll need another
re-roll but if not, here are the changes that will be squashed in.
Ben
diff --git a/dir.c b/dir.c
index da428489e2..37f1c580a5 100644
--- a/dir.c
+++ b/d
Hey Jeff, I'll take a look at improving the text and the other commands.
Thanks for the response. I'll get back to you soonish.
André
2017-05-18 12:59 GMT-03:00 Jeff King :
> On Thu, May 18, 2017 at 11:03:00AM -0300, André Werlang wrote:
>
>> Git 2.11 introduced a computation to guess the defaul
Joey Hess wrote:
> Bisecting this test suite failure
> https://git-annex.branchable.com/git-annex_in_nixpkgs_fails_with_git-2.13.0/
> I landed on commit f57f37e2e1bf11ab4cdfd221ad47e961ba9353a0 to git.
>
> It seems that changed resolving refs paths when GIT_DIR and GIT_COMMON_DIR
> are both set. W
On 19/05/17 12:24, Ævar Arnfjörð Bjarmason wrote:
On Fri, May 19, 2017 at 12:13 PM, Phillip Wood
wrote:
On 18/05/17 22:21, Johannes Schindelin wrote:
Hi Phillip,
On Thu, 18 May 2017, Phillip Wood wrote:
From: Phillip Wood
The message that's printed when auto-stashed changes are successful
From: Phillip Wood
The message that's printed when auto-stashed changes are successfully
restored was missing '\n' at the end.
Signed-off-by: Phillip Wood
Acked-by: Johannes Schindelin
---
I've added signed-off-by and acked-by lines to the commit message,
otherwise this is unchanged
sequence
There's a subtle distinction between "name" and "path" for a
blob that we resolve: the name is what the user told us on
the command line, and the path is what we traversed when
finding the blob within a tree (if we did so).
When we diff blobs directly, we use "name", but "path" is
more likely to b
When we diff a blob against a working tree file like:
git diff HEAD:Makefile Makefile
we always use the working tree filename for both sides of
the diff. In most cases that's fine, as the two would be the
same anyway, as above. And until recently, we used the
"name" for the blob, not the path,
The stuff_change() function makes diff_filespecs out of
blobs. The term we generally use for filespecs is "path",
not "name", so let's be consistent here. That will make
things less confusing when the next patch starts caring
about the path/name distinction inside the pending object
array.
Signed
When diffing blobs directly, git-diff picks the blobs out of
the rev_info's pending array and copies the relevant bits to
a custom "struct blobinfo". But the pending array entry
already has all of this information (and more, which we'll
use in future patches). Let's just pass the original entry
ins
The "a..b" revision syntax was designed to handle commits,
so it doesn't bother to record any mode we find while
traversing a "tree:path" endpoint. These days "git diff" can
diff blobs using either "a:path..b:path" (with dots) or
"a:path b:path" (without), but the two behave
inconsistently, as the
When a sha1 lookup returns the tree path via "struct
object_context", it just copies it into a fixed-size buffer.
This means the result can be truncated, and it means our
"struct object_context" consumes a lot of stack space.
Instead, let's allocate a string on the heap. Because most
callers don't
If the revision parser sees an argument like tree:path, we
parse it down to the correct blob (or tree), but throw away
the "path" portion. Let's ask get_sha1_with_context() to
record it, and pass it along in the pending array.
This will let programs like git-diff which rely on the
revision-parser
The git-diff command can directly compare two blobs (or a
blob and a file), but we don't test this at all. Let's add
some basic tests that reveal a few problems.
There are basically four interesting inputs:
1. sha1 against sha1 (where diff has no information beyond
the contents)
2. tree
The get_sha1_with_context() function zeroes out the
oc->symlink_path strbuf, but doesn't use strbuf_init() to
set up the usual invariants (like pointing to the slopbuf).
We don't actually write to the oc->symlink_path strbuf
unless we call get_tree_entry_follow_symlinks(), and that
function does in
An early version of the patch to add object_context used the
name object_resolve_context. This was later shortened to
just object_context, but the "orc" variable name stuck in a
few places. Let's use "oc", which is used elsewhere in the
code.
Signed-off-by: Jeff King
---
cache.h | 2 +-
sha
The handle_revision_arg function is rather long, and a big
chunk of it is handling the range operators. Let's pull that
out to a separate helper. While we're doing so, we can clean
up a few of the rough edges that made the flow hard to
follow:
- instead of manually restoring *dotdot (that we ove
Since 003c84f6d (specifying ranges: we did not mean to make
".." an empty set, 2011-05-02), we treat the argument ".."
specially. We detect it by noticing that both sides of the
range are empty, and that this is a non-symmetric two-dot
range.
While correct, this makes the code overly complicated.
The handle_revision_arg() function has a "dotdot" variable
that it uses to find a ".." or "..." in the argument. If we
don't find one, we look for other marks, like "^!". But we
just keep re-using the "dotdot" variable, which is
confusing.
Let's introduce a separate "mark" variable that can be use
When we are parsing a range like "a..b", we write a
temporary NUL over the first ".", so that we can access the
names "a" and "b" as C strings. But our restoration of the
original "." is done at inconsistent times, which can lead
to confusing results.
For most calls, we restore the "." after we re
The "dotdot" range parser avoids calling
lookup_commit_reference() if we are directly fed two
commits. But its casts are unnecessarily complex; that
function will just return a commit we pass into it.
Just calling the function all the time is much simpler, and
doesn't do any significant extra work
On Tue, May 16, 2017 at 10:05:35PM -0400, Jeff King wrote:
> On Wed, May 17, 2017 at 10:38:36AM +0900, Junio C Hamano wrote:
>
> > > - add_pending_object(revs, a_obj, this);
> > > - add_pending_object(revs, b_obj, next);
> > > + add_pending_object_w
On 5/18/2017 7:21 PM, Brandon Williams wrote:
When I first started working on the git project I found it very difficult to
understand parts of the code base because of the inherently global nature of
our code. It also made working on submodules very difficult. Since we can
only open up a sing
Hello ,
I am specifically contacting you in respect of a business proposal that I have
for you as you appear very relevant in the proposal.
Please kindly reply back to me for further details.
Waiting to hear from you.
Regards,
Mr. Adams Salem
Private E-mail: mradamssa...@outlook.my
On Fri, May 19, 2017 at 12:13 PM, Phillip Wood
wrote:
> On 18/05/17 22:21, Johannes Schindelin wrote:
>> Hi Phillip,
>>
>> On Thu, 18 May 2017, Phillip Wood wrote:
>>
>>> From: Phillip Wood
>>>
>>> The message that's printed when auto-stashed changes are successfully
>>> restored was missing '\n'
On 18/05/17 22:21, Johannes Schindelin wrote:
> Hi Phillip,
>
> On Thu, 18 May 2017, Phillip Wood wrote:
>
>> From: Phillip Wood
>>
>> The message that's printed when auto-stashed changes are successfully
>> restored was missing '\n' at the end.
>> ---
>
> Please add your Signed-off-by:, and my
On 05/17/2017 03:38 PM, Jeff King wrote:
> On Wed, May 17, 2017 at 02:05:45PM +0200, Michael Haggerty wrote:
>
>> From: Jeff King
>
> This patch did originate with me, but I know you had to fix several
> things to integrate it in your series. So I'll review it anyway, and
> give you full blame f
On 05/17/2017 07:44 PM, Stefan Beller wrote:
> On Wed, May 17, 2017 at 5:05 AM, Michael Haggerty
> wrote:
>> Break the function `ref_transaction_commit()` into two functions,
>> `ref_transaction_prepare()` and `ref_transaction_finish()`, with a
>> third function, `ref_transaction_abort()`, that c
53 matches
Mail list logo