On Fri, Oct 18, 2013 at 03:14:49PM -0700, Junio C Hamano wrote:
> * jn/add-2.0-u-A-sans-pathspec (2013-04-26) 1 commit
> - git add: -u/-A now affects the entire working tree
>
> Will cook in 'next' until Git 2.0.
>
>
> * jc/core-checkstat-2.0 (2013-05-06) 1 commit
> - core.statinfo: remove a
OH Mein persönlicher GAWD - Also ich bin in schätzen neben unserer neuen
Sneakers! Ich geworden , wenn immer die Finger für eine Reihe von Nike
Breeze Max 1 ist, als dass sie wieder erschien auf der städtischen Szene in
bunten Schuhen zusätzlich verrückt Arten - Einbau , dass die fabelhafte
animal
Yoshioka Tsuneo writes:
> "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 filen
Nike sind alle freiberuflich Schuster, der hatte eine beispielhafte Befehl
über Turnschuhe bekommen . seine Turnschuhe mit Qualität billig Nike No-cost
Runs und eine Menge wünschenswert Womens Nike kommen kostenlos betrieben
drei .
Zusammen mit erweiterten Begriff Verbesserung hat Nike Unternehmen
[Unfortunately libgit2 no longer has a mailing list. I put an arbitrary
group of libgit2 contributors in the Cc list.]
Previous Episodes
=
Git participated in Google Summer of Code (GSoC) 2007-2012, but did not
participate in 2013 based on discussion in February [1]. At Git-Mer
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 w
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
Stefan Beller 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 converted
to tabs.
-Kesh
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 f
On Fri, Oct 18, 2013 at 9:24 PM, Junio C Hamano wrote:
> Jeff King 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, would abort the
>> tmpfil
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
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
---
Documentation/git-repack.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-repack.txt b/Docum
> From: Junio C Hamano
> 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 run. With Subver
> From: Junio C Hamano
> 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:
wor...@alum.mit.edu (Dale R. Worley) writes:
>> From: Junio C Hamano
>
>> 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 use
> From: Junio C Hamano
> 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
> repository that
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 confi
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
http://git-blame.blogspot.com/p/git-publi
From: "Jonathan Nieder"
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 returns
work_tree (sta
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
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
---
Documentation/git-svn.txt | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-svn.txt b/Do
Am 18.10.2013 21:09, schrieb Junio C Hamano:
> Karsten Blees 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
>> @@ -116,
Am 18.10.2013 02:42, schrieb Karsten Blees:
> Am 17.10.2013 23:07, schrieb Junio C Hamano:
>> Junio C Hamano writes:
>>
>>> Karsten Blees writes:
>>>
Am 16.10.2013 23:43, schrieb Junio C Hamano:
> * kb/fast-hashmap (2013-09-25) 6 commits
> - fixup! diffcore-rename.c: simplify findin
Jeff King 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 the
> race
Jeff King writes:
> On Fri, Oct 18, 2013 at 11:25:13AM -0700, Junio C Hamano wrote:
>
>> Jeff King 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 bas
Karsten Blees 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 old
entry in the first p
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 betw
On Fri, Oct 18, 2013 at 11:25:13AM -0700, Junio C Hamano wrote:
> Jeff King 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 bas
Jeff King 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 "http://example.com/
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 wi
Theodore Ts'o 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
> " vs and "git format-patch ". Even if you think that
> this is a matter of self-i
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
On Fri, Oct 18, 2013 at 10:52 AM, Johan Herland wrote:
> On Fri, Oct 18, 2013 at 3:53 PM, Eric Sunshine
> wrote:
>> On Fri, Oct 18, 2013 at 9:17 AM, Johan Herland wrote:
>>> There are cases (e.g. when running concurrent fetches in a repo) where
>>> multiple Git processes concurrently attempt to
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 4:00 PM, Duy Nguyen wrote:
> On Fri, Oct 18, 2013 at 8:55 PM, Duy Nguyen wrote:
>> On Fri, Oct 18, 2013 at 8:17 PM, Johan Herland 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
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 cente
On Fri, Oct 18, 2013 at 3:53 PM, Eric Sunshine wrote:
> On Fri, Oct 18, 2013 at 9:17 AM, Johan Herland 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 cr
On Fri, Oct 18, 2013 at 8:55 PM, Duy Nguyen wrote:
> On Fri, Oct 18, 2013 at 8:17 PM, Johan Herland 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 b
On Fri, Oct 18, 2013 at 8:17 PM, Johan Herland 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)
> /* Make s
On Fri, Oct 18, 2013 at 9:17 AM, Johan Herland 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) safe from rac
-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
> remova
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
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)
U
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 wrote:
> Junio C Hamano wrote:
>> Felipe Contreras writes:
>>
>>> Junio C
On 17.10.2013, at 21:50, Junio C Hamano wrote:
> Felipe Contreras 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 everyday phrase or common CS
> lin
On Fri, Oct 18, 2013 at 4:46 AM, Matthieu Moy
wrote:
> I'm lacking time to read and answer in detail, sorry.
>
> Junio C Hamano 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, a
On Fri, Oct 18, 2013 at 5:46 AM, Matthieu Moy
wrote:
> I'm lacking time to read and answer in detail, sorry.
>
> Junio C Hamano 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, a
I'm lacking time to read and answer in detail, sorry.
Junio C Hamano 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 not sure exac
"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 to
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/nameOfTheFileTh
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 checkou
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
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
53 matches
Mail list logo
