Hello,
I ran into the following bug today: BUG: PATHSPEC_PREFER_CWD requires
arguments. It's not that bad because I'm trying to run `git log
--merge` on an already resolved conflict. Still, I don't think I
should hit a BUG: :-)
Here is a script to reproduce:
git init .
a
git add a
git commit
The -- notation disambiguates files and branches, but as a side-effect
of the previous implementation, also disabled the branch auto-creation
when $branch does not exist.
A possible scenario is then:
git checkout $branch
= fails if $branch is both a ref and a file, and suggests --
git checkout
The previous code was detecting the presence of -- by looking only at
argument 1. As a result, git checkout foo bar -- was interpreted as an
ambiguous file/revision list, and errored out with:
error: pathspec 'foo' did not match any file(s) known to git.
error: pathspec 'bar' did not match any
git diff -M --stat can detect rename and show renamed file name like
foofoofoo = barbarbar.
Before this commit, this output is shortened always by omitting left most
part like ...foo = barbarbar. So, if the destination filename is too long,
source filename putting left or arrow can be totally
Hello Junio
In the [PATCH v7], I changed to keep filename part of suffix to handle
above case, but not always keep directory part because I feel totally
keeping all part of long suffix including directory name may cause output
like:
…{… = …}…ongPath1/LongPath2/nameOfTheFileThatWasMoved
I'm lacking time to read and answer in detail, sorry.
Junio C Hamano gits...@pobox.com writes:
It must be done is different from any change is good, as long as
it introduces more instances of word 'stage'.
I agree. Something must be done, at least to remove the cache Vs index
confusion. I'm
On Fri, Oct 18, 2013 at 5:46 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
I'm lacking time to read and answer in detail, sorry.
Junio C Hamano gits...@pobox.com writes:
It must be done is different from any change is good, as long as
it introduces more instances of word 'stage'.
I
On Fri, Oct 18, 2013 at 4:46 AM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
I'm lacking time to read and answer in detail, sorry.
Junio C Hamano gits...@pobox.com writes:
It must be done is different from any change is good, as long as
it introduces more instances of word 'stage'.
I
On 17.10.2013, at 21:50, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
[...]
However, since you asked, I would share a couple of comments
regarding the index, cache and staging area.
(1) Staging area.
The phrase staging area is not an
I guess most other people keep out of this because they are sensible enough to
not feed the troll, and instead focus on useful things. But I can't help it, I
have to say this.
On 17.10.2013, at 23:44, Felipe Contreras felipe.contre...@gmail.com wrote:
Junio C Hamano wrote:
Felipe Contreras
Max Horn wrote:
I guess most other people keep out of this because they are sensible enough
to not feed the troll, and instead focus on useful things. But I can't help
it, I have to say this.
You should probably read the definition of troll:
https://en.wikipedia.org/wiki/Troll_(Internet)
There are cases (e.g. when running concurrent fetches in a repo) where
multiple Git processes concurrently attempt to create loose objects
within the same objects/XX/ dir. The creation of the loose object files
is (AFAICS) safe from races, but the creation of the objects/XX/ dir in
which the loose
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/17/2013 5:14 PM, Junio C Hamano wrote:
Correct.
Without inspecting them, you would not know what you would be
losing by blindly resolving to removal, hence we do not
auto-resolve one side removed, the other side changed to a
removal.
On Fri, Oct 18, 2013 at 9:17 AM, Johan Herland jo...@herland.net wrote:
There are cases (e.g. when running concurrent fetches in a repo) where
multiple Git processes concurrently attempt to create loose objects
within the same objects/XX/ dir. The creation of the loose object files
is (AFAICS)
On Fri, Oct 18, 2013 at 8:17 PM, Johan Herland jo...@herland.net wrote:
diff --git a/sha1_file.c b/sha1_file.c
index f80bbe4..00e 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2857,7 +2857,9 @@ static int create_tmpfile(char *buffer, size_t bufsiz,
const char *filename)
On Fri, Oct 18, 2013 at 8:55 PM, Duy Nguyen pclo...@gmail.com wrote:
On Fri, Oct 18, 2013 at 8:17 PM, Johan Herland jo...@herland.net wrote:
diff --git a/sha1_file.c b/sha1_file.c
index f80bbe4..00e 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2857,7 +2857,9 @@ static int
On Fri, Oct 18, 2013 at 3:53 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Fri, Oct 18, 2013 at 9:17 AM, Johan Herland jo...@herland.net wrote:
There are cases (e.g. when running concurrent fetches in a repo) where
multiple Git processes concurrently attempt to create loose objects
On Fri, Oct 18, 2013 at 06:41:41AM -0500, Felipe Contreras wrote:
And I hazard to guess that the vast majority agree with Junio on this
(based,
again, on email evidence). Not with you.
That is irrelevant, and a fallacy. The vast majority of people thought the
Earth was the center of the
On Fri, Oct 18, 2013 at 4:00 PM, Duy Nguyen pclo...@gmail.com wrote:
On Fri, Oct 18, 2013 at 8:55 PM, Duy Nguyen pclo...@gmail.com wrote:
On Fri, Oct 18, 2013 at 8:17 PM, Johan Herland jo...@herland.net wrote:
diff --git a/sha1_file.c b/sha1_file.c
index f80bbe4..00e 100644
---
I've just completed a task involving two releases of a piece of embedded
software and an attempt to integrate portions of one into the other. My
comments:
Git is just *ucking incredible!
Very well done people...
Nick
--
To unsubscribe from this list: send the line unsubscribe git
On Fri, Oct 18, 2013 at 10:52 AM, Johan Herland jo...@herland.net wrote:
On Fri, Oct 18, 2013 at 3:53 PM, Eric Sunshine sunsh...@sunshineco.com
wrote:
On Fri, Oct 18, 2013 at 9:17 AM, Johan Herland jo...@herland.net wrote:
There are cases (e.g. when running concurrent fetches in a repo) where
Theodore Ts'o wrote:
On Fri, Oct 18, 2013 at 06:41:41AM -0500, Felipe Contreras wrote:
And I hazard to guess that the vast majority agree with Junio on this
(based,
again, on email evidence). Not with you.
That is irrelevant, and a fallacy. The vast majority of people thought the
Theodore Ts'o ty...@mit.edu writes:
Over the past 5+ years, I've observed that I
think the way commit selection in git format-patch is inconsistent
with how we handle commit selection for other commands, e.g., git log
commit vs and git format-patch commit. Even if you think that
this is a
git-fast-import documentation says that paths can be C-style quoted.
Unfortunately, the current remote-hg helper doesn't unquote quoted
path and pass them as-is to Mercurial when the commit is created.
This result in the following situation:
- clone a mercurial repository with git
- Add a file
Jeff King p...@peff.net writes:
+ * Our basic strategy is to compare base and asked to find the bits
+ * specific to our request. We then strip those bits off of got to yield
the
+ * new base. So for example, if our base is http://example.com/foo.git;,
+ * and we ask for
On Fri, Oct 18, 2013 at 11:25:13AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
+ * Our basic strategy is to compare base and asked to find the bits
+ * specific to our request. We then strip those bits off of got to yield
the
+ * new base. So for example, if our base
On Fri, Oct 18, 2013 at 05:41:54PM +0200, Johan Herland wrote:
(c) mkdir() fails with EEXIST, i.e. we lost the race. We do the
adjust_shared_perms() which might fail (- abort) or succeed, and we
then _retry_ the git_mkstemp_mode(). There is no case where the
whatever that happened between
Karsten Blees karsten.bl...@gmail.com writes:
The coredumps are caused by my patch #10, which free()s
cache_entries when they are removed, in combination with ...
Looking at that patch, it makes me wonder if remove_index_entry_at()
and replace_index_entry() should be the ones that frees the
Jeff King p...@peff.net writes:
On Fri, Oct 18, 2013 at 11:25:13AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
+ * Our basic strategy is to compare base and asked to find the bits
+ * specific to our request. We then strip those bits off of got to
yield the
+ * new
Jeff King p...@peff.net writes:
I was almost tempted to say we do not even need to run
adjust_shared_perm twice, but we do, or we risk another race: one side
loses the mkdir race, but wins the open() race, and writes to a
wrong-permission directory. Of course, that should not matter unless
Am 18.10.2013 02:42, schrieb Karsten Blees:
Am 17.10.2013 23:07, schrieb Junio C Hamano:
Junio C Hamano gits...@pobox.com writes:
Karsten Blees karsten.bl...@gmail.com writes:
Am 16.10.2013 23:43, schrieb Junio C Hamano:
* kb/fast-hashmap (2013-09-25) 6 commits
- fixup! diffcore-rename.c:
Am 18.10.2013 21:09, schrieb Junio C Hamano:
Karsten Blees karsten.bl...@gmail.com writes:
Can't we just use add_file_to_cache here (which replaces
cache_entries by creating a copy)?
diff --git a/submodule.c b/submodule.c
index 1905d75..e388487 100644
--- a/submodule.c
+++ b/submodule.c
While I can understand 4 or 7 white spaces are fancy, we'd rather want
to use tabs throughout the whole document.
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
Documentation/git-svn.txt | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git
Commit 5fee995244e introduced the stage_updated_gitmodules() function to
add submodule configuration updates to the index. It assumed that even
after calling remove_cache_entry_at() the same cache entry would still be
valid. This was true in the old days, as cache entries could never be
freed, but
From: Jonathan Nieder jrnie...@gmail.com
Philip Oakley wrote:
It was Dale that had the problem, I was just suggesting where he might
want to look... ;-)
A bit more looking gave that the cd_to_toplevel () in git-sh-setup.sh
directly uses `git rev-parse --show-toplevel`, which simply
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
On Sat, Oct 12, 2013 at 12:26:39AM +, brian m. carlson wrote:
On Fri, Oct 11, 2013 at 04:50:52PM -0700, Jonathan Nieder wrote:
Perhaps this should be conditional on the authentication method used,
so affected people could still contact broken servers without having
different
From: Junio C Hamano gits...@pobox.com
Side note: without GIT_WORK_TREE environment (or
core.worktree), there is no way to tell where the top level
is, so you were limited to always be at the top level of
your working tree if you used GIT_DIR to refer to a
wor...@alum.mit.edu (Dale R. Worley) writes:
From: Junio C Hamano gits...@pobox.com
Side note: without GIT_WORK_TREE environment (or
core.worktree), there is no way to tell where the top level
is, so you were limited to always be at the top level of
your working tree if
From: Junio C Hamano gits...@pobox.com
Now, when you say the cwd contains the .git directory, do you mean
cd /repositories
git add ../working/trees/proj-wt1/file
updates file in the /repositories/proj.git/index? Or do you mean
this?
The pattern I use is to have this:
From: Junio C Hamano gits...@pobox.com
It was unclear to me which part of our documentation needs updating
and how, and that was (and still is) what I was primarily interested
in finding out.
It seems to me that what is missing is a description of the
circumstances under which Git can be
This updates the documentation regarding the changes introduced
by a1bbc6c01 (2013-09-15, repack: rewrite the shell script in C).
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
Documentation/git-repack.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
Am 15.10.2013 00:29, schrieb Felipe Contreras:
tl;dr: everyone except Junio C Hamano and Drew Northup agrees; we should move
away from the name the index.
It has been discussed many times in the past that 'index' is not an
appropriate description for what the high-level user does with it,
On Fri, Oct 18, 2013 at 9:24 PM, Junio C Hamano gits...@pobox.com wrote:
Jeff King p...@peff.net writes:
Agreed. We already leave a wrong-permission directory in place if it
existed before we started create_tmpfile. The code before your patch,
when racing with such a wrong-directory creator,
Karsten Blees wrote:
Am 15.10.2013 00:29, schrieb Felipe Contreras:
tl;dr: everyone except Junio C Hamano and Drew Northup agrees; we should
move
away from the name the index.
It has been discussed many times in the past that 'index' is not an
appropriate description for what the
Stefan Beller stefanbel...@googlemail.com writes:
While I can understand 4 or 7 white spaces are fancy, we'd rather want
to use tabs throughout the whole document.
You missed lines 278 and 833. There are also some spaces around line
488, but maybe those are layout-relevant and so shouldn't be
When parse_pathspec() is called with no paths, the behavior could be
either return no paths, or return one path that is cwd. Some commands
do the former, some the latter. parse_pathspec() itself does not make
either the default and requires the caller to specify either flag if
it may run into this
On Sat, Oct 19, 2013 at 01:45:03AM +0200, Johan Herland wrote:
I'm trying to mentally construct a scenario where two writers with
different configuration contexts - one with shared_repository and one
without - compete in this race, and we somehow end up with one of them
not being able to
48 matches
Mail list logo
