Am 16.08.2013 03:51, schrieb Jharrod LaFon:
> Git fails due to a segmentation fault if a submodule path is empty.
> Here is an example .gitmodules that will cause a segmentation fault:
> [submodule "foo-module"]
> path
> url = http://host/repo.git
> $ git status
> Segmentation fault (core d
On Fri, 16 Aug 2013 00:17:27 -0400
Eric Sunshine wrote:
> On Thu, Aug 15, 2013 at 6:35 PM, Mattias Andrée
> wrote:
> > This can be used for automated bisection without a
> > check script.
> >
> > Signed-off-by: Mattias Andrée
> > ---
> > Documentation/git-bisect.txt | 13 +
> > git
On Thu, Aug 15, 2013 at 6:35 PM, Mattias Andrée wrote:
> This can be used for automated bisection without a check script.
>
> Signed-off-by: Mattias Andrée
> ---
> Documentation/git-bisect.txt | 13 +
> git-bisect.sh| 11 ++-
> 2 files changed, 23 insertions(+
On Thu, 15 Aug 2013, Eric Sunshine wrote:
> On Thu, Aug 15, 2013 at 5:34 PM, Stefan Beller
> wrote:
> > When checking the previous lines in that function, we can deduce that
> > hsize must always be smaller than (1u<<31), since 506049c7df2c6
> > (fix >4GiB source delta assertion failure), because
On Thu, 15 Aug 2013, Junio C Hamano wrote:
> Forwarding to the area expert...
>
> Stefan Beller writes:
>
> > When checking the previous lines in that function, we can deduct that
> > hsize must always be smaller than (1u<<31), since 506049c7df2c6
> > (fix >4GiB source delta assertion failure),
Changes since v6:
* s/broken/gone/ in [PATCH 2/3] (branch: mark missing tracking branch
as gone)
* rewrite commit log for [PATCH 3/3] (status: always show tracking
branch even no change)
Jiang Xin (3):
branch: not report invalid tracking branch
branch: mark missing tracking branch as gon
If a branch has been set to track a upstream, but the upstream branch
is missing, the tracking info is silently ignored in the output of
some commands such as "git branch -vv" and "git status", as if there
were no such tracking settings.
Junio suggested missing upstream should be reported [1], suc
Command "git branch -vv" will report tracking branches, but invalid
tracking branches are also reported. This is because the function
stat_tracking_info() can not distinguish whether the upstream branch
does not exist, or nothing is changed between one branch and its
upstream.
This patch changes t
In order to see what the current branch is tracking, one way is using
"git branch -v -v", but branches other than the current are also
reported. Another way is using "git status", such as:
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
...
B
Git fails due to a segmentation fault if a submodule path is empty.
Here is an example .gitmodules that will cause a segmentation fault:
[submodule "foo-module"]
path
url = http://host/repo.git
$ git status
Segmentation fault (core dumped)
This occurs because in the function parse_submodul
ksaitoh...@gmail.com wrote on Wed, 14 Aug 2013 09:59 +0900:
> > My only concern is in the commit message, about performance. A
> > change that has lots of files in it will cause many roundtrips to
> > p4d to do "p4 where" on each. When the files don't have much
> > edited content, this new approa
This is the beginning of the rewrite of the repacking.
* Removed unneeded system header files
* corrected remove_pack to really remove any pack files with the given
sha1
* fail if pack-objects fails
* Only test t7701 (2nd) fails now with this patch.
Signed-off-by: Stefan Beller
---
Make
On Tue, Aug 13, 2013 at 1:31 AM, Luke San Antonio
wrote:
>
> So I found an isolated case, it's very strange...
>
> Here's a script!
>
>
Thanks for that. It was hard to read, but it demonstrates the problem well.
> ... Copy and paste that into a terminal and you should have a recreated
> versi
From: Petr Baudis
"stash save" is about saving the local change to the working tree,
but also about restoring the state of the last commit to the working
tree. When a local change is to turn a non-directory to a directory,
in order to restore the non-directory, everything in the directory
needs
Jiang Xin writes:
> In order to see what the current branch is tracking, one way is using
> "git branch -v -v", but branches other than the current are also
> reported. Another way is using "git status", such as:
>
> $ git status
> # On branch master
> # Your branch is ahead of 'origi
Jiang Xin writes:
> /*
> - * Return false if cannot stat a tracking branch (not exist or invalid),
> - * otherwise true.
> + * Compare a branch with its tracking branch, and save their differences
> + * (number of commits) in *num_ours and *num_theirs.
> + *
> + * Return 0 if branch has no upstr
This can be used for automated bisection without a check script.
Signed-off-by: Mattias Andrée
---
Documentation/git-bisect.txt | 13 +
git-bisect.sh| 11 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-bisect.txt b/Documen
Junio C Hamano writes:
> ... we may have to restrict "is available" a bit
> tighter.
As Eric pointed out, that "bit tighter" opt-in could just be an
explicit use of --cc-cmd option to specify this script ;-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mess
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
Due to unfortunate regressions, two topics had to be reverted:
* An attempted fix to "git stash save", to detect that going back
to the sta
Stefan Beller writes:
> I have got an idea regarding the send-email. If there are no recipients
> given, it could propose recipients using the new 'git contacts'
> This would help people new to projects to not forget people, who may have
> the most knowledge reviewing that specific patch.
>
> Unf
On Thu, Aug 15, 2013 at 6:17 PM, Stefan Beller
wrote:
> I have got an idea regarding the send-email. If there are no recipients
> given, it could propose recipients using the new 'git contacts'
> This would help people new to projects to not forget people, who may have
> the most knowledge reviewi
I have got an idea regarding the send-email. If there are no recipients
given, it could propose recipients using the new 'git contacts'
This would help people new to projects to not forget people, who may have
the most knowledge reviewing that specific patch.
Unfortunately I cannot read/write perl
From: "Stefan Beller"
When checking the previous lines in that function, we can deduce that
hsize must always be smaller than (1u<<31), since 506049c7df2c6
(fix >4GiB source delta assertion failure), because entries is
capped at an upper bound of 0xfffeU, so hsize contains a maximum
value of
Nicolas,
I am sorry for not including you in the first mail.
Just before Junio included you, there were these 2 mails
http://www.mail-archive.com/git@vger.kernel.org/msg34101.html
http://www.mail-archive.com/git@vger.kernel.org/msg34103.html
Stefan
On 08/15/2013 11:43 PM, Junio C Hamano wrote:
>
On Thu, Aug 15, 2013 at 5:34 PM, Stefan Beller
wrote:
> When checking the previous lines in that function, we can deduce that
> hsize must always be smaller than (1u<<31), since 506049c7df2c6
> (fix >4GiB source delta assertion failure), because entries is
> capped at an upper bound of 0xfffeU
Forwarding to the area expert...
Stefan Beller writes:
> When checking the previous lines in that function, we can deduct that
> hsize must always be smaller than (1u<<31), since 506049c7df2c6
> (fix >4GiB source delta assertion failure), because the entries is
> capped at an upper bound of 0xff
When checking the previous lines in that function, we can deduce that
hsize must always be smaller than (1u<<31), since 506049c7df2c6
(fix >4GiB source delta assertion failure), because entries is
capped at an upper bound of 0xfffeU, so hsize contains a maximum
value of 0x3fff, which is sma
An earlier draft of the previous step used cache_name_exists() to
check the directory we were looking at, which missed the second case
described in its log message. Demonstrate why it is not sufficient.
Signed-off-by: Junio C Hamano
---
t/t3010-ls-files-killed-modified.sh | 12 +---
1 f
"ls-files -o" and "ls-files -k" both traverse the working tree down
to find either all untracked paths or those that will be "killed"
(removed from the working tree to make room) when the paths recorded
in the index are checked out. It is necessary to traverse the
working tree fully when enumerati
These codepaths always start from the_index and use index_*
functions, but there is no reason to do so. Use the compatibility
cache_* macro to access the current in-core index like everybody
else.
While at it, fix typo in the comment for a function to check if a
path within a directory appears in
"ls-files -o" and "ls-files -k" both traverse the working tree down
to find either all untracked paths or those that will be "killed"
(removed from the working tree to make room) when the paths recorded
in the index are checked out.
It is necessary to traverse the working tree fully when enumerati
On Thu, Aug 15, 2013 at 3:37 PM, Stefan Beller
wrote:
> When checking the previous lines in that function, we can deduct that
s/deduct/deduce/
> hsize must always be smaller than (1u<<31), since 506049c7df2c6
> (fix >4GiB source delta assertion failure), because the entries is
s/the entries/ent
On 08/15/2013 10:50 PM, Benoît Legat wrote:
> Hello everyone,
>
> I think I have just found a bug in Git which basically occurs when I run
> `git log HEAD` in a detached HEAD state.
> To reproduce it, just run
> $ git init
> ...
> $ touch tmp
> ...
> $ git add tmp
> $ git commit -m "tmp"
> ...
> $
Hello everyone,
I think I have just found a bug in Git which basically occurs when I run
`git log HEAD` in a detached HEAD state.
To reproduce it, just run
$ git init
...
$ touch tmp
...
$ git add tmp
$ git commit -m "tmp"
...
$ git checkout
...
$ git branch HEAD
Segmentation fault (core dumpe
Junio C Hamano writes:
> diff --git a/dir.c b/dir.c
> index 910bfcd..02939e2 100644
> --- a/dir.c
> +++ b/dir.c
> @@ -1183,6 +1183,15 @@ static enum path_treatment treat_one_path(struct
> dir_struct *dir,
> cache_name_exists(path->buf, path->len, ignore_case))
> return pa
When checking the previous lines in that function, we can deduct that
hsize must always be smaller than (1u<<31), since 506049c7df2c6
(fix >4GiB source delta assertion failure), because the entries is
capped at an upper bound of 0xfffeU, so hsize contains a maximum
value of 0x3fff, which is
A little background on hash tables first:
Consider you want to have the object X, which you'd expect at position
i, but because that place was already taken by B, it is not found at
position i, you start looking right of position i to find X until you
find it.
index | i-1 | i | i+1 | i
On Thu, Aug 15, 2013 at 7:31 PM, Junio C Hamano wrote:
> While the last statement applies to other parts of the system, it is
> not true for the in-core index design. We always had a flat index,
> and it is not cheating at all. The original "tree" was also a flat
> representation of everything u
Josh Triplett writes:
>> I've already reverted the problematic patch to "git stash" and it
>> will not be part of the upcoming release.
>
> Thanks!
>
>> Here is a quick attempt to see if we can do better in "ls-files -k".
Having said that, I am curious if the result of applying the patch
you are
Jiang Xin writes:
> If a branch has been set to track a upstream, but the upstream branch
> is missing or invalid, the tracking info is silently ignored in the
> output of some commands such as "git branch -vv" and "git status",
> as if there were no such tracking settings.
>
> Junio suggested br
If a branch has been set to track a upstream, but the upstream branch
is missing or invalid, the tracking info is silently ignored in the
output of some commands such as "git branch -vv" and "git status",
as if there were no such tracking settings.
Junio suggested broken upstream should be reporte
In order to see what the current branch is tracking, one way is using
"git branch -v -v", but branches other than the current are also
reported. Another way is using "git status", such as:
$ git status
# On branch master
# Your branch is ahead of 'origin/master' by 1 commit.
...
B
Command "git branch -vv" will report tracking branches, but invalid
tracking branches are also reported. This is because the function
stat_tracking_info() can not distinguish whether the upstream branch
does not exist, or nothing is changed between one branch and its
upstream.
This patch changes t
On Thu, Aug 15, 2013 at 10:52:39AM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > In any case, this is a regression introduced in 'master' since the
> > last release, and the attempted fix was for an issue that has long
> > been with us, so I'll revert a7365313 (git stash: avoid data
Junio C Hamano writes:
> In any case, this is a regression introduced in 'master' since the
> last release, and the attempted fix was for an issue that has long
> been with us, so I'll revert a7365313 (git stash: avoid data loss
> when "git stash save" kills a directory, 2013-06-28) soon. For
>
On Thu, Aug 15, 2013 at 10:28:16AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Unfortunately, I think that will require some refactoring of the
> > run_hook interface, which does not allow arbitrary environment
> > parameters to be set.
>
> Heh, I said that long time ago, e.g. $gmane
Andreas Ericsson writes:
> You seem to believe that the in-memory representation of trees have to
> be the same as the on-disk one. That's simply not true. Git cheats
> outrageously with internal formats for pretty much everything in order
> to squeeze out more performance.
While the last statem
Jeff King writes:
> Unfortunately, I think that will require some refactoring of the
> run_hook interface, which does not allow arbitrary environment
> parameters to be set.
Heh, I said that long time ago, e.g. $gmane/212284 ;-)
This might turn out to be a good starting point, even though I
did
Martin Fick writes:
> On Wednesday, August 14, 2013 04:53:36 pm Junio C Hamano
> wrote:
>> Martin Fick writes:
>> > One suggestion would be to change the repack code to
>> > create pack filenames based on the sha1 of the
>> > contents of the pack file instead of on the sha1 of
>> > the objects
I've had good success recently with the git->bzr bridge, but the
following still fails. This is on Debian with the git from "unstable".
Stefan
% git clone bzr::bzr://bzr.savannah.nongnu.org/enwc/trunk
Cloning into 'trunk'...
Note: checking out 'e8fa1a2339729de62d0ad85e44b8993bf25b7996'
It is Private
I am George Daniels, a Banker and credit system programmer (HSBC bank).
I saw your email address while browsing through the bank D.T.C Screen in
my office yesterday so I decided to use this very chance to know you. I
believe we should use every opportunity to know each other better.
On Thursday, August 15, 2013 01:46:02 am Stefan Beller
wrote:
> On 08/15/2013 01:25 AM, Martin Fick wrote:
> > On Wednesday, August 14, 2013 04:51:14 pm Matthieu Moy
> >
> > wrote:
> >> Antoine Pelisse writes:
> >>> On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
> >>>
> >>> wrote:
> buil
On Thu, Aug 15, 2013 at 2:32 AM, Ben Tebulin wrote:
> Just as a catchup for everybody being interested:
>
> I finally wrote to the linux-mm newsgroup and Linus pointed out, that
> this might be a known bug yet not fixed in mainline.
>
> Unfortunately this doesn't seem to stand the test; but as far
On 2013-08-15 12:35, John Keeping wrote:
Just a follow-up, I tried it within the "bash"ish shell
included in the git install and got the same error regarding
"/tmp/report.tmp".
>>>
>>> It seems that report.tmp is something that SVN creates and for
>>> some reason the svn on your sys
Greetings to you my Dear Beloved, my name is Gina Rinehart, a great citizen of
Australia,born in Perth, Western Australia,I have a mission for you worth
($200,000,000 000.)Tow Hundred Million Dollars which I intend to use for
CHARITY.Please reply if interested with this email below.
Email: ge
On 2013-08-15 12:29, Erik Bernoth wrote:
Hi,
I'm currently trying to understand the inner workings of git better by
writing a git clone in Python. I find it rather hard to understand how
to efficiently use trees.
What I understand is this: Trees are in essence blobs with a specific
content. The
On Thu, Aug 15, 2013 at 12:43:39AM -0400, Matan Nassau wrote:
> With git 1.8.3.3,
>
> $ seq 5 >data
> $ git add data
> $ git commit -mdata
> $ sed -i '2 d' data
> $ git commit -pmchange
>
> At the prompt, type e to edit the hunk. The editor doesn't start, but
> git records a commit.
>
> I
On Thu, Aug 15, 2013 at 06:33:11AM +, Damien Robert wrote:
> git init
> git commit --allow-empty -m "init"
> git checkout -b test
> echo foo > foo
> git add foo
> git commit -am 'add foo'
> git checkout master
> echo 'Important data' > foo #[1]
> echo foo > .gitignore
> git checkout test
>
>
On Thu, Aug 15, 2013 at 06:12:29AM -0500, Tim Chase wrote:
> On 2013-08-15 09:00, John Keeping wrote:
> > On Wed, Aug 14, 2013 at 06:26:57PM -0500, Tim Chase wrote:
> > > On 2013-08-14 12:49, Tim Chase wrote:
> > > > If it makes any difference, this is within a cmd.exe shell (with
> > > > $PATH set
On 2013-08-15 09:00, John Keeping wrote:
> On Wed, Aug 14, 2013 at 06:26:57PM -0500, Tim Chase wrote:
> > On 2013-08-14 12:49, Tim Chase wrote:
> > > If it makes any difference, this is within a cmd.exe shell (with
> > > $PATH set appropriately so git is being found).
> >
> > Just a follow-up, I t
Hi,
I'm currently trying to understand the inner workings of git better by
writing a git clone in Python. I find it rather hard to understand how
to efficiently use trees.
What I understand is this: Trees are in essence blobs with a specific
content. The content is a relation between other blobs
Just as a catchup for everybody being interested:
I finally wrote to the linux-mm newsgroup and Linus pointed out, that
this might be a known bug yet not fixed in mainline.
Unfortunately this doesn't seem to stand the test; but as far as Git is
concerned, it appears that that they are willing to
On 08/14/2013 09:57 PM, Junio C Hamano wrote:
> Johannes Sixt writes:
>
> [SNIP]
>
>> Stefano's use-case, where @/foo is turned into HEAD/foo,
>> indicates a bug.
>>
>> In my opinion, the topic, which touches a central part of ref
>> handling, was a bit hurried (and this report is a symptom of it
On Wed, Aug 14, 2013 at 06:26:57PM -0500, Tim Chase wrote:
> On 2013-08-14 12:49, Tim Chase wrote:
> > If it makes any difference, this is within a cmd.exe shell (with
> > $PATH set appropriately so git is being found).
>
> Just a follow-up, I tried it within the "bash"ish shell included in
> the
On 08/14/2013 07:04 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> diff --git a/builtin/repack.c b/builtin/repack.c
>> new file mode 100644
>> index 000..d39c34e
>> --- /dev/null
>> +++ b/builtin/repack.c
>> @@ -0,0 +1,410 @@
>> +/*
>> + * The shell version was written by Linus Torval
On 08/15/2013 12:59 AM, Matthieu Moy wrote:
> Junio C Hamano writes:
>
>> Stefan Beller writes:
>>
>>> I asked for a todo wish list a few weeks ago, but got no real answer,
>>> but rather: "Pick your choice and try to come up with good patches".
>>
>> Hmph, I hope that wasn't me.
>>
>> There are
On 08/15/2013 01:25 AM, Martin Fick wrote:
> On Wednesday, August 14, 2013 04:51:14 pm Matthieu Moy
> wrote:
>> Antoine Pelisse writes:
>>> On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
>>>
>>> wrote:
builtin/repack.c | 410
+
>>>
67 matches
Mail list logo
