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
On Tue, Aug 12, 2014 at 1:47 AM, Junio C Hamano gits...@pobox.com wrote:
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/mv.c | 47 +--
1 file changed, 21 insertions(+), 26
On Tue, Aug 12, 2014 at 11:34 AM, Jeff King p...@peff.net 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
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 jsorianopas...@gmail.com
---
read-cache.c | 10 +++---
1 file changed, 7
On Tue, Aug 12, 2014 at 5:56 AM, Luke Campagnola
luke.campagn...@gmail.com 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
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 that
On Tue, Aug 12, 2014 at 12:11 PM, Dennis Kaarsemaker
den...@kaarsemaker.net 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
Pat Thoyts pattho...@users.sourceforge.net 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.
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
Stefan Beller stefanbel...@gmail.com 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
Duy Nguyen pclo...@gmail.com 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
Stefan Beller stefanbel...@gmail.com 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)
Jaime Soriano Pastor jsorianopas...@gmail.com 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
Jaime Soriano Pastor jsorianopas...@gmail.com 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
Sergey Organov sorga...@gmail.com 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
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 file... to include in what will be committed)
#
# lib/yzz/posward_side.rb
nothing added to
Junio C Hamano gits...@pobox.com 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
Hi Thomas,
Thomas Rast writes:
Fabian Ruch baf...@gmail.com 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
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.
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 stefanbel...@gmail.com
Helped-by: René Scharfe
Stefan Beller stefanbel...@gmail.com 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 Moy matthieu@grenoble-inp.fr writes:
Stefan Beller stefanbel...@gmail.com 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
... 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 gits...@pobox.com wrote:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Stefan Beller
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
Stefan Beller stefanbel...@gmail.com writes:
+ if (is_bare !allow_bare) {
+ unlink(name);
+ fprintf(stderr, corrupt mailbox\n);
+ exit(1);
+ }
Not directly
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 ock...@raz.or.at
---
Since version 7.30.0, libcurl's API has been able to communicate with
IMAP servers. Using those high-level functions
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
Stefan Beller stefanbel...@gmail.com 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)
Stefan Beller wrote:
This was found by coverity. (Id: 290001)
[...]
Signed-off-by: Stefan Beller stefanbel...@gmail.com
Helped-by: René Scharfe l@web.de
---
builtin/mailsplit.c | 17 ++---
1 file changed, 6 insertions(+), 11 deletions(-)
The idea is to simplify error
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 wants to view
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
From: Stefan Beller stefanbel...@gmail.com
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)
Match the predominant style in git by following KR 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
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,
On Tue, Aug 12, 2014 at 5:03 PM, Jonathan Nieder jrnie...@gmail.com 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
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
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
On Tue, Aug 12, 2014 at 10:13:03PM +0700, Duy Nguyen wrote:
On Tue, Aug 12, 2014 at 11:34 AM, Jeff King p...@peff.net 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
38 matches
Mail list logo
