Re: [msysGit] 4th release candidate of Git for Windows 2.x, was Re: 3rd release candidate of Git for Windows 2.x
Am 29.06.2015 um 16:37 schrieb Johannes Schindelin:
Hi Stefan,
On 2015-06-29 11:07, Stefan Näwe wrote:
Am 29.06.2015 um 10:30 schrieb Johannes Schindelin:
I just uploaded the 4th release candidate for the upcoming Git for
Windows 2.x release. Please find the download link here:
https://git-for-windows.github.io/#download
The most important changes are the update to Git 2.4.5 and a fix for the
crash when running Git Bash
with a legacy `TERM` setting (this should help 3rd party software to
upgrade to Git for Windows 2.x).
Thanks.
It seems that this link:
https://github.com/git-for-windows/git/releases/latest
doesn't point to the latest release.
Might be because the tags have the same date ?
Wooops. Sorry for being so slow (been interviewing today). It should be
correct now, can you verify, please?
Yes.
https://github.com/git-for-windows/git/releases/latest
redirects to Fourth release candidate of Git for Windows 2.x now.
Thanks,
Stefan
--
/dev/random says: Documentation is the castor oil of programming.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] 4th release candidate of Git for Windows 2.x, was Re: 3rd release candidate of Git for Windows 2.x
Am 29.06.2015 um 10:30 schrieb Johannes Schindelin:
Hi all,
I just uploaded the 4th release candidate for the upcoming Git for
Windows 2.x release. Please find the download link here:
https://git-for-windows.github.io/#download
The most important changes are the update to Git 2.4.5 and a fix for the
crash when running Git Bash
with a legacy `TERM` setting (this should help 3rd party software to upgrade
to Git for Windows 2.x).
Thanks.
It seems that this link:
https://github.com/git-for-windows/git/releases/latest
doesn't point to the latest release.
Might be because the tags have the same date ?
Thanks anyway!
Stefan
--
/dev/random says: Who needs comedians? Journalists are much more laughable!
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git completion not using ls-remote to auto-complete during push
Am 17.06.2015 um 18:10 schrieb Robert Dailey:
I do the following:
$ git push origin :topic
If I stop halfway through typing 'topic' and hit TAB, auto-completion
does not work if I do not have a local branch by that name (sometimes
I delete my local branch first, then I push to delete it remotely). I
thought that git completion code was supposed to use ls-remote to auto
complete refs used in push operations. Is this supposed to work?
I'm using Git 2.4.3. Tested on both MSYS2 in Windows and Linux Mint.
Same behavior in both. I am using the latest git completion code from
the master branch in the git repo.
Same here!
But it works in my self-compiled version of msysgit (yes, the old
'Git for Windows' development environment) which is rebased onto v2.2.2.
Time for 'git bisect' I guess...
Stefan
--
/dev/random says: A cat sleeps fat, yet walks thin.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] log: diagnose empty HEAD more clearly
Am 03.06.2015 um 19:24 schrieb Junio C Hamano:
Jeff King p...@peff.net writes:
My concern there would be risk of regression. I.e., that we would take
some case which used to error out and turn it into a silent noop. So I'd
prefer to keep the behavior the same, and just modify the error code
path. The end result is pretty similar to the user, because we obviously
cannot produce any actual output either way.
Okay.
Something like:
-- 8 --
Subject: log: diagnose empty HEAD more clearly
If you init or clone an empty repository, the initial
message from running git log is not very friendly:
$ git init
Initialized empty Git repository in /home/peff/foo/.git/
$ git log
fatal: bad default revision 'HEAD'
Let's detect this situation and write a more friendly
message:
$ git log
fatal: default revision 'HEAD' points to an unborn branch 'master'
We also detect the case that 'HEAD' points to a broken ref;
this should be even less common, but is easy to see. Note
that we do not diagnose all possible cases. We rely on
resolve_ref, which means we do not get information about
complex cases. E.g., --default master would use dwim_ref
to find refs/heads/master, but we notice only that
master does not exist. Similarly, a complex sha1
expression like --default HEAD^2 will not resolve as a
ref.
But that's OK. We fall back to the existing error message in
those cases, and they are unlikely to be used anyway.
Catching an empty or broken HEAD improves the common case,
and the other cases are not regressed.
Signed-off-by: Jeff King p...@peff.net
---
I'm not a big fan of the new error message, either, just because the
term unborn is also likely to be confusing to new users.
We can also probably get rid of mentioning HEAD completely. It is
always the default unless the user has overridden it explicitly.
I think that still mentioning HEAD goes directly against the
reasoning you made in an earlier part of your message:
I think it is one of those cases where the message makes sense when you
know how git works. But a new user who does not even know what HEAD or
a ref actually is may find it a bit confusing. Saying we can't run
git-log, your repository empty! may seem redundantly obvious even to
such a new user. But saying bad revision 'HEAD' may leave them saying
eh, what is HEAD and why is it bad?.
and I agree with that reasoning: the user didn't say anything about
HEAD, so why complain about it?
Which is what led me to say Why are we defaulting to HEAD before
checking if it even exists? Isn't that the root cause of this
confusion? What happens if we stopped doing it?
And I think the diagnose after finding that pending is empty and we
were given 'def' approach almost gives us the equivalent, which is
why I said Okay above.
If we can make it possible to tell if that def was given by the
user (i.e. --default parameter) or by the machinery (e.g. git log
and friends), then we can remove almost from the above sentence.
So we
could go with something like:
fatal: your default branch 'master' does not contain any commits
or something. I dunno. Bikeshed colors welcome. Adding:
advise(try running 'git commit');
is probably too pedantic. ;)
;-)
I am wondering if the attached is better, if only because it is of
less impact. I have die() there to avoid the behaviour change, but
if we are going to have another future version where we are willing
to take incompatiblity for better end-user experience like we did at
2.0, I suspect turning it to warning() or even removing it might be
a candidate for such a version. If you have one commit and ask
log, you get one commit back. If you have no commit and ask log,
I think it is OK to say that you should get nothing back without
fuss.
builtin/log.c | 19 +++
1 file changed, 15 insertions(+), 4 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index 4c4e6be..3b568a1 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -148,6 +148,9 @@ static void cmd_log_init_finish(int argc, const char
**argv, const char *prefix,
rev-diffopt.output_format |= DIFF_FORMAT_NO_OUTPUT;
argc = setup_revisions(argc, argv, rev, opt);
+ if (!rev-pending.nr !opt-def)
+ die(you do not have a commit yet on your branch);
I am not a native english speaker but shouldn't this be:
you do not have a commit on your branch yet
??
[...]
Stefan
--
/dev/random says: I bet you I could stop gambling.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git gc gives error: Could not read...
Hi there.
One of my repos started giving an error on 'git gc' recently:
$ git gc
error: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85
Counting objects: 3052, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (531/531), done.
Writing objects: 100% (3052/3052), done.
Total 3052 (delta 2504), reused 3052 (delta 2504)
error: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85
(Yes, the error comes twice).
I tried:
$ git cat-file -t 7713c3b1e9ea2dd9126244
fatal: Not a valid object name 7713c3b1e9ea2dd9126244
Otherwise, everything works fine.
I used that repo initially on Win7 with an older msysgit installation but
also tried the latest git-for-windows installer, and version 2.4.2 on linux.
All give the same error (no matter if I clone or copy the repo).
Unfortunately I cannot make the repo publically available.
Any chance to get rid of that error ?
Thanks,
Stefan
--
/dev/random says: When it comes to humility, I'm the very BEST there is!
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git gc gives error: Could not read...
Am 01.06.2015 um 10:52 schrieb Jeff King:
On Mon, Jun 01, 2015 at 10:40:53AM +0200, Stefan Näwe wrote:
Turns out to be a tree:
tree 7713c3b1e9ea2dd9126244697389e4000bb39d85
parent d7acfc22fbc0fba467d82f41c90aab7d61f8d751
author Stefan Naewe stefan.na...@atlas-elektronik.com 1429536806 +0200
committer Stefan Naewe stefan.na...@atlas-elektronik.com 1429536806 +0200
Yeah, I bungled the grep earlier. That message can come from a missing
tag, tree, or commit object. But I think the root cause is the same.
Maybe this one:
d3038d (prune: keep objects reachable from recent objects)
??
That's what 'git bisect' told me.
Not exactly. My msysgit is merge-rebase'd (or rebase-merge'd...) onto
v2.2.0...
I'll try older versions (pre v2.2.0) on linux.
OK, that makes more sense then.
I also cloned from local filesystem (widnows drive) to a samba share.
And that, too.
I've managed to create a small test case that replicates the problem:
diff --git a/t/t6501-freshen-objects.sh b/t/t6501-freshen-objects.sh
index 157f3f9..015b0da 100755
--- a/t/t6501-freshen-objects.sh
+++ b/t/t6501-freshen-objects.sh
@@ -129,4 +129,19 @@ for repack in '' true; do
'
done
+test_expect_failure 'do not complain about existing broken links' '
+ cat broken-commit -\EOF
+ tree 0001
+ parent 0002
+ author whatever whate...@example.com 1234 -
+ committer whatever whate...@example.com 1234 -
+
+ some message
+ EOF
+ commit=$(git hash-object -t commit -w broken-commit)
+ git gc 2stderr
+ verbose git cat-file -e $commit
+ test_must_be_empty stderr
+'
+
test_done
which produces:
'stderr' is not empty, it contains:
error: Could not read 0002
error: Could not read 0001
error: Could not read 0002
error: Could not read 0001
Unfortunately the fix is a little bit invasive. I'll send something out
in a few minutes.
It would be really helpful if you sent the patch as an attachment.
I know that's not the normal wokflow but our mail server garbles every
message so that I can't (or don't know how to...) use 'git am' to test
the patch, which I'm willing to do!
Thanks,
Stefan
--
/dev/random says: The cost of feathers has risen... Now even DOWN is up!
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git gc gives error: Could not read...
Am 01.06.2015 um 11:58 schrieb Jeff King:
On Mon, Jun 01, 2015 at 11:14:27AM +0200, Stefan Näwe wrote:
Maybe this one:
d3038d (prune: keep objects reachable from recent objects)
Yes, exactly.
It would be really helpful if you sent the patch as an attachment.
I know that's not the normal wokflow but our mail server garbles every
message so that I can't (or don't know how to...) use 'git am' to test
the patch, which I'm willing to do!
It ended up as a patch series. However, you can fetch it from:
git://github.com/peff/git.git jk/silence-unreachable-broken-links
which is perhaps even easier.
Not really in my situation...(but that's another story)
I managed to create patch files by simply copy-and-pasting the message
text (and the From:, Date:, and Subject: fields from 'View message source' in
Thunderbird...)
which I could then 'git am' ;-)
The patches applied (and compiled) cleanly on v2.4.2 and 'git gc'
stopped giving me the error message.
So (FWIW):
Tested-by: Stefan Naewe stefan.na...@gmail.com
Anything else I could test ?
Thanks,
Stefan
--
/dev/random says: Windows N'T: as in Wouldn't, Couldn't, and Didn't.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git gc gives error: Could not read...
Am 01.06.2015 um 10:14 schrieb Jeff King:
On Mon, Jun 01, 2015 at 09:37:17AM +0200, Stefan Näwe wrote:
One of my repos started giving an error on 'git gc' recently:
$ git gc
error: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85
Counting objects: 3052, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (531/531), done.
Writing objects: 100% (3052/3052), done.
Total 3052 (delta 2504), reused 3052 (delta 2504)
error: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85
The only error string that matches that is the one in parse_commit(),
when we fail to read the object. It happens twice here because
`git gc` runs several subcommands; you can see which ones are generating
the error if you run with GIT_TRACE=1.
I am surprised that it doesn't cause the commands to abort, though. If
we are traversing the object graph to repack, for example, we would want
to abort if we are missing a reachable object (i.e., the repository is
corrupt).
I tried:
$ git cat-file -t 7713c3b1e9ea2dd9126244
fatal: Not a valid object name 7713c3b1e9ea2dd9126244
Not surprising, if we don't have the object. What is curious is why git
wants to look it up in the first place. I.e., who is referencing it?
Either:
1. It is an object that we are OK to be missing (e.g., the
UNINTERESTING side of a traversal), and the error should be
suppressed.
2. Your repository really is corrupted, and this is a case where we
need to be paying attention to the return value of parse_commit but
are not.
I'd love to see:
- the output of GIT_TRACE=1 git gc (to see which subcommand is
causing the error)
- the output of git fsck (which should hopefully confirm whether or
not there is a real problem)
See attached file.
- any mentions of the sha1 in the refs or reflogs. Something like:
sha1=7713c3b1e9ea2dd9126244697389e4000bb39d85
cd .git
grep $sha1 $(find packed-refs refs logs -type f)
That gives nothing.
- If that doesn't turn up any hits, then presumably it's an object
referencing the sha1. We can dig into the objects (all of them, not
just reachable ones), like:
{
# loose objects
(cd .git/objects find ?? -type f | tr -d /)
# packed objects
for i in .git/objects/pack/*.idx; do
git show-index $i
done | cut -d' ' -f2
} |
# omit blobs; they are expensive to access and cannot have
# reachability pointers
git cat-file --batch-check='%(objecttype) %(objectname)' |
grep -v ^blob |
cut -d' ' -f2 |
# now get all of the contents, and look for our object; this is
# going to be slow, since it's one process per object; but we
# can't use --batch because we need to pretty-print the trees
xargs -n1 git cat-file -p |
less +/$sha1
Turns out to be a tree:
tree 7713c3b1e9ea2dd9126244697389e4000bb39d85
parent d7acfc22fbc0fba467d82f41c90aab7d61f8d751
author Stefan Naewe stefan.na...@atlas-elektronik.com 1429536806 +0200
committer Stefan Naewe stefan.na...@atlas-elektronik.com 1429536806 +0200
I would have guessed this was maybe caused by trying to traverse
unreachable recent objects for reachability. It fits case 1 (it is OK
for us to be missing these objects, but we might accidentally complain),
and it would probably happen twice during a gc (once for the repack, and
once for `git prune`).
But that code should not be present in older versions of msysgit, as it
came in v2.2.0 (and I assume older msysgit is v1.9.5).
Not exactly. My msysgit is merge-rebase'd (or rebase-merge'd...) onto v2.2.0...
I'll try older versions (pre v2.2.0) on linux.
And if that is
the problem, it would follow a copy of the repo, but not a clone (though
I guess if your clone was on the local filesystem, we blindly hardlink
the objects, so it might follow there).
I also cloned from local filesystem (widnows drive) to a samba share.
Thanks,
Stefan
--
/dev/random says: Useless Invention: How-to cassettes for the deaf.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
$ GIT_TRACE=1 git gc
10:21:27.228845 git.c:348 trace: built-in: git 'gc'
10:21:27.228845 run-command.c:347 trace: run_command: 'pack-refs' '--all'
'--prune'
10:21:27.25 git.c:348 trace: built-in: git 'pack-refs'
'--all' '--prune'
10:21:27.260045 run-command.c:347 trace: run_command: 'reflog' 'expire'
'--all'
10:21:27.275646 git.c:348 trace: built-in: git 'reflog' 'expire'
'--all'
10:21:27.338047 run-command.c:347 trace: run_command: 'repack' '-d' '-l'
'-A' '--unpack-unreachable=2.weeks.ago'
10:21:27.353647 git.c:348 trace: built-in: git
Re: [Announce] submitGit for patch submission (was Diffing submodule does not yield complete logs)
Am 22.05.2015 um 10:33 schrieb Roberto Tyley:
[...]
Hello, I'm stepping up to do that work :) Or at least, I'm implementing a
one-way GitHub PR - Mailing list tool, called submitGit:
https://submitgit.herokuapp.com/
That looks really promising!
I wonder if that wouldn't make a good addition to github's repository ui
in general ?
Thanks,
Stefan
--
/dev/random says: Diplomacy: The patriotic art of lying for one's country.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Change default branch name (server side) while cloning a repository
Am 27.03.2015 um 13:27 schrieb Garbageyard:
We use Gitolite for access control and i have admin access on Git server. I
wanted to make sure that whenever a new repository is created and is then
cloned on any machine, the default branch should point to mainline. To do
this, when I run the repository creation script, i change the content of
file HEAD of a given repository to point to mainline i.e., default entry of
“ref: refs/heads/master” in file HEAD is changed to “ref:
refs/heads/mainline”.
For example, if work is the repository name, then on Git server,
[gitolite@gitserver repositories]$ cd work.git/
[gitolite@gitserver work.git]$ cat HEAD
ref: refs/heads/mainline
If i now clone the repository on my local machine, then the default branch
should be pointing to mainline and not master. However, the issue is that it
still points to master. Am I /wrong/ in assuming that changing the entry in
file HEAD for a given repository on Git server will change the default
branch while cloning? If I’m wrong, can anyone please tell me how can I
enforce this change on the /server/ side correctly?
Works for me with gitolite3 v3.6.2-24-g8e36230 on git 2.3.4.
Could it be that the repo was emtpy when you tried to clone it ?
Stefan
--
/dev/random says: Half of the people in the world are below average.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] git: make was_alias and done_help non-static
Am 02.03.2015 um 13:02 schrieb Alexander Kuleshov:
'was_alias' variable does not need to store it's value on each
iteration in the loop, anyway this variable changes it's value with run_argv.
s/it's/its/
'done_help' variable does not need to be static variable too if we'll move it
out the loop.
So these variables do not need to be static.
Signed-off-by: Alexander Kuleshov kuleshovm...@gmail.com
Helped-by: Eric Sunshine sunsh...@sunshineco.com
---
git.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/git.c b/git.c
index 1780233..96723b8 100644
--- a/git.c
+++ b/git.c
@@ -619,6 +619,7 @@ int main(int argc, char **av)
{
const char **argv = (const char **) av;
const char *cmd;
+ int done_help, was_alias;
startup_info = git_startup_info;
@@ -681,8 +682,6 @@ int main(int argc, char **av)
setup_path();
while (1) {
- static int done_help = 0;
- static int was_alias = 0;
was_alias = run_argv(argc, argv);
if (errno != ENOENT)
break;
/S
--
/dev/random says: Recovery program for excessive talkers: On-and-on-Anon.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gittutorial.txt: remove reference to ancient Git version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 12.11.2014 um 09:57 schrieb Thomas Ackermann:
I also re-read the whole document and think it's still up-to-date
with Git 2.0. But I might have missed some subtler points.
Hhmm..
At least this is not 100% up to date:
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 8262196..8715244 100644
- --- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -107,14 +107,15 @@ summary of the situation with 'git status':
$ git status
- -# On branch master
- -# Changes to be committed:
- -# (use git reset HEAD file... to unstage)
- -#
- -# modified: file1
- -# modified: file2
- -# modified: file3
- -#
+On branch master
+Changes to be committed:
+Your branch is up-to-date with 'origin/master'.
+ (use git reset HEAD file... to unstage)
+
+modified: file1
+modified: file2
+modified: file3
+
Stefan
- --
-
/dev/random says: The drunker I sit here, The longer I get.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iEYEARECAAYFAlRjJGgACgkQgptJxZIhJ6+MfQCeI4iZ3HSkT0Lsk1sh1ckHLBzK
ROwAnAog8We8VLs6trwJsSQqZWDg7ndN
=YC26
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] gittutorial.txt: remove reference to ancient Git version
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Am 12.11.2014 um 10:12 schrieb Stefan Näwe:
Am 12.11.2014 um 09:57 schrieb Thomas Ackermann:
I also re-read the whole document and think it's still up-to-date
with Git 2.0. But I might have missed some subtler points.
Hhmm..
At least this is not 100% up to date:
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
[...]
And while at it:
diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index 3109ea8..1901af7 100644
- --- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -368,17 +368,18 @@ situation:
$ git status
- -# On branch master
- -# Changes to be committed:
- -# (use git reset HEAD file... to unstage)
- -#
- -# new file: closing.txt
- -#
- -# Changes not staged for commit:
- -# (use git add file... to update what will be committed)
- -#
- -# modified: file.txt
- -#
+On branch master
+Changes to be committed:
+ (use git reset HEAD file... to unstage)
+
+new file: closing.txt
+
+Changes not staged for commit:
+ (use git add file... to update what will be committed)
+ (use git checkout -- file... to discard changes in working directory)
+
+modified: file.txt
+
Stefan
- --
-
/dev/random says: Make it idiot proof and someone will make a better idiot.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
-BEGIN PGP SIGNATURE-
Version: GnuPG v1
iEYEARECAAYFAlRjJmoACgkQgptJxZIhJ6+LBgCgmVgJCmJjC86NHopW1rQwk/eA
r04AoIgMfKhB00H8KCHBMAsC5LjCFXY5
=bNM+
-END PGP SIGNATURE-
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git commit --only -- $path when $path already has staged content
Am 07.11.2014 um 20:54 schrieb Junio C Hamano:
Junio C Hamano gits...@pobox.com writes:
In other words, you give paths from the command line to tell the
command that you want to record the contents of them in the working
tree as a whole to be recorded in the resulting commit.
... and --only/--include only makes difference wrt what happens to
contents from the other paths.
Perhaps the attached would clarify it better, but there may have to
be some tutorial material to teach users that fundamentally there
are two ways to use Git, one to prepare what to be committed in the
index and run git commit without any paths, and the other to
pretty much ignore the index and run git commit with paths (or
with -a), and mixing two are considered to be rare exception.
You would (1) work with an elaborate sequence to build the next
commit in the index using add path and add -p, (2) notice a
change that can go before what you are building (e.g. trivial
typofix) outside the paths you are touching, and (3) edit that path
and do git commit path. That is the only scenario that makes
some sense to mix the two modes.
Imagine the change (2) you want to jump over your changes in (1)
happens to be in a path you are working with the index, e.g. after
running:
git add -p hello.rb
and picking only parts of changes you made to hello.rb into the
index, you found a trivial typo in the same file but in an unrelated
place (i.e. git diff hello.rb at that point would not show the
typo either in the preimage or the context). There is no way to
make the typofix first without disrupting what you did so far, and
git commit -o would not help (you would instead do a git stash
to save away the work in progress, make _only_ the typofix in the
same file, commit and then unstash, or something).
So in short, stick to either work with the index or ignore the
index; do not mix the two workflows and you would not have to worry
about -o or -i.
Thanks for your explanation. Makes perfect sense.
Documentation/git-commit.txt | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt
index 0bbc8f5..d6c4af1 100644
--- a/Documentation/git-commit.txt
+++ b/Documentation/git-commit.txt
@@ -250,7 +250,7 @@ FROM UPSTREAM REBASE section in linkgit:git-rebase[1].)
-o::
--only::
- Make a commit only from the paths specified on the
+ Make a commit only from the working tree contents of the paths
specified on the
command line, disregarding any contents that have been
staged so far. This is the default mode of operation of
'git commit' if any paths are given on the command line,
Yep, why not. Makes it a little clearer.
Stefan
--
/dev/random says: For every vision there is an equal and opposite revision.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git commit --only -- $path when $path already has staged content
Hello.
The manpage of git commit reads:
--only
Make a commit only from the paths specified on the command line,
disregarding any contents that have been staged so far. This is
the default mode of operation of git commit if any paths are given
on the command line, in which case this option can be omitted. [...]
But that seems to be only true for other content (i.e. other files not
specified in the command line).
If I do:
# some repo with a file in it
git init
echo content foo git add foo git commit -m foo
# modify and stage a file
echo other foo git add foo
# modify the same file even further but don't stage
echo bar foo
# commit with path specified on command line with explicit '--only'
git commit --only -m'.' -- foo
# but everything was commited
git status -s
empty
I would expect to only get the unstaged changes in the commit.
Could anyone shed some light, please?
Thanks,
Stefan
--
/dev/random says: Useless Invention: Camcorder with braile-encoded buttons.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] Allow the user to change the temporary file name for mergetool
Am 19.08.2014 um 19:15 schrieb Robin Rosenberg:
Using the original filename suffix for the temporary input files to
the merge tool confuses IDEs like Eclipse. This patch introduces
a configurtion option, mergetool.tmpsuffix, which get appended to
the temporary file name. That way the user can choose to use a
suffix like .tmp, which does not cause confusion.
Signed-off-by: Robin Rosenberg robin.rosenb...@dewire.com
---
Documentation/config.txt| 5 +
Documentation/git-mergetool.txt | 7 +++
git-mergetool.sh| 10 ++
3 files changed, 18 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index c55c22a..0e15800 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1778,6 +1778,11 @@ notes.displayRef::
several times. A warning will be issued for refs that do not
exist, but a glob that does not match any refs is silently
ignored.
+
+mergetool.tmpsuffix::
+ A string to append the names of the temporary files mergetool
+ creates in the worktree as input to a custom merge tool. The
+ primary use is to avoid confusion in IDEs during merge.
+
This setting can be overridden with the `GIT_NOTES_DISPLAY_REF`
environment variable, which must be a colon separated list of refs or
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index e846c2e..80a0526 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -89,6 +89,13 @@ Setting the `mergetool.keepBackup` configuration variable
to `false`
causes `git mergetool` to automatically remove the backup as files
are successfully merged.
+`git mergetool` may also create other temporary files for the
+different versions involved in the merge. By default these files have
+the same filename suffix as the file being merged. This may confuse
+other tools in use during a long merge operation. The user can set
+`mergetool.tmpsuffix` to be used as an extra suffix, which will be
+appened to the temporary filename to lessen that problem.
Still:
s/appened/appended/
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 9a046b7..d7cc76c 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -214,6 +214,8 @@ checkout_staged_file () {
}
merge_file () {
+ tmpsuffix=$(git config mergetool.tmpsuffix || true)
+
MERGED=$1
f=$(git ls-files -u -- $MERGED)
@@ -229,10 +231,10 @@ merge_file () {
fi
ext=$$$(expr $MERGED : '.*\(\.[^/]*\)$')
- BACKUP=./$MERGED.BACKUP.$ext
- LOCAL=./$MERGED.LOCAL.$ext
- REMOTE=./$MERGED.REMOTE.$ext
- BASE=./$MERGED.BASE.$ext
+ BACKUP=./$MERGED.BACKUP.$ext$tmpsuffix
+ LOCAL=./$MERGED.LOCAL.$ext$tmpsuffix
+ REMOTE=./$MERGED.REMOTE.$ext$tmpsuffix
+ BASE=./$MERGED.BASE.$ext$tmpsuffix
base_mode=$(git ls-files -u -- $MERGED | awk '{if ($3==1) print $1;}')
local_mode=$(git ls-files -u -- $MERGED | awk '{if ($3==2) print
$1;}')
Stefan
--
/dev/random says: It's Ensign Flintstone, Jim... He's Fred!
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Allow the user to change the temporary file name for mergetool
Am 19.08.2014 um 14:22 schrieb Robin Rosenberg:
Using the original filename suffix for the temporary input files to
the merge tool confuses IDEs like Eclipse. This patch introduces
a configurtion option, mergetool.tmpsuffix, which get appended to
the temporary file name. That way the user can choose to use a
suffix like .tmp, which does not cause confusion.
Signed-off-by: Robin Rosenberg robin.rosenb...@dewire.com
---
Documentation/git-mergetool.txt | 7 +++
git-mergetool.sh| 10 ++
2 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-mergetool.txt b/Documentation/git-mergetool.txt
index e846c2e..a586766 100644
--- a/Documentation/git-mergetool.txt
+++ b/Documentation/git-mergetool.txt
@@ -89,6 +89,13 @@ Setting the `mergetool.keepBackup` configuration variable
to `false`
causes `git mergetool` to automatically remove the backup as files
are successfully merged.
+`git mergetool` may also create other temporary files for the
+different versions involved in the merge. By default these files have
+the same filename suffix as the file being merged. This may confuse
+other tools in use during a long merge operation. The user can set
+`mergtool.tmpsuffix` to be used as an extra suffix, which will be
s/mergtool/mergetool/
+appened to the temporary filenamame to lessen that problem.
s/appened/appended/
s/filenamame/filename/
+
GIT
---
Part of the linkgit:git[1] suite
diff --git a/git-mergetool.sh b/git-mergetool.sh
index 9a046b7..d7cc76c 100755
--- a/git-mergetool.sh
+++ b/git-mergetool.sh
@@ -214,6 +214,8 @@ checkout_staged_file () {
}
merge_file () {
+ tmpsuffix=$(git config mergetool.tmpsuffix || true)
+
MERGED=$1
f=$(git ls-files -u -- $MERGED)
@@ -229,10 +231,10 @@ merge_file () {
fi
ext=$$$(expr $MERGED : '.*\(\.[^/]*\)$')
- BACKUP=./$MERGED.BACKUP.$ext
- LOCAL=./$MERGED.LOCAL.$ext
- REMOTE=./$MERGED.REMOTE.$ext
- BASE=./$MERGED.BASE.$ext
+ BACKUP=./$MERGED.BACKUP.$ext$tmpsuffix
+ LOCAL=./$MERGED.LOCAL.$ext$tmpsuffix
+ REMOTE=./$MERGED.REMOTE.$ext$tmpsuffix
+ BASE=./$MERGED.BASE.$ext$tmpsuffix
base_mode=$(git ls-files -u -- $MERGED | awk '{if ($3==1) print $1;}')
local_mode=$(git ls-files -u -- $MERGED | awk '{if ($3==2) print
$1;}')
Stefan
--
/dev/random says: Confusion not only reigns, it pours.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9 9666 829B 49C5 9221 27AF
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] Git release notes man page
Am 18.02.2014 23:54, schrieb Philip Oakley:
From: Junio C Hamano gits...@pobox.com
I do not understand why
it is even a good idea to show release notes from the command line
git interface.
My looking at this came from Stefan's suggestion noted above
$gmane/240595. So it had at least one follower ;-)
Yes, but I could definitely live without it.
I compile git myself on most systems and that would just be a
convenient way to get an overview of the latest changes.
Regards,
Stefan
--
/dev/random says: It is bad luck to be superstitious.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [msysGit] Git for Windows 1.9.0
Am 18.02.2014 00:38, schrieb Johannes Schindelin:
Dear Git fanbois,
this announcement informs you that the small team of volunteers who keep
the Git ship afloat for the most prevalent desktop operating system
managed to release yet another version of Git for Windows:
Git Release Notes (Git-1.9.0-preview20140217)
Last update: 17 February 2013
Changes since Git-1.8.5.2-preview20131230
New Features
- Comes with Git 1.9.0 plus Windows-specific patches.
- Better work-arounds for Windows-specific path length limitations (pull
request #122)
- Uses optimized TortoiseGitPLink when detected (msysGit pull request
#154)
- Allow Windows users to use Linux Git on their files, using Vagrant
http://www.vagrantup.com/ (msysGit pull request #159)
- InnoSetup 5.5.4 is now used to generate the installer (msysGit pull
request #167)
Bugfixes
- Fixed regression with interactive password prompt for remotes using the
HTTPS protocol (issue #111)
- We now work around Subversion servers printing non-ISO-8601-compliant
time stamps (pull request #126)
- The installer no longer sets the HOME environment variable (msysGit pull
request #166)
- Perl no longer creates empty sys$command files when no stdin is
connected (msysGit pull request #152)
Ciao,
Johannes
Thanks to all involved!
Stefan
--
/dev/random says: I didn't cheat, I just changed the Rules!
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git-draw - draws nearly the full content of a tiny git repository as a graph
Am 29.01.2014 22:21, schrieb Flo:
I just want to present a small tool I wrote. I use it at work to have
a tool visualizing the Git basic concepts and data structures which
are really really really simple (Linus' words). That helps me
teaching my colleagues about Git and answering their questions when
Git did not behave as they expected.
https://github.com/sensorflo/git-draw/wiki
This looks really promising!
Stefan
--
/dev/random says: Famous last words - Jesus Christ: Father, beam me up.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [ANNOUNCE] Git v1.9-rc0
Am 22.01.2014 13:53, schrieb Javier Domingo Cansino:
Will there be any change on how tarballs are distributed, taking into
account that Google will be shutting down Google Code Downloads
section[1][2]?
Am I missing something or what's wrong with this:
https://github.com/gitster/git/archive/v1.9-rc0.tar.gz
or any
https://github.com/gitster/git/archive/$TAG.tar.gz
??
(As long as Junio continues to push to github, of course)
Stefan
--
/dev/random says: Folks who think they know it all bug those of us who do
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Make 'git help everyday' work - relnotes
Am 16.01.2014 22:14, schrieb Philip Oakley:
From: Stefan Näwe stefan.na...@atlas-elektronik.com
[...]
I'd really like to see 'git help relnotes' working as well...
Stefan
Stefan,
Were you thinking that all the release notes would be quoted verbatim in
the one long man page?
Or that it would be a set of links to each of the individual text files
(see the ifdef::stalenotes[] in git/Documentation/git.txt)?
The latter allows individual release notes to be checked, but still
leaves folks with a difficult search problem if they want to find when
some command was 'tweaked'.
Obviously, any method would need to be easy to maintain. And the
RelNotes symlink would need handling.
'git help relnotes' should show the current release note with
a link to the previous.
And 'git help git' should link to the current release note.
Stefan
--
/dev/random says: We now return you to your regularly scheduled flame-throwing
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 0/6] Make 'git help everyday' work
Am 10.01.2014 00:49, schrieb Junio C Hamano:
I think we already use a nicer way to set up a page alias to keep
old links working than making a copy in Documentation/; please mimic
that if possible.
It may be overdue to refresh the suggested set of top 20 commands,
as things have vastly changed over the past 8 years. Perhaps we
should do that after reorganizing with something like this series.
I'd really like to see 'git help relnotes' working as well...
Stefan
--
/dev/random says: Despite the high cost of living, it remains popular.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: [hostname:port]:repo.git notation no longer works (for ssh)
Am 27.09.2013 10:07, schrieb Morten Stenshorne:
I've just upgraded to Debian testing (jessie), and with that I got a
brand new (for me) git version:
$ git --version
git version 1.8.4.rc3
Some of my repos I use an ssh tunnel to reach, so when I want to reach a
repo forwarded to local port 2223, using the ssh protocol, the following
used to work (.git/config) in older git versions:
[remote exp]
url = [localhost:2223]:blink.git
fetch = +refs/heads/*:refs/remotes/exp/*
However, now I get this message:
$ git fetch exp
fatal: ':blink.git' does not appear to be a git repository
fatal: Could not read from remote repository.
I wonder why that worked (especially the [...]) at all ?
I thought specifying a port for a SSH connection was always only
possible when using
ssh://user@host:port/path/to/repo.git
- or -
ssh://user@host:port/~user/path/to/repo.git
At least that's what I always read out of the git-clone man page.
Stefan
--
/dev/random says: Don't ask me, I have random access memory.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[Bug] git show crashes with deepened shallow clone
Just a quick report since I don't have time to bisect now (will do later
if no other gitster is faster...)
When I execute the below script 'git show' crashes. 'git log --oneline -2' gives
for example:
3808bade5b76c4663ac4a3f751dc9f1ed0b08f2e three
error: Could not read 1e8777edeb2b7e757f74c789e679fc6c71073897
fatal: Failed to traverse parents of commit
0aa4ef86004f5bb29f67e971d7963f5cf430c668
gdb backtrace of one run is attached.
It happens on 32-bit Debian (5.0.10), 64-bit openSUSE (12.2), and Windows XP
with git 1.8.4
on all systems.
The help of 'git fetch' says:
--depth=depth
Deepen or shorten the history of a shallow repository created by git
clone with
--depth=depth option (see git-clone(1)) to the specified number of
commits from
the tip of each remote branch history. Tags for the deepened commits are
not fetched.
---^
But that's not true. The tag 'two' (from the script below) gets fetched when
deepening the repository.
---8---8---8---8---8---8---8---8---8---8---8---8---8---8---8
git init shallow-test
(cd shallow-test
echo foo file
git add file
git commit -mone
git tag -mone one
echo bar file
git commit -mtwo file
git tag -mtwo two
echo baz file
git commit -mthree file
git tag -mthree three )
git clone --depth=1 -b three file://`pwd`/shallow-test shallow-test-clone
(cd shallow-test-clone
git fetch --depth=2
git log --oneline -2 ;
git show two)
---8---8---8---8---8---8---8---8---8---8---8---8---8---8---8
Stefan
--
/dev/random says: The cost of feathers has risen... Now even DOWN is up!
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
Core was generated by `/home/naewe/src/git/git show two'.
Program terminated with signal 11, Segmentation fault.
[New process 13783]
#0 read_object_with_reference (sha1=0x4 Address 0x4 out of bounds,
required_type_name=0x817ca97 tree, size=0xbfdfe3d8, actual_sha1_return=0x0)
at cache.h:697
697 memcpy(sha_dst, sha_src, 20);
#0 read_object_with_reference (sha1=0x4 Address 0x4 out of bounds,
required_type_name=0x817ca97 tree, size=0xbfdfe3d8, actual_sha1_return=0x0)
at cache.h:697
type = -1075846344
required_type = OBJ_TREE
buffer = (void *) 0x0
isize = value optimized out
actual_sha1 = \fãß¿\000\000\000\000¸âß¿±n\022\b¼`S\t
#1 0x081392bf in diff_tree_sha1 (old=0x4 Address 0x4 out of bounds,
new=0x95429cc A1þM3Í\205Ú\200Zɦi|\QÉ\023\210\034, base=0x8155ab9 ,
opt=0xbfdfe7e4) at tree-diff.c:277
tree1 = (void *) 0x954a9d0
tree2 = value optimized out
t1 = {
buffer = 0x1,
entry = {
sha1 = 0x0,
path = 0x0,
mode = 3219121144
},
size = 135386226
}
t2 = {
buffer = 0xbfdfe3e8,
entry = {
sha1 = 0x80c44cc é1ÿÿÿë\r, '\220' repeats 13 times,
U\211åW\211×V\211ÎS\203ì\034ÇEð,
path = 0x816d329 Could not read %s,
mode = 135991090
},
size = 3219121108
}
size1 = value optimized out
size2 = value optimized out
retval = value optimized out
#2 0x080f12d9 in log_tree_commit (opt=0xbfdfe530, commit=0x9536088) at
log-tree.c:778
log = {
commit = 0x9536088,
parent = 0x0
}
shown = 0
#3 0x08082dea in cmd_log_walk (rev=0xbfdfe530) at builtin/log.c:342
commit = (struct commit *) 0x9536088
saved_nrl = 0
saved_dcctc = 0
#4 0x080835cd in cmd_show (argc=2, argv=0xbfdfec28, prefix=0x0) at
builtin/log.c:566
o = (struct object *) 0x9536088
name = 0x952c390 two
rev = {
commits = 0x0,
pending = {
nr = 0,
alloc = 0,
objects = 0x0
},
boundary_commits = {
nr = 0,
alloc = 0,
objects = 0x0
},
cmdline = {
nr = 1,
alloc = 24,
rev = 0x952c9f8
},
prefix = 0x0,
def = 0x815364c HEAD,
prune_data = {
raw = 0x0,
nr = 0,
has_wildcard = 0,
recursive = 0,
max_depth = 0,
items = 0x0
},
sort_order = REV_SORT_IN_GRAPH_ORDER,
early_output = 0,
ignore_missing = 0,
dense = 1,
prune = 0,
no_walk = 1,
show_all = 0,
remove_empty_trees = 0,
simplify_history = 1,
topo_order = 0,
simplify_merges = 0,
simplify_by_decoration = 0,
tag_objects = 0,
tree_objects = 0,
blob_objects = 0,
verify_objects = 0,
edge_hint = 0,
limited = 0,
unpacked = 0,
boundary = 0,
count = 0,
left_right = 0,
left_only = 0,
right_only = 0,
rewrite_parents = 0,
print_parents = 0,
show_source = 0,
show_decorations = 0,
reverse = 0,
reverse_output_stage = 0,
cherry_pick = 0,
cherry_mark = 0,
bisect = 0,
ancestry_path = 0,
first_parent_only = 0,
line_level_traverse = 0,
diff = 1,
full_diff = 0,
show_root_diff = 1,
no_commit_id = 0,
verbose_header = 1,
Re: [Bug] git show crashes with deepened shallow clone
Am 25.09.2013 16:47, schrieb Stefan Näwe:
Just a quick report since I don't have time to bisect now (will do later
if no other gitster is faster...)
Seems to be somewhere between v1.8.3.1 (OK) and v1.8.3.2 (not OK) !!
When I execute the below script 'git show' crashes. 'git log --oneline -2'
gives
for example:
3808bade5b76c4663ac4a3f751dc9f1ed0b08f2e three
error: Could not read 1e8777edeb2b7e757f74c789e679fc6c71073897
fatal: Failed to traverse parents of commit
0aa4ef86004f5bb29f67e971d7963f5cf430c668
gdb backtrace of one run is attached.
It happens on 32-bit Debian (5.0.10), 64-bit openSUSE (12.2), and Windows XP
with git 1.8.4
on all systems.
The help of 'git fetch' says:
--depth=depth
Deepen or shorten the history of a shallow repository created by git
clone with
--depth=depth option (see git-clone(1)) to the specified number of
commits from
the tip of each remote branch history. Tags for the deepened commits
are not fetched.
---^
But that's not true. The tag 'two' (from the script below) gets fetched when
deepening the repository.
v1.8.3.1 fetches the tag also.
Stefan
--
/dev/random says: Pobody's Nerfect!
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug] git show crashes with deepened shallow clone
Am 25.09.2013 16:47, schrieb Stefan Näwe:
Just a quick report since I don't have time to bisect now (will do later
if no other gitster is faster...)
I'd marry 'git bisect' if I wasn't already... ;-)
This is what it gives me if I use my script (slightly modified to also run make)
with 'git bisect run':
6035d6aad8ca11954c0d7821f6f3e7c047039c8f is the first bad commit
commit 6035d6aad8ca11954c0d7821f6f3e7c047039c8f
Author: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Date: Sun May 26 08:16:15 2013 +0700
fetch-pack: prepare updated shallow file before fetching the pack
index-pack --strict looks up and follows parent commits. If shallow
information is not ready by the time index-pack is run, index-pack may
be led to non-existent objects. Make fetch-pack save shallow file to
disk before invoking index-pack.
git learns new global option --shallow-file to pass on the alternate
shallow file path. Undocumented (and not even support --shallow-file=
syntax) because it's unlikely to be used again elsewhere.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
Signed-off-by: Junio C Hamano gits...@pobox.com
:100644 100644 67bd5091be0b34bfea075cd60281d22cf5b34768
6e9c7cd9d5da7d24d4810b36039681f184325932 M commit.h
:100644 100644 f156dd4fac30cda4e09c508b7091cdb8d96917e2
6b5467c6dec9645f53d83cdad2467a158db622c0 M fetch-pack.c
:100644 100644 1ada169d5cff3051effee33c6f9ba5b9be15b2e6
88eef5a7cc6d36f6e17f4855945116dd6f1b0681 M git.c
:100644 100644 6be915f38f1fe8dbe0a22c4cd8ae2569331f483f
cbe2526d8c2b2643957eea2729a16269a7a74fab M shallow.c
:04 04 5333beeb4db3fc37c37e5a4d03816c4750ce6b28
3b0fb999b8655155cba24e2d09ebff29058d29d7 M t
bisect run success
Stefan
--
/dev/random says: Answers: $1 * Correct answers: $5 * Dumb looks: Free! *
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [Bug] git show crashes with deepened shallow clone
Stefan Näwe stefan.naewe at atlas-elektronik.com writes: Am 25.09.2013 16:47, schrieb Stefan Näwe: This is what it gives me if I use my script (slightly modified to also run make) with 'git bisect run': 6035d6aad8ca11954c0d7821f6f3e7c047039c8f is the first bad commit And to answer myself once more: That's fixed in 6da8bdc fetch-pack: do not remove .git/shallow file when --depth is not specified Sorry for all the noise. Stefan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone -b
Am 01.07.2013 18:46, schrieb Junio C Hamano:
Stefan Näwe stefan.na...@atlas-elektronik.com writes:
Is there any reason why 'git clone -b' only takes a branch (from
refs/heads/)
or a tag (from refs/tags/) ?
Because they are common enough, and doing the same for an arbitrary
object is just as easy to do something like:
git clone -n
git checkout $an_arbitrary_commit_object_name^0
OK. I wasn't aware of '-n' for 'git clone'. Thanks.
Background: At $dayjob we're using some kind of 'hidden' refs (in
refs/releases/)
to communicate between the 'branch integrator' (who creates the ref in
refs/releases/)
and the 'build master' who wants to build that ref.
While I wasn't paying much attention to this, I vaguely recall that
people pointed out that using a fresh clone every time may not be
what you want to do in the first place, and I happen to agree with
them (and that is why I am not very much interested in this topic).
As I said: We'd be using 'git archive --remote...' if that was
submodule-aware.
Thanks,
Stefan
--
/dev/random says: Circular Definition: see Definition, Circular.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone -b
Am 28.06.2013 13:59, schrieb Stefan Näwe:
Hi there!
Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
or a tag (from refs/tags/) ?
Background: At $dayjob we're using some kind of 'hidden' refs (in
refs/releases/)
to communicate between the 'branch integrator' (who creates the ref in
refs/releases/)
and the 'build master' who wants to build that ref.
It would be a little easier if the build master could simply say
git clone -b refs/releases/the-release-for-today URL
instead of: git clone... ; cd ... ; git fetch... ; git checkout
Any answer or even a better idea to solve that is appreciated.
Stefan
Anyone?
Thanks,
Stefan
--
/dev/random says: Some people like learning Eskimo, but I can't get Inuit.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH] submodule: add 'exec' option to submodule update
Am 28.06.2013 11:53, schrieb Chris Packham:
This allows the user some finer grained control over how the update is
done. The primary motivation for this was interoperability with stgit
however being able to intercept the submodule update process may prove
useful for integrating or extending other tools.
Signed-off-by: Chris Packham judge.pack...@gmail.com
--
Hi,
At $dayjob we have a number of users that are accustomed to using stgit.
Stgit doesn't play nicely with git rebase which would be the logical
setting for submodule.*.update for our usage. Instead we need to run
'stg rebase --merged' on those submodules that have been initialised
with stgit.
Our current solution is an in-house script which is a poor substitute
for git submodule update. I'd much rather replace our script with git
submodule update but we do have a requirement to keep stgit for the
foreseeable future. Rather than narrowing in on stgit it seems logical
to allow an arbitrary update command to be executed.
Hhmmm...
Can't the same be accomplished with
git submodule foreach 'your-update-script $sha1'
Am I missing something?
Stefan
--
/dev/random says: Preserve nature... pickle a squirrel.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
git clone -b
Hi there!
Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
or a tag (from refs/tags/) ?
Background: At $dayjob we're using some kind of 'hidden' refs (in
refs/releases/)
to communicate between the 'branch integrator' (who creates the ref in
refs/releases/)
and the 'build master' who wants to build that ref.
It would be a little easier if the build master could simply say
git clone -b refs/releases/the-release-for-today URL
instead of: git clone... ; cd ... ; git fetch... ; git checkout
Any answer or even a better idea to solve that is appreciated.
Stefan
--
/dev/random says: Second star to the right straight on till morning...
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone -b
Am 28.06.2013 13:59, schrieb Stefan Näwe:
Hi there!
Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
or a tag (from refs/tags/) ?
Background: At $dayjob we're using some kind of 'hidden' refs (in
refs/releases/)
to communicate between the 'branch integrator' (who creates the ref in
refs/releases/)
and the 'build master' who wants to build that ref.
It would be a little easier if the build master could simply say
git clone -b refs/releases/the-release-for-today URL
instead of: git clone... ; cd ... ; git fetch... ; git checkout
Any answer or even a better idea to solve that is appreciated.
Stefan
Oh, and while at it:
This doesn't look/feel right:
$ git clone -b refs/heads/master git/.git other-git
Cloning into 'other-git'...
fatal: Remote branch refs/heads/master not found in upstream origin
fatal: The remote end hung up unexpectedly
(where git is git's git which definitely has refs/heads/master...)
Stefan
--
/dev/random says: In God we trust; all else we walk through.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git clone -b
Am 28.06.2013 14:18, schrieb Fredrik Gustafsson:
On Fri, Jun 28, 2013 at 01:59:51PM +0200, Stefan Näwe wrote:
Hi there!
Is there any reason why 'git clone -b' only takes a branch (from refs/heads/)
or a tag (from refs/tags/) ?
Background: At $dayjob we're using some kind of 'hidden' refs (in
refs/releases/)
to communicate between the 'branch integrator' (who creates the ref in
refs/releases/)
and the 'build master' who wants to build that ref.
It would be a little easier if the build master could simply say
git clone -b refs/releases/the-release-for-today URL
instead of: git clone... ; cd ... ; git fetch... ; git checkout
Any answer or even a better idea to solve that is appreciated.
Stefan
I don't understand what the alternative should be. You can't look in
/refs/* because there's a lot of other stuff like bisect/remotes etc.
there.
Well, I tell clone exactly what I want. There is no reason try something
from refs/*.
Of course you could add to also look in /refs/releases/ but as I
understand you that a special solution for your company. Why should all
git users have that addition?
It wouldn't hurt, IMHO. Maybe it would even make sense to allow any SHA-1
to be passed to '-b'.
Two questions about your setup:
1. Why do you always clone your repository? To me clone is a one
time operation.
We would use 'git archive' if that would be submodule-aware...
2. Why don't you tag your releases with an ordinary tag?
Because we use that 'refs/release' thing as a hidden ref that other
developers will not see when they fetch (unless they are told to checkout
that particular ref).
Think of using this similar to the way github uses refs/pull/*/{head,merge}
for their pull request mechanism.
Stefan
--
/dev/random says: The Definition of an Upgrade: Take old bugs out, put new ones
in.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: segmentation fault (nullpointer) with git log --submodule -p
Am 23.01.2013 21:02, schrieb Jeff King:
On Wed, Jan 23, 2013 at 03:38:16PM +0100, Armin wrote:
Hello dear git people.
I experience a reproducible segmentation fault on one of my
repositories when doing a git log --submodule -p, tested with newest
version on Arch Linux (git version 1.8.1.1) and built fresh (git
version 1.8.1.1.347.g9591fcc), tried on 2 seperate systems:
Program terminated with signal 11, Segmentation fault.
#0 0x004b51e5 in parse_commit_header (context=0x769b6980) at
pretty.c:752
752 for (i = 0; msg[i]; i++) {
[...]
(gdb) l
747 static void parse_commit_header(struct format_commit_context *context)
748 {
749 const char *msg = context-message;
750 int i;
751
752 for (i = 0; msg[i]; i++) {
753 int eol;
754 for (eol = i; msg[eol] msg[eol] != '\n'; eol++)
755 ; /* do nothing */
756
(gdb) p msg
$7 = optimized out
(gdb) p context-message
$8 = 0x0
Yeah, that should definitely not be NULL. I can't reproduce here with a
few simple examples, though.
Does it fail with older versions of git? If so, can you bisect?
I did. My bisection told me this is the suspect:
ccdc603 (parse_object: try internal cache before reading object db)
My git-fu is not good enough to analyze that...
Is it possible for you to make your repo available?
Unfortunately not. It crashes with one particular repos (using submodules)
that I can't make available but not with another which is available
at https://github.com/snaewe/super.git
HTH
Stefan
--
/dev/random says: There must be more to life than compile-and-go.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: segmentation fault (nullpointer) with git log --submodule -p
Am Donnerstag, 24. Januar 2013 14:40:47 schrieb Duy Nguyen:
On Thu, Jan 24, 2013 at 7:11 PM, Stefan Näwe
stefan.na...@atlas-elektronik.com wrote:
Does it fail with older versions of git? If so, can you bisect?
I did. My bisection told me this is the suspect:
ccdc603 (parse_object: try internal cache before reading object db)
diff --git a/object.c b/object.c
index d8d09f9..6b06297 100644
--- a/object.c
+++ b/object.c
@@ -191,10 +191,15 @@ struct object *parse_object(const unsigned char *sha1)
enum object_type type;
int eaten;
const unsigned char *repl = lookup_replace_object(sha1);
- void *buffer = read_sha1_file(sha1, type, size);
+ void *buffer;
+ struct object *obj;
+
+ obj = lookup_object(sha1);
+ if (obj obj-parsed)
+ return obj;
Any chance obj-parsed is 1 but ((struct commit*)obj)-buffer is NULL?
What if you change that if to
if (obj obj-parsed (obj-type != OBJ_COMMIT || ((struct commit
*)obj)-buffer))
No more segfault!
Also you did not encode commits in any specific encoding,
We're using Git for Windows and some commits contain 'umlauts' (äöü).
But those characters should be encoded in UTF-8, shouldn't they?
But the 'git log...' only crashes on a Debian/Linux machine.
nor set i18n.logOutputEncoding?
It's not set.
(only i18n.filesEncoding is set to utf-8 on my machine)
Oh, and it's not crashing if I do:
git log -p --submodule |cat
Stefan
--
/dev/random says: Dumb luck beats sound planning every time. Trust me.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git gui does not open bare repositories
Am 28.09.2012 10:44, schrieb Stefan Näwe:
I get Not a Git repository: remote.git as well, when I run
git gui somewhere (i.e. not in remote.git)
i.e.:
$ cd /not/a/repo
$ git gui
and the select Open Existing Repository.
I get Cannot use bare repository: .../remote.git when I run git gui
from inside the remote.git directory.
i.e.:
$ cd /path/to/bare-repo.git
$ git gui
Both on WinXP with msysGit.
And the same on Linux with Git v1.7.12
Stefan
--
/dev/random says: Press any key to continue or any other key to quit...
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git gui does not open bare repositories
Am 28.09.2012 10:35, schrieb Frans Klaver:
Hi,
Please remember to reply to all when discussing things on the git mailing
list.
On Fri, Sep 28, 2012 at 10:29 AM, Angelo Borsotti
angelo.borso...@gmail.com wrote:
Hello
I apologise for having used the wrong script to reproduce the error.
This is the right one:
angelo@ANGELO-PC /d/gtest (master)
$ mkdir remote.git
angelo@ANGELO-PC /d/gtest (master)
$ cd remote.git
angelo@ANGELO-PC /d/gtest/remote.git (master)
$ git init --bare
Initialized empty Git repository in d:/gtest/remote.git/
Now with the git gui I try to open the d:/gtest/remote.git/ and
receive the message
that it is not a git repository.
I understand that the gui is mostly aimed to non-bare repositories,
but in such a case
it would be better it could give me a message like, e.g. could not
open a bare repository
instead of telling me that it is not a git repository (I thought my
bare repository was
corrupt, and tried to figure out what was wrong with it).
Actually git-gui 0.16.0 is telling me that it cannot use bare
repositories, much in the vein of what I wrote earlier. Don't know if
it matters that I'm on Linux though.
I get Not a Git repository: remote.git as well, when I run
git gui somewhere (i.e. not in remote.git) and the select
Open Existing Repository.
I get Cannot use bare repository: .../remote.git when I run git gui
from inside the remote.git directory.
Both on WinXP with msysGit.
Stefan
--
/dev/random says: Unless you're the lead dog, the view never changes.
python -c print
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC] Add a new email notification script to contrib
mhagger at alum.mit.edu writes: From: Michael Haggerty mhagger at alum.mit.edu Add a new Python script, contrib/hooks/post-receive-multimail.py, that can be used to send notification emails describing pushes into a git repository. This script is derived from contrib/hooks/post-receive-mail, but has many differences, including: Looks interesting! Do you have a fork of git.git somewhere that contains the script? (I find it so much easier these days to simply fetch another repo instead of applying patches with 'git am'.) Thanks, Stefan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Support of '^' as alias for 'HEAD^'
Zeeshan Ali (Khattak zeeshanak at gnome.org writes: Hi, Many times I want to refer to 'HEAD^', 'HEAD^^' and sometimes even further up the tree. It would be really nice if I didn't have to type 'HEAD^' but could only type '^'. Bash completion make things easier but it automatically inserts a space immediately after HEAD so you have to hit backspace. I think this change would be good in general anyway. Or even '~1', '~3'. Where's the '+1' button...? Stefan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
