* Re: .gitignore don't ignore a file
From: Gustaf Hendeby @ 2011-09-10 11:01 UTC (permalink / raw)
To: Bastien Sevajol; +Cc: git
In-Reply-To: <4E6B3C19.4040908@gmail.com>
Hi!
On 09/10/2011 12:29 PM, Bastien Sevajol wrote:
> Hello !
> I don't understand why my gitingnore don't want to ignore a file.
> I have this in my gitignore:
>
>> app/cache/
>> app/logs/
>> app/logs/dev.log
>> app/logs/prog.log
>> app/logs/test.log
>> *.log
>> *.*~
>> nbproject
>
> i've try with app/logs/.gitignore with this:
>
>> dev.log
>
> But, git don't ignore app/logs/dev.log :/
>
> Do you now why ?
> thank's =)
Is the file currently committed (or staged) to your repository? In that
case; Git never ignore files that are put under version control. If
not, could you please elaborate a bit more on in what way the file is
not ignored. It is not completely clear to me what you expect, and what
in fact happens.
/Gustaf
^ permalink raw reply
* Re: merge result
From: Matthieu Moy @ 2011-09-10 11:35 UTC (permalink / raw)
To: Lynn Lin; +Cc: git
In-Reply-To: <CAPgpnMTMPQQPkS-gKLvUJNKLfMWuAT-oA3NCiSRFxu7PknYsnA@mail.gmail.com>
Lynn Lin <lynn.xin.lin@gmail.com> writes:
>>> 1->2->3-4>5 Master
>>> |
>>> 4->6->7 A
>>
>> A more accurate drawing would be
>>
>> 1->2->3-4>5 Master
>> |
>> 4'->6->7 A
>>
>> and after merging, you'd get
>>
>> 1->2->3-4>5-->8 A, master
>> | /
>> 4'->6->7
>>
>> with 8 having both 4 and 4' as ancestors. There's nothing wrong with it.
>> Git cannot remove either 4 or 4' without rewritting history, and "git
>> merge" does not rewrite history.
> so confused here.If 4' is just next 4 commit,how can the diff work? for example
>
> 1->2->4->4'->6->...
>
> diff 4 and 4' is a little confused,correct?
History is not linear. When you type "git log", you may think that 4 and
4' follow each other, but try "gitk" or "git log --oneline --graph" to
see a better view of history.
It's possible to have several times the same change applied to multiple
branches (e.g. when doing cherry-picking), but having twice the same
change in a row is not really possible.
Suppose your commit 4 removes the line "foobar". Then, commits 1, 2 and
3 have the line "foobar" (think of commits as snapshots in history, not
as diff. 3 is a snapshot, and when you run "git show 3", it shows you
the diff from 2 to 3). Commits 4 and 4' don't have it anymore, and then
obviously 5, 6, 7 don't have it either. At the time of merge, Git will
notice that neither of the merges to commit have the line "foobar" and
the result 8 won't have it either.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] t3200: test branch creation with -v
From: Michael J Gruber @ 2011-09-10 13:29 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20110909194357.GA31446@sigill.intra.peff.net>
Jeff King venit, vidit, dixit 09.09.2011 21:43:
> On Fri, Sep 09, 2011 at 09:40:59PM +0200, Michael J Gruber wrote:
>
>> +test_expect_success 'git branch -v t should work' ' + git branch
>> -v t && + test .git/refs/heads/t &&
>
> test -f ?
>
> Also, don't we have test_path_is_file which yields slightly prettier
> output (and maybe some portability benefits; I don't remember)?
>
>> + git branch -d t && + test ! -f .git/refs/heads/t
>
> Ditto for 'test_path_is_missing' here.
>
> -Peff
Well, I tried to follow the surrounding style. That t3200 could benefit
from some attention, though, which I did not want to mix in with the
issue at hand.
Michael
^ permalink raw reply
* Letter from Hong Kong
From: Mr. Daniel Tsai @ 2011-09-09 22:02 UTC (permalink / raw)
To: danieltsai0
Hello my friend. My name is Daniel Tsai and
I live in Hong Kong. I want you to be my
partner in a business transaction of 44.5Million USD.
If you are interested for more details,
you MUST reply me to my private email address:
danieltsai11@yahoo.com.hk or danieltsai95@aol.com
when I get your message, I will tell you what
to do next. Thank you.
Mr. Daniel Tsai
^ permalink raw reply
* Re: [PATCH v3 0/4] Signed push
From: Sverre Rabbelier @ 2011-09-10 15:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Shawn O. Pearce
In-Reply-To: <7vipp1otyp.fsf@alter.siamese.dyndns.org>
Heya,
On Sat, Sep 10, 2011 at 07:19, Junio C Hamano <gitster@pobox.com> wrote:
> Even under v2 design, if somebody who has access to both k.org (public)
> and github (proprietary in the hypothetical universe) would want to
> combine the signed-push notes to see a unified picture (perhaps I push to
> these two sites with different frequencies), he can fetch signed-push
> notes from both sites and merge them himself. But v3 design also allows
> anybody who has access to k.org (which is public so by definition that
> truly is anybody) to peek into signed-push notes at k.org to learn more
> than he should be able to.
I think this is also some further motivation to have a
refs/remotes/github/notes/signed-push and a
refs/remotes/korg/notes/signed-push, rather than have everything
automatically go into refs/notes/signed-push when fetching from a
remote.
(If I misremembered and it's already that way, please ignore this message :P)
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH v3 0/4] Signed push
From: Junio C Hamano @ 2011-09-10 16:30 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, Jeff King, Shawn O. Pearce
In-Reply-To: <CAGdFq_hWVPCEeJKKccp4Wc-j+XMSFXqRf6VYd7ngLER8RhODRQ@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> I think this is also some further motivation to have a
Did you miss that I already mentioned that workaround? It does not _fix_
the fundamental breakage, which is that you are _forcing_ the sending side
to keep copies, though.
^ permalink raw reply
* Re: [RFC/PATCH] t9159-*.sh: Don't use the svn '@<rev>' syntax
From: Ramsay Jones @ 2011-09-10 17:40 UTC (permalink / raw)
To: Sam Vilain
Cc: Michael J Gruber, Junio C Hamano, Eric Wong, GIT Mailing-list,
mhagger
In-Reply-To: <4E27098B.906@vilain.net>
Sam Vilain wrote:
> On 20/07/11 10:07, Michael J Gruber wrote:
>> path@REV are so-called peg revisions, introduced in svn 1.1, and denote
>> "I mean the file named path in REV" (as opposed to "the file named path
>> now and maybe differently back then"). It (now) defaults to BASE (for
>> worktree) resp. HEAD (for URLs). A bit like our rename detection.
>>
>> -r REV specifies the operative revision. After resolving the
>> name/location using the pegrev, the version at the resolved path at the
>> oprative version is operated on.
>>
>> svn 1.5.0 (June 2008) introduced peg revisions to "svn copy", so I
>> assume our people were following svn trunk and adjusting in 2007 already
>> (to r22964). There were some fixes to "svn copy" with peg later on.
>>
>> I do not understand the above commit message at all; and I did not find
>> anything about how "svn copy -r REV" acted in svn 1.4. I would assume
>> "operative revision", and the above commit message seems to imply that
>> peg defaulted to REV here (not HEAD) and that that changed in 1.5.0, but
>> that is a wild guess (svnbook 1.4 does not so anything).
>
> What happened is that I noticed that the code stopped working after svn
> 1.5 was released. Previously I wrote it to detect the merge properties
> as left by SVK and the experimental/contrib python script for merging.
> I was testing at times using trunk SVN versions. You could probably
> figure it out by running ffab6268^ with svn 1.4.x vs svn 1.5.x if you
> cared. My comment tries to explain what you describe above, but without
> the correct terms. I could see via experimentation what the difference
> was between "-r N" and '/path@N', and that the behaviour changed in svn
> 1.5. Apologies for not explaining this thoroughly enough in the
> submitted description!
Hmm, I was hoping that someone would say something like:
"This test does not depend on the difference between the peg revision
and the operative revision, because the history represented in the test
repo is so simple that there *is* no difference, so Acked By: ... "
But, since that didn't happen, maybe the patch given below would be more
acceptable? (I personally prefer the original patch ...)
Given that I didn't quite follow Sam's explanation, I still don't know
if t9104-git-svn-follow-parent.sh needs to be changed (again, this test
*passes* for me), so ... :-P
ATB,
Ramsay Jones
-- >8 --
Subject: [PATCH] t9159-*.sh: Add an svn version check
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
t/t9159-git-svn-no-parent-mergeinfo.sh | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/t/t9159-git-svn-no-parent-mergeinfo.sh b/t/t9159-git-svn-no-parent-mergeinfo.sh
index 85120b7..69e4815 100755
--- a/t/t9159-git-svn-no-parent-mergeinfo.sh
+++ b/t/t9159-git-svn-no-parent-mergeinfo.sh
@@ -2,6 +2,14 @@
test_description='git svn handling of root commits in merge ranges'
. ./lib-git-svn.sh
+svn_ver="$(svn --version --quiet)"
+case $svn_ver in
+0.* | 1.[0-4].*)
+ skip_all="skipping git-svn test - SVN too old ($svn_ver)"
+ test_done
+ ;;
+esac
+
test_expect_success 'test handling of root commits in merge ranges' '
mkdir -p init/trunk init/branches init/tags &&
echo "r1" > init/trunk/file.txt &&
--
1.7.6
^ permalink raw reply related
* [PATCH 4/2] remote: only update remote-tracking branch if updating refspec
From: Martin von Zweigbergk @ 2011-09-10 19:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Jeff King, Martin von Zweigbergk
In-Reply-To: <7vr53rx9r6.fsf@alter.siamese.dyndns.org>
'git remote rename' will only update the remote's fetch refspec if it
looks like a default one. If the remote has no default fetch refspec,
as in
[remote "origin"]
url = git://git.kernel.org/pub/scm/git/git.git
fetch = +refs/heads/*:refs/remotes/upstream/*
we would not update the fetch refspec and even if there is a ref
called "refs/remotes/origin/master", we should not rename it, since it
was not created by fetching from the remote.
Suggested-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
---
Some questions on style:
1. Should I wrap the statement in "else" block in braces when "then"
block has braces? I couldn't find anything conclusive by looking at
existing code.
2. Is it ok (as I did) to return from the function prematurely even
though it is not an error case? This will of course make the
function more brittle when it comes to adding code at the end of
it. Would you prefer to invert the condition and put the remainder
of the function inside the "then" block? Or even to extract the
code into a new function?
builtin/remote.c | 10 +++++++---
t/t5505-remote.sh | 3 ++-
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/builtin/remote.c b/builtin/remote.c
index 61326cb..b25dfb4 100644
--- a/builtin/remote.c
+++ b/builtin/remote.c
@@ -625,7 +625,7 @@ static int mv(int argc, const char **argv)
old_remote_context = STRBUF_INIT;
struct string_list remote_branches = STRING_LIST_INIT_NODUP;
struct rename_info rename;
- int i;
+ int i, refspec_updated = 0;
if (argc != 3)
usage_with_options(builtin_remote_rename_usage, options);
@@ -667,12 +667,13 @@ static int mv(int argc, const char **argv)
strbuf_reset(&buf2);
strbuf_addstr(&buf2, oldremote->fetch_refspec[i]);
ptr = strstr(buf2.buf, old_remote_context.buf);
- if (ptr)
+ if (ptr) {
+ refspec_updated = 1;
strbuf_splice(&buf2,
ptr-buf2.buf + strlen(":refs/remotes/"),
strlen(rename.old), rename.new,
strlen(rename.new));
- else
+ } else
warning("Not updating non-default fetch respec\n"
"\t%s\n"
"\tPlease update the configuration manually if necessary.",
@@ -695,6 +696,9 @@ static int mv(int argc, const char **argv)
}
}
+ if (!refspec_updated)
+ return 0;
+
/*
* First remove symrefs, then rename the rest, finally create
* the new symrefs.
diff --git a/t/t5505-remote.sh b/t/t5505-remote.sh
index 15186c8..e8af615 100755
--- a/t/t5505-remote.sh
+++ b/t/t5505-remote.sh
@@ -637,7 +637,8 @@ test_expect_success 'rename does not update a non-default fetch refspec' '
(cd four.one &&
git config remote.origin.fetch +refs/heads/*:refs/heads/origin/* &&
git remote rename origin upstream &&
- test "$(git config remote.upstream.fetch)" = "+refs/heads/*:refs/heads/origin/*")
+ test "$(git config remote.upstream.fetch)" = "+refs/heads/*:refs/heads/origin/*" &&
+ git rev-parse -q origin/master)
'
--
1.7.7.rc0.317.gd0afe
^ permalink raw reply related
* [PATCH] contrib: add a credential helper for Mac OS X's keychain
From: Jay Soffian @ 2011-09-10 19:44 UTC (permalink / raw)
To: git; +Cc: Jay Soffian, Junio C Hamano, Jeff King
A credential helper which uses /usr/bin/security to add, search,
and remove entries from the Mac OS X keychain.
Tested with 10.6.8.
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
---
This is a quick script to explore the new credential API. A more robust
implementation would be to link to OS X's Security framework from C.
contrib/credential/git-credential-osxkeychain | 148 +++++++++++++++++++++++++
1 files changed, 148 insertions(+), 0 deletions(-)
create mode 100755 contrib/credential/git-credential-osxkeychain
diff --git a/contrib/credential/git-credential-osxkeychain b/contrib/credential/git-credential-osxkeychain
new file mode 100755
index 0000000000..ae5ec00d68
--- /dev/null
+++ b/contrib/credential/git-credential-osxkeychain
@@ -0,0 +1,148 @@
+#!/usr/bin/python
+# Copyright 2011 Jay Soffian. All rights reserved.
+# FreeBSD License.
+"""
+A git credential helper that interfaces with the Mac OS X keychain via
+/usr/bin/security.
+"""
+
+import os
+import re
+import sys
+import termios
+from getpass import _raw_input
+from optparse import OptionParser
+from subprocess import Popen, PIPE
+
+USERNAME = 'USERNAME'
+PASSWORD = 'PASSWORD'
+PROMPTS = dict(USERNAME='Username', PASSWORD='Password')
+
+def prompt_tty(what, desc):
+ """Prompt on TTY for username or password with optional description"""
+ prompt = '%s%s: ' % (PROMPTS[what], " for '%s'" % desc if desc else '')
+ # Borrowed mostly from getpass.py
+ fd = os.open('/dev/tty', os.O_RDWR|os.O_NOCTTY)
+ tty = os.fdopen(fd, 'w+', 1)
+ if what == USERNAME:
+ return _raw_input(prompt, tty, tty)
+ old = termios.tcgetattr(fd) # a copy to save
+ new = old[:]
+ new[3] &= ~termios.ECHO # 3 == 'lflags'
+ try:
+ termios.tcsetattr(fd, termios.TCSADRAIN, new)
+ return _raw_input(prompt, tty, tty)
+ finally:
+ termios.tcsetattr(fd, termios.TCSADRAIN, old)
+ tty.write('\n')
+
+def emit_user_pass(username, password):
+ if username:
+ print 'username=' + username
+ if password:
+ print 'password=' + password
+
+def make_security_args(command, protocol, hostname, username):
+ args = ['/usr/bin/security', command]
+ # tlfd is 'dflt' backwards - obvious /usr/bin/security bug
+ # but allows us to ignore matching saved web forms.
+ args.extend(['-t', 'tlfd'])
+ args.extend(['-r', protocol])
+ if hostname:
+ args.extend(['-s', hostname])
+ if username:
+ args.extend(['-a', username])
+ return args
+
+def find_internet_password(protocol, hostname, username):
+ args = make_security_args('find-internet-password',
+ protocol, hostname, username)
+ args.append('-g') # asks for password on stderr
+ p = Popen(args, stdin=PIPE, stdout=PIPE, stderr=PIPE)
+ # grok stdout for username
+ out, err = p.communicate()
+ if p.returncode != 0:
+ return
+ for line in out.splitlines(): # pylint:disable-msg=E1103
+ m = re.search(r'^\s+"acct"<blob>=[^"]*"(.*)"$', line)
+ if m:
+ username = m.group(1)
+ break
+ # grok stderr for password
+ m = re.search(r'^password:[^"]*"(.*)"$', err)
+ if not m:
+ return
+ emit_user_pass(username, m.group(1))
+ return True
+
+def delete_internet_password(protocol, hostname, username):
+ args = make_security_args('delete-internet-password',
+ protocol, hostname, username)
+ p = Popen(args, stdin=PIPE, stdout=PIPE, stderr=PIPE)
+ p.communicate()
+
+def add_internet_password(protocol, hostname, username, password):
+ # We do this over a pipe so that we can provide the password more
+ # securely than as an argument which would show up in ps output.
+ # Unfortunately this is possibly less robust since the security man
+ # page does not document how to quote arguments. Emprically it seems
+ # that using the double-quote, escaping \ and " works properly.
+ username = username.replace('\\', '\\\\').replace('"', '\\"')
+ password = password.replace('\\', '\\\\').replace('"', '\\"')
+ command = ' '.join([
+ 'add-internet-password', '-U',
+ '-r', protocol,
+ '-s', hostname,
+ '-a "%s"' % username,
+ '-w "%s"' % password,
+ '-j default',
+ '-l "%s (%s)"' % (hostname, username),
+ ]) + '\n'
+ args = ['/usr/bin/security', '-i']
+ p = Popen(args, stdin=PIPE, stdout=PIPE, stderr=PIPE)
+ p.communicate(command)
+
+def main():
+ p = OptionParser()
+ p.add_option('--description')
+ p.add_option('--reject', action='store_true')
+ p.add_option('--unique', dest='token', help='REQUIRED OPTION')
+ p.add_option('--username')
+ opts, _ = p.parse_args()
+
+ if not opts.token:
+ p.error('--unique option required')
+ if not ':' in opts.token:
+ print >> sys.stderr, "Invalid token: '%s'" % opts.token
+ return 1
+ protocol, hostname = opts.token.split(':', 1)
+ if protocol not in ('http', 'https'):
+ print >> sys.stderr, "Unsupported protocol: '%s'" % protocol
+ return 1
+ if protocol == 'https':
+ protocol = 'htps'
+
+ # "GitHub for Mac" compatibility
+ if hostname == 'github.com':
+ hostname = 'github.com/mac'
+
+ # if this is a rejection delete the existing creds
+ if opts.reject:
+ delete_internet_password(protocol, hostname, opts.username)
+ return 0
+
+ # otherwise look for creds
+ if find_internet_password(protocol, hostname, opts.username):
+ return 0
+
+ # creds not found, so prompt the user then store the creds
+ username = opts.username
+ if username is None:
+ username = prompt_tty(USERNAME, opts.description)
+ password = prompt_tty(PASSWORD, opts.description)
+ add_internet_password(protocol, hostname, username, password)
+ emit_user_pass(username, password)
+ return 0
+
+if __name__ == '__main__':
+ sys.exit(main())
--
1.7.6.346.g5a895
^ permalink raw reply related
* Re: [PATCH v3 0/4] Signed push
From: Robin H. Johnson @ 2011-09-10 20:05 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
Cc: Sverre Rabbelier, Jeff King, Shawn O. Pearce
In-Reply-To: <7vehzopdga.fsf@alter.siamese.dyndns.org>
On Sat, Sep 10, 2011 at 09:30:29AM -0700, Junio C Hamano wrote:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>
> > I think this is also some further motivation to have a
>
> Did you miss that I already mentioned that workaround? It does not _fix_
> the fundamental breakage, which is that you are _forcing_ the sending side
> to keep copies, though.
In the case of a shared Git repo, I'd like to pull copies added by other
developers, so that I can verify the content locally as well. In that
case, I'd need to have copies of the certificates I created as well.
--
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail : robbat2@gentoo.org
GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
^ permalink raw reply
* Re: [PATCH v3 0/4] Signed push
From: Ted Ts'o @ 2011-09-10 19:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, git, Jeff King, Shawn O. Pearce
In-Reply-To: <7vehzopdga.fsf@alter.siamese.dyndns.org>
On Sat, Sep 10, 2011 at 09:30:29AM -0700, Junio C Hamano wrote:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>
> > I think this is also some further motivation to have a
>
> Did you miss that I already mentioned that workaround? It does not _fix_
> the fundamental breakage, which is that you are _forcing_ the sending side
> to keep copies, though.
I guess I'm confused about what the problem is with this?
If I do something like this:
git tag -s -m for_linus-20110910 for_linus-20110910
git push github
git push --tags github
I'm "forcing" the sending side to keep the signed tag, no? Isn't that
kind of implicit in allowing someone to push to your repo?
- Ted
^ permalink raw reply
* Re: [PATCH v3 0/4] Signed push
From: Junio C Hamano @ 2011-09-11 1:42 UTC (permalink / raw)
To: Ted Ts'o; +Cc: Sverre Rabbelier, git, Jeff King, Shawn O. Pearce
In-Reply-To: <20110910192225.GA5397@thunk.org>
Ted Ts'o <tytso@mit.edu> writes:
> I guess I'm confused about what the problem is with this?
Yeah, I have to agree.
> If I do something like this:
>
> git tag -s -m for_linus-20110910 for_linus-20110910
> git push github
> git push --tags github
>
> I'm "forcing" the sending side to keep the signed tag, no?
No, you are not forced to _keep_ it. After pushing you can delete it
locally.
The reason your "tag" example is fundamentally different is because a tag
like for_linus_20110910 is a one-shot thing and you can choose to remove
it from your local namespace once you are done pushing. It does not affect
your ability to make another signed tag for_linus_20110911 before pushing
tomorrow.
The point in this round of "signed push" topic is to allow people not tag
every time before they push, making it easier to sign their pushes to
encourage it, so that other people can have a way to verify the commits
near the tip of branches that are not still tagged in between releases.
Instead of contaminating refs/tags/ namespace with daily tags, the idea
was to keep a single "signed-push" notes tree on the receiving end (which
is the distribution point for consumers) that contain the signed record of
pushes.
The original "signed push" (what I called v2) design was for the sender to
prepare the record that goes into the notes tree, but record the notes
tree at the receiving end (this does _not_ prevent the sender from
fetching it back to keep his local copy, but the sender is _not_ required
to do so). It needs updates to both sending and receiving end.
An alternative idea (which I implemented as v3) that came up during the
discussion was to instead have the sender add this record locally to the
signed-push notes tree, and push it out along with the branches. For this
push not to lose _existing_ records of pushes at the receiving end, the
pusher is required to have an up-to-date copy of signed-push notes tree,
and add the new record to it before pushing it out. One upside is that
this does not need updates to receiving end.
I do not know if you read the message Sverre was responding to, but the
"you have to have local copy" requirement has another and potentially
bigger downside (which Sverre did not quote) for people who push out to
multiple places.
Perhaps we shouldn't worry about tag namespace contamination to make
things easier and simpler and stop using notes tree?
^ permalink raw reply
* "git archive" seems to be broken wrt zip files
From: Linus Torvalds @ 2011-09-11 4:58 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
So I wouldn't ever have noticed on my own, but now that I've tried
github for the kernel, somebody else reported that the downloaded zip
file (seriously? the kernel as a zip file?) is corrupt.
And it doesn't really seem to be a github issue. I can re-create it
with a simple
git archive --format=zip HEAD -o ../kernel.zip
on my kernel repository: the end result does not unzip correctly:
mkdir temp-directory
cd temp-directory
unzip kernel.zip
...
inflating: virt/kvm/iommu.c
inflating: virt/kvm/irq_comm.c
inflating: virt/kvm/kvm_main.c
finishing deferred symbolic links:
arch/microblaze/boot/dts/system.dts -> ../../platform/generic/system.dts
drivers/scsi/aic94xx/aic94xx_reg.h -> /*^J * Aic94xx SAS/SATA
driver hardware registers definitions.[ rest of the file ]
symlink error: File name too long
iow, for some reason that "drivers/scsi/aic94xx/aic94xx_reg.h" file
seems to have been encoded as a symlink.
Anybody seen this?
Linus
^ permalink raw reply
* Re: "git archive" seems to be broken wrt zip files
From: Jeff King @ 2011-09-11 6:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: René Scharfe, Junio C Hamano, Git Mailing List
In-Reply-To: <CA+55aFx43OxExGNrJs+AyKNtdr+KCZZoE=iaQTz8uHoUSrQv0w@mail.gmail.com>
On Sat, Sep 10, 2011 at 09:58:08PM -0700, Linus Torvalds wrote:
> So I wouldn't ever have noticed on my own, but now that I've tried
> github for the kernel, somebody else reported that the downloaded zip
> file (seriously? the kernel as a zip file?) is corrupt.
>
> And it doesn't really seem to be a github issue. I can re-create it
> with a simple
>
> git archive --format=zip HEAD -o ../kernel.zip
>
> on my kernel repository: the end result does not unzip correctly:
Hmm. I can easily replicate the problem here, but interestingly it does
not happen with sub-trees like:
git archive --format=zip HEAD:drivers -o ../kernel.zip
Going back in history, I can replicate it with René's 62cdce1
(git-archive --format=zip: add symlink support, 2006-10-07). So there's
nothing to bisect.
Cc'ing René.
-Peff
^ permalink raw reply
* Re: "git archive" seems to be broken wrt zip files
From: Jeff King @ 2011-09-11 6:27 UTC (permalink / raw)
To: Linus Torvalds; +Cc: René Scharfe, Junio C Hamano, Git Mailing List
In-Reply-To: <20110911062206.GA29620@sigill.intra.peff.net>
On Sun, Sep 11, 2011 at 02:22:06AM -0400, Jeff King wrote:
> Hmm. I can easily replicate the problem here, but interestingly it does
> not happen with sub-trees like:
>
> git archive --format=zip HEAD:drivers -o ../kernel.zip
>
> Going back in history, I can replicate it with René's 62cdce1
> (git-archive --format=zip: add symlink support, 2006-10-07). So there's
> nothing to bisect.
Weirder still. I get roughly the same output as you:
finishing deferred symbolic links:
arch/microblaze/boot/dts/system.dts -> ../../platform/generic/system.dts
drivers/scsi/aic94xx/aic94xx_reg.h -> /*^J * Aic94xx SAS/SATA driver...
But looking at the generated file with zipinfo, I see:
$ zipinfo kernel.zip
...
lrwxrwxrwx 2.3 unx 33 b- stor 11-Aug-25 14:02 arch/microblaze/boot/dts/system.dts
...
-rw---- 0.0 fat 10470 b- defN 11-Aug-25 14:02 drivers/scsi/aic94xx/aic94xx_reg.h
IOW, the zip file looks right. I wonder if this is actually a bug in
"unzip".
-Peff
^ permalink raw reply
* Re: [PATCH v3 0/4] Signed push
From: Sverre Rabbelier @ 2011-09-11 8:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ted Ts'o, git, Jeff King, Shawn O. Pearce
In-Reply-To: <7v4o0jq2fx.fsf@alter.siamese.dyndns.org>
Heya,
On Sun, Sep 11, 2011 at 03:42, Junio C Hamano <gitster@pobox.com> wrote:
> I do not know if you read the message Sverre was responding to, but the
> "you have to have local copy" requirement has another and potentially
> bigger downside (which Sverre did not quote) for people who push out to
> multiple places.
That's not what I meant though. I was responding to your "than you can
later _inspect_ the certificates from multiple locations". I was
indicating that it would be easier to do such inspection if you can
optionally fetch the notes from different remotes to different
locations in the refs/remotes namespace.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Git wiki down?
From: suvayu ali @ 2011-09-11 11:56 UTC (permalink / raw)
To: git
Is something wrong with the git wiki?
$ ping http://git.wiki.kernel.org/
ping: unknown host http://git.wiki.kernel.org/
On the browser I get redirected to the OpenDNS page when there is a
DNS problem for some site. The OpenDNS cache also says there is no
such site. Was the git wiki affected in the recent DNS hack?
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply
* Re: Git wiki down?
From: Carlos Martín Nieto @ 2011-09-11 11:59 UTC (permalink / raw)
To: suvayu ali; +Cc: git
In-Reply-To: <CAMXnza1fwgup_YbbrvM7egpZnaUBBV935x4ib72MO=TmvHS3Bg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 519 bytes --]
On Sun, 2011-09-11 at 13:56 +0200, suvayu ali wrote:
> Is something wrong with the git wiki?
>
> $ ping http://git.wiki.kernel.org/
> ping: unknown host http://git.wiki.kernel.org/
>
> On the browser I get redirected to the OpenDNS page when there is a
> DNS problem for some site. The OpenDNS cache also says there is no
> such site. Was the git wiki affected in the recent DNS hack?
The kernel.org site and associated services are down for maintenance, as
it says on the main web page.
cmn
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
^ permalink raw reply
* Re: Git wiki down?
From: Suvayu Ali @ 2011-09-11 12:14 UTC (permalink / raw)
To: Carlos Martín Nieto; +Cc: git
In-Reply-To: <1315742361.4370.0.camel@centaur.lab.cmartin.tk>
On Sun, 11 Sep 2011 13:59:12 +0200
Carlos Martín Nieto <cmn@elego.de> wrote:
> The kernel.org site and associated services are down for maintenance,
> as it says on the main web page.
>
Thanks a lot Carlos. Sorry for not checking thoroughly.
> cmn
--
Suvayu
Open source is the future. It sets us free.
^ permalink raw reply
* [PATCH] SubmittingPathces: remove Cogito reference
From: Sverre Rabbelier @ 2011-09-11 12:38 UTC (permalink / raw)
To: Junio C Hamano, Git List; +Cc: Sverre Rabbelier
Removing Cogito leaves just git and StGit, which is a rather
incomplete list of git diff tools available. Sidestep the problem
of deciding what tools to mention by not mentioning any.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Reading `git log -p --reverse Documentation/SubmittingPatches` [0]
I noticed the Cogito reference was never removed. In the light of
the recent discussion about removing Cogito from the GitSurvey I
figured now might be a good time to remove this reference as well.
[0] https://plus.google.com/115991361267198418069/posts/NPa7vQYeMnm
Documentation/SubmittingPatches | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/Documentation/SubmittingPatches b/Documentation/SubmittingPatches
index 938eccf..0dbf2c9 100644
--- a/Documentation/SubmittingPatches
+++ b/Documentation/SubmittingPatches
@@ -134,8 +134,7 @@ Another thing: NULL pointers shall be written as NULL, not as 0.
(2) Generate your patch using git tools out of your commits.
-git based diff tools (git, Cogito, and StGIT included) generate
-unidiff which is the preferred format.
+git based diff tools generate unidiff which is the preferred format.
You do not have to be afraid to use -M option to "git diff" or
"git format-patch", if your patch involves file renames. The
--
1.7.6.1.724.g9519c
^ permalink raw reply related
* Re: "git archive" seems to be broken wrt zip files
From: Andreas Schwab @ 2011-09-11 13:14 UTC (permalink / raw)
To: Jeff King
Cc: Linus Torvalds, René Scharfe, Junio C Hamano,
Git Mailing List
In-Reply-To: <20110911062740.GA8018@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> IOW, the zip file looks right. I wonder if this is actually a bug in
> "unzip".
It is. This only happens if you have more then 16k entries and when one
of the 16k entry infos is reused it happend to be previously used for a
symlink entry.
Here's a patch for unzip60 for reference:
--- process.c
+++ process.c
@@ -1751,6 +1751,12 @@ int process_cdir_file_hdr(__G) /* ret
= (G.crec.general_purpose_bit_flag & (1 << 11)) == (1 << 11);
#endif
+#ifdef SYMLINKS
+ /* Initialize the symlink flag, may be set by the platform-specific
+ mapattr function. */
+ G.pInfo->symlink = 0;
+#endif
+
return PK_COOL;
} /* end function process_cdir_file_hdr() */
Andreas.
--
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5
"And now for something completely different."
^ permalink raw reply
* Re: "git archive" seems to be broken wrt zip files
From: René Scharfe @ 2011-09-11 15:38 UTC (permalink / raw)
To: Andreas Schwab
Cc: Jeff King, Linus Torvalds, Junio C Hamano, Git Mailing List
In-Reply-To: <m239g3i5kz.fsf@igel.home>
Am 11.09.2011 15:14, schrieb Andreas Schwab:
> Jeff King <peff@peff.net> writes:
>
>> IOW, the zip file looks right. I wonder if this is actually a bug in
>> "unzip".
>
> It is. This only happens if you have more then 16k entries and when one
> of the 16k entry infos is reused it happend to be previously used for a
> symlink entry.
>
> Here's a patch for unzip60 for reference:
Oh, thanks, now I can stop scratching my head while trying to find my
way around unzip's source and its amazing OS compatibility code.
On Windows (the main target for ZIP file support in git archive), 7-Zip,
the unzip from msysgit and the native ZIP support extract the archive
without any issues (except for 13 files whose names only differ
upper/lower case of some chars to 13 other files), by the way. Since
they lack symlink support, the target path of
arch/microblaze/boot/dts/system.dts is simply written to a regular file,
though.
René
^ permalink raw reply
* [PATCH] Support empty blob in fsck --lost-found
From: BJ Hargrave @ 2011-09-11 15:40 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
fsck --lost-found died when attempting to write out the empty blob.
Avoid calling fwrite when the blob size is zero since the call to
fwrite returns 0 objects written which fails the check and caused
fsck to die.
Signed-off-by: BJ Hargrave <bj@bjhargrave.com>
---
builtin/fsck.c | 7 ++++---
t/t1420-lost-found.sh | 13 ++++++++-----
2 files changed, 12 insertions(+), 8 deletions(-)
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 5ae0366..ad6d713 100644
--- a/builtin/fsck.c
+++ b/builtin/fsck.c
@@ -232,9 +232,10 @@ static void check_unreachable_object(struct object *obj)
char *buf = read_sha1_file(obj->sha1,
&type, &size);
if (buf) {
- if (fwrite(buf, size, 1, f) != 1)
- die_errno("Could not write '%s'",
- filename);
+ if (size > 0)
+ if (fwrite(buf, size, 1, f) != 1)
+ die_errno("Could not write '%s'",
+ filename);
free(buf);
}
} else
diff --git a/t/t1420-lost-found.sh b/t/t1420-lost-found.sh
index dc9e402..02323c9 100755
--- a/t/t1420-lost-found.sh
+++ b/t/t1420-lost-found.sh
@@ -8,7 +8,7 @@ test_description='Test fsck --lost-found'
test_expect_success setup '
git config core.logAllRefUpdates 0 &&
- : > file1 &&
+ echo x > file1 &&
git add file1 &&
test_tick &&
git commit -m initial &&
@@ -18,18 +18,21 @@ test_expect_success setup '
test_tick &&
git commit -m second &&
echo 3 > file3 &&
- git add file3
+ : > file4 &&
+ git add file3 file4
'
test_expect_success 'lost and found something' '
git rev-parse HEAD > lost-commit &&
- git rev-parse :file3 > lost-other &&
+ git rev-parse :file3 > lost-other3 &&
+ git rev-parse :file4 > lost-other4 &&
test_tick &&
git reset --hard HEAD^ &&
git fsck --lost-found &&
- test 2 = $(ls .git/lost-found/*/* | wc -l) &&
+ test 3 = $(ls .git/lost-found/*/* | wc -l) &&
test -f .git/lost-found/commit/$(cat lost-commit) &&
- test -f .git/lost-found/other/$(cat lost-other)
+ test -f .git/lost-found/other/$(cat lost-other3) &&
+ test -f .git/lost-found/other/$(cat lost-other4)
'
test_done
--
1.7.6.2
^ permalink raw reply related
* Re: [PATCH v3 0/4] Signed push
From: Ted Ts'o @ 2011-09-11 15:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, git, Jeff King, Shawn O. Pearce
In-Reply-To: <7v4o0jq2fx.fsf@alter.siamese.dyndns.org>
On Sat, Sep 10, 2011 at 06:42:58PM -0700, Junio C Hamano wrote:
> Perhaps we shouldn't worry about tag namespace contamination to make
> things easier and simpler and stop using notes tree?
With the appropriate conventions, such as using a tag name such as
signed-<email>-<timestamp>" we can at least avoid name conflicts, at
least for all practical purposes.
There is the additional problem that "git tag -l" gets painful. At
least for me, though, it's already mostly useless:
% git tag -l | grep ^v[23] | wc -l
858
I can work around this with git aliases that filter out certain
prefixes that I normally don't care about, but maybe that's something
that should be directly supported in git-tag with some git-config
parameters.
The final issue that I'd worry about with using tags is performance.
If we have hundreds of thousands or millions of tags of the form
signed-<email>-<timestamp>, is this going to be a problem? This does
seem like something that could be worked around --- in the worst case
there could just be a locally maintained reverse index from git commit
id's to tag names. (Although as I recall Linus objected to having
something like this for time skews, so maybe he'd object to this too.)
- Ted
^ permalink raw reply
* Re: [PATCH] Support empty blob in fsck --lost-found
From: Sverre Rabbelier @ 2011-09-11 16:03 UTC (permalink / raw)
To: BJ Hargrave; +Cc: git, Junio C Hamano
In-Reply-To: <A3964281-B24B-46C0-AE73-0CCB4C12556F@bjhargrave.com>
Heya,
On Sun, Sep 11, 2011 at 17:40, BJ Hargrave <bj@bjhargrave.com> wrote:
> fsck --lost-found died when attempting to write out the empty blob.
> Avoid calling fwrite when the blob size is zero since the call to
> fwrite returns 0 objects written which fails the check and caused
> fsck to die.
Now we don't die at all if a 0-byte file couldn't be written.
Shouldn't we check errno or something?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox