On 13.08.2014 01:57, Jonathan Nieder wrote:
> Stefan Beller wrote:
>
>> In line 1763 of unpack-tree.c we have a condition on the current tree
> [...]
>
> The description is describing why the patch is *correct* (i.e., not
> going to introduce a bug), while what the reader wants to know is why
> t
On Tue, Aug 12, 2014 at 10:13:03PM +0700, Duy Nguyen wrote:
> On Tue, Aug 12, 2014 at 11:34 AM, Jeff King wrote:
> > Arguably is_repository_shallow should return 1 if anybody has registered
> > a shallow graft, but that wouldn't be enough to fix this (we'd still
> > need to check it again _after_
Bernhard Reiter wrote:
> Use libcurl's high-level API functions to implement git-imap-send
> instead of the previous low-level OpenSSL-based functions.
Wow! This sounds lovely. Thanks for working on this.
[...]
> Since version 7.30.0, libcurl's API has been able to communicate with
> IMAP serv
This is about what happens when a Git process gets killed by someone,
or there is a system crash, and then we try to run Git again on the
repository.
When I run git-commit after adding a few files to the repository, git
updates the .git/refs/heads/master file using rename() to complete the
commit.
On Tue, Aug 12, 2014 at 5:03 PM, Jonathan Nieder wrote:
> twoway_merge() is missing an o->gently check in the case where a file
> that needs to be modified is missing from the index but present in the
> old and new trees. As a result, in this case 'git checkout -m' errors
> out instead of trying
twoway_merge() is missing an o->gently check in the case where a file
that needs to be modified is missing from the index but present in the
old and new trees. As a result, in this case 'git checkout -m' errors
out instead of trying to perform a merge.
Fix it by checking o->gently. While at it,
Match the predominant style in git by following K&R style for if/else
cascades. Documentation/CodingStyle from linux.git explains:
Note that the closing brace is empty on a line of its own, _except_ in
the cases where it is followed by a continuation of the same statement,
ie a "while" in a
From: Stefan Beller
In the 'if (current)' block of twoway_merge, we handle the boring
errors by checking if the entry from the old tree, current index, and
new tree are present, to get a pathname for the error message from one
of them:
if (oldtree)
return o->gently ? -1 :
Stefan Beller wrote:
> In line 1763 of unpack-tree.c we have a condition on the current tree
[...]
The description is describing why the patch is *correct* (i.e., not
going to introduce a bug), while what the reader wants to know is why
the change is *desirable*.
Is this about making the code mo
On Wed, 2014-07-30 at 20:09 -0400, Jeff King wrote:
> On Wed, Jul 30, 2014 at 12:43:09PM -0700, Junio C Hamano wrote:
>
> > > "git log --cc" is one of the things I wanted for a long time to fix.
> > > When the user explicitly asks "--cc", we currently ignore it, but
> > > because we know the user
Stefan Beller wrote:
> This was found by coverity. (Id: 290001)
[...]
> Signed-off-by: Stefan Beller
> Helped-by: René Scharfe
> ---
> builtin/mailsplit.c | 17 ++---
> 1 file changed, 6 insertions(+), 11 deletions(-)
The idea is to simplify error handling (removing cleanup of the
Stefan Beller writes:
> In line 1763 of unpack-tree.c we have a condition on the current tree
> if (current) {
> ...
> Within this block of code we can assume current to be non NULL, hence
> the code after the statement in line 1796:
> if (current)
> return
This is more of an RFH than a PATCH. I think we would want to
encapsulate the logic to set STATUS_REJECT_NODELETE in
set_ref_status_for_push() function, but I do not see a good code
structure to do so, given the constraints of the dataflow (i.e. the
protocol capability is only inspected here with
Use libcurl's high-level API functions to implement git-imap-send
instead of the previous low-level OpenSSL-based functions.
Signed-off-by: Bernhard Reiter
---
Since version 7.30.0, libcurl's API has been able to communicate with
IMAP servers. Using those high-level functions instead of the curr
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Stefan Beller writes:
>>
>>> + if (is_bare && !allow_bare) {
>>> + unlink(name);
>>> + fprintf(stderr, "corrupt mailbox\n");
>>> + exit(1);
>>> + }
>>
>> Not directly related to your patch, but shouldn't this b
... answering to myself, the only invoker does not seem to care,
so I do not mind if the fprintf/exit gets turned into die() in a
follow-up patch.
Thanks.
On Tue, Aug 12, 2014 at 2:38 PM, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Stefan Beller writes:
>>
>>> +if (is_bare && !allow_
Matthieu Moy writes:
> Stefan Beller writes:
>
>> +if (is_bare && !allow_bare) {
>> +unlink(name);
>> +fprintf(stderr, "corrupt mailbox\n");
>> +exit(1);
>> +}
>
> Not directly related to your patch, but shouldn't this be using
>
> die(_("corrupt mailb
Stefan Beller writes:
> + if (is_bare && !allow_bare) {
> + unlink(name);
> + fprintf(stderr, "corrupt mailbox\n");
> + exit(1);
> + }
Not directly related to your patch, but shouldn't this be using
die(_("corrupt mailbox"));
instead?
--
Matthieu M
This was found by coverity. (Id: 290001)
The variable 'output' is assigned to a value
after all gotos to the corrupt label.
Remove the goto by moving the errorhandling code to the
condition, which detects the error.
Signed-off-by: Stefan Beller
Helped-by: René Scharfe
---
builtin/mailsplit.c
In line 1763 of unpack-tree.c we have a condition on the current tree
if (current) {
...
Within this block of code we can assume current to be non NULL, hence
the code after the statement in line 1796:
if (current)
return ...
cannot be reached.
curr
Hi Thomas,
Thomas Rast writes:
> Fabian Ruch writes:
>> @@ -634,21 +644,24 @@ do_replay () {
>> comment_for_reflog pick
>>
>> mark_action_done
>> -do_pick $sha1 || die_with_patch $sha1 "Could not apply $sha1...
>> $rest"
>> +eval do_pick $opts
Junio C Hamano writes:
> So I think the reasoning (i.e. "is a descendant" is not quite right)
> is correct, but the updated text is not quite right. Changing it
> further to "only the committer timestamps and identities would
> change" is probably not an improvement, either. "Force the rebase
>
Hi,
I am not able to push my feature branch using Git. I cloned using SSH and SSH
key is also added.
arup@linux-wzza:~/Ruby/yzz> git status
# On branch posward
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# lib/yzz/posward_side.rb
nothing added to commi
Sergey Organov writes:
> Previous description of -f option was wrong as "git rebase" does not
> require -f to perform rebase when "current branch is a descendant of
> the commit you are rebasing onto", provided commit(s) to be rebased
> contain merge(s).
Both the above and the updated documentat
Jaime Soriano Pastor writes:
> Wrong implementations of tools that modify the index can left
> some files as merged and unmerged at the same time. Avoid undesiderable
> behaviours by handling this situation.
It is understandable that the way _you_ decided to "handle the
situation" is so obvious
Jaime Soriano Pastor writes:
> A file in the index can be left as merged and unmerged at the same time
> by some tools as libgit2, this causes some undesiderable behaviours in git.
Well, doesn't it mean that libgit2 is broken? Have you filed a bug
over there yet?
Having said that, protecting o
Stefan Beller writes:
> In line 1763 of unpack-tree.c we have a condition on the current tree
> if (current) {
> ...
> Within this block of code we can assume current to be non NULL, hence
> the code after the statement in line 1796:
> if (current)
> return
Duy Nguyen writes:
>> Otherwise, perhaps squash this in?
>
> Sure. But I'm having second thought about this series.
>
> mv.c is centered around files on worktree, which makes it pretty hard
> if we want to make it more like rm.c where index and worktree entries
> are treated more equally and path
Stefan Beller writes:
> blame belonging to the group of
> ancillaryinterrogators and not to plumbinginterrogators
> should have localized error messages?
Unless running under --porcelain option to be driven by scripts, we
expect that we are talking to a human user, so using "_(msg)" is very
much
Am 11.08.2014 um 23:11 schrieb Stefan Beller:
This was found by coverity. (Id: 290001)
the variable 'output' is only assigned to a value inequal to NUL,
after all gotos to the corrupt label.
Therefore we can conclude the two removed lines are actually dead code.
After reading the above for the
Pat Thoyts writes:
>>Pat, do you want patches via the git mailing list, personal mail, or
>>some other way?
>>
>
> The standard method is both: personal to ensure I see it and mailing list to
> allow everyone to comment.
>
> I've applied this patch to git-gui master.
Thanks, both. Is it a goo
On Tue, Aug 12, 2014 at 12:11 PM, Dennis Kaarsemaker
wrote:
> On ma, 2014-08-11 at 18:56 -0400, Luke Campagnola wrote:
>>
>> raven:/home/luke/vispy (transform-cache)$ git checkout master
>> Switched to branch 'master'
>> Deleted 103 .pyc files
>> Deleted 11 empty directories
>
> This looks like yo
On ma, 2014-08-11 at 18:56 -0400, Luke Campagnola wrote:
>
> raven:/home/luke/vispy (transform-cache)$ git checkout master
> Switched to branch 'master'
> Deleted 103 .pyc files
> Deleted 11 empty directories
This looks like you have a local post-checkout hook that deletes empty
directories. Fix
On Tue, Aug 12, 2014 at 5:56 AM, Luke Campagnola
wrote:
> Greetings,
>
> I have been working happily with git for a couple of years, and ran
> into a mysterious issue today: after running a git-pull during which I
> saw the message "Auto packing the repository for optimum performance".
> I now rec
A file in the index can be left as merged and unmerged at the same time
by some tools as libgit2, this causes some undesiderable behaviours in git.
I have seen, at least, these behaviours:
- git reset --hard consuming 100% CPU and never ending
- git reset --hard consuming all memory in git < 2.0
-
Wrong implementations of tools that modify the index can left
some files as merged and unmerged at the same time. Avoid undesiderable
behaviours by handling this situation.
Signed-off-by: Jaime Soriano Pastor
---
read-cache.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff
On Tue, Aug 12, 2014 at 11:34 AM, Jeff King wrote:
> Arguably is_repository_shallow should return 1 if anybody has registered
> a shallow graft, but that wouldn't be enough to fix this (we'd still
> need to check it again _after_ reading the --shallow lines). So I think
> this fix is fine here. I
On Tue, Aug 12, 2014 at 1:47 AM, Junio C Hamano wrote:
> Nguyễn Thái Ngọc Duy writes:
>
>> Signed-off-by: Nguyễn Thái Ngọc Duy
>> ---
>> builtin/mv.c | 47 +--
>> 1 file changed, 21 insertions(+), 26 deletions(-)
>>
>> diff --git a/builtin/mv.c b/bui
Hello all,
I noticed a weird rename conflict after doing the following steps:
1. Changing the extension of a file using 'git mv'.
2. Editing the file and staging the changes.
3. Creating a new file and staging it.
Here is the Git Bash output showing the issue. The previously mentioned st
39 matches
Mail list logo
