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
If I tried a `git checkout test` after [1], I would get the error message
error: The
On Wed, Aug 14, 2013 at 09:39:10AM -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com writes:
This does not have anything to do with C, but is a breakage in our
autoconf script.
I've meant C-programmers does understand autoconf, too. But I do not :(.
It appears that anything
On 08/15/2013 01:25 AM, Martin Fick wrote:
On Wednesday, August 14, 2013 04:51:14 pm Matthieu Moy
wrote:
Antoine Pelisse apeli...@gmail.com writes:
On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
builtin/repack.c | 410
On 08/15/2013 12:59 AM, Matthieu Moy wrote:
Junio C Hamano gits...@pobox.com writes:
Stefan Beller stefanbel...@googlemail.com 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
On 08/14/2013 07:04 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com 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
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 bashish shell included in
the git
On 08/14/2013 09:57 PM, Junio C Hamano wrote:
Johannes Sixt j...@kdbg.org 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
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
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
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 tried it
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 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
If I tried a
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 found that
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.
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:
On 2013-08-15 12:35, John Keeping wrote:
Just a follow-up, I tried it within the bashish 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 system is trying to create
On Thu, Aug 15, 2013 at 2:32 AM, Ben Tebulin tebu...@googlemail.com 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
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 apeli...@gmail.com writes:
On Wed, Aug 14, 2013 at 6:27 PM, Stefan Beller
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'.
Martin Fick mf...@codeaurora.org writes:
On Wednesday, August 14, 2013 04:53:36 pm Junio C Hamano
wrote:
Martin Fick mf...@codeaurora.org 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
Jeff King p...@peff.net 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
Andreas Ericsson a...@op5.se 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
On Thu, Aug 15, 2013 at 10:28:16AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net 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.
Junio C Hamano gits...@pobox.com 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)
On Thu, Aug 15, 2013 at 10:52:39AM -0700, Junio C Hamano wrote:
Junio C Hamano gits...@pobox.com 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:
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
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.
...
But
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 reported
Jiang Xin worldhello@gmail.com 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.
Josh Triplett j...@joshtriplett.org 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
On Thu, Aug 15, 2013 at 7:31 PM, Junio C Hamano gits...@pobox.com 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
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 |
When checking the previous lines in that function, we can deduct that
hsize must always be smaller than (1u31), 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
Junio C Hamano gits...@pobox.com 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))
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 commit_sha
...
$ git branch HEAD
Segmentation fault
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
...
$ git checkout
On Thu, Aug 15, 2013 at 3:37 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
When checking the previous lines in that function, we can deduct that
s/deduct/deduce/
hsize must always be smaller than (1u31), since 506049c7df2c6
(fix 4GiB source delta assertion failure), because the entries
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 enumerating
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
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 enumerating
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 gits...@pobox.com
---
t/t3010-ls-files-killed-modified.sh | 12
When checking the previous lines in that function, we can deduce that
hsize must always be smaller than (1u31), 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
Forwarding to the area expert...
Stefan Beller stefanbel...@googlemail.com writes:
When checking the previous lines in that function, we can deduct that
hsize must always be smaller than (1u31), since 506049c7df2c6
(fix 4GiB source delta assertion failure), because the entries is
capped at
On Thu, Aug 15, 2013 at 5:34 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
When checking the previous lines in that function, we can deduce that
hsize must always be smaller than (1u31), since 506049c7df2c6
(fix 4GiB source delta assertion failure), because entries is
capped at an upper
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:
From: Stefan Beller stefanbel...@googlemail.com
When checking the previous lines in that function, we can deduce that
hsize must always be smaller than (1u31), since 506049c7df2c6
(fix 4GiB source delta assertion failure), because entries is
capped at an upper bound of 0xfffeU, so hsize
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
On Thu, Aug 15, 2013 at 6:17 PM, Stefan Beller
stefanbel...@googlemail.com 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
Stefan Beller stefanbel...@googlemail.com 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
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
Junio C Hamano gits...@pobox.com 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
This can be used for automated bisection without a check script.
Signed-off-by: Mattias Andrée maand...@operamail.com
---
Documentation/git-bisect.txt | 13 +
git-bisect.sh| 11 ++-
2 files changed, 23 insertions(+), 1 deletion(-)
diff --git
Jiang Xin worldhello@gmail.com 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
Jiang Xin worldhello@gmail.com 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
From: Petr Baudis pa...@ucw.cz
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
On Tue, Aug 13, 2013 at 1:31 AM, Luke San Antonio
lukesananto...@gmail.com wrote:
So I found an isolated case, it's very strange...
Here's a script!
deleted
Thanks for that. It was hard to read, but it demonstrates the problem well.
... Copy and paste that into a terminal and you should
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
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 approach will
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
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
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.
...
But
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
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], such
On Thu, 15 Aug 2013, Junio C Hamano wrote:
Forwarding to the area expert...
Stefan Beller stefanbel...@googlemail.com writes:
When checking the previous lines in that function, we can deduct that
hsize must always be smaller than (1u31), since 506049c7df2c6
(fix 4GiB source delta
On Thu, 15 Aug 2013, Eric Sunshine wrote:
On Thu, Aug 15, 2013 at 5:34 PM, Stefan Beller
stefanbel...@googlemail.com wrote:
When checking the previous lines in that function, we can deduce that
hsize must always be smaller than (1u31), since 506049c7df2c6
(fix 4GiB source delta assertion
On Thu, Aug 15, 2013 at 6:35 PM, Mattias Andrée maand...@operamail.com wrote:
This can be used for automated bisection without a check script.
Signed-off-by: Mattias Andrée maand...@operamail.com
---
Documentation/git-bisect.txt | 13 +
git-bisect.sh| 11
On Fri, 16 Aug 2013 00:17:27 -0400
Eric Sunshine sunsh...@sunshineco.com wrote:
On Thu, Aug 15, 2013 at 6:35 PM, Mattias Andrée
maand...@operamail.com wrote:
This can be used for automated bisection without a
check script.
Signed-off-by: Mattias Andrée maand...@operamail.com
---
67 matches
Mail list logo
