* Re: [PATCH 1/2] git-p4: Improve rename detection support.
From: Pete Wyckoff @ 2011-02-06 0:21 UTC (permalink / raw)
To: Vitor Antunes; +Cc: git
In-Reply-To: <1296429563-18390-1-git-send-email-vitor.hda@gmail.com>
vitor.hda@gmail.com wrote on Sun, 30 Jan 2011 23:19 +0000:
> Only open files for edit after integrating if the SHA1 of source and destination
> differ from each other.
> Add git config option detectRenames to allow permanent rename detection. This
> options should be set to a true/false value.
I like the idea.
> def applyCommit(self, id):
> print "Applying %s" % (read_pipe("git log --max-count=1 --pretty=oneline %s" % id))
> - diffOpts = ("", "-M")[self.detectRename]
> +
> + detectRenames = gitConfig("git-p4.detectRenames")
> + if len(detectRenames) and detectRenames.lower() != "false" > 0:
> + diffOpts = "-M"
> + else:
> + diffOpts = ("", "-M")[self.detectRename]
The comparisons confuse me. detectRenames != "false" > 0 ?
How about just detectRenames == "true"?
You could rename the existing self.detectRename to add an "s" so
it all makes a bit more sense.
if not self.detectRenames:
# not explicitly set, check the config variable
b = gitConfig("git-p4.detectRenames")
if b == "true":
self.detectRenames = "-M"
if self.detectRenames:
diffOpts = "-M"
else:
diffOpts = ""
> diff = read_pipe_lines("git diff-tree -r %s \"%s^\" \"%s\"" % (diffOpts, id, id))
> filesToAdd = set()
> filesToDelete = set()
> @@ -640,7 +646,8 @@ class P4Submit(Command):
> elif modifier == "R":
> src, dest = diff['src'], diff['dst']
> p4_system("integrate -Dt \"%s\" \"%s\"" % (src, dest))
> - p4_system("edit \"%s\"" % (dest))
> + if diff['src_sha1'] != diff['dst_sha1']:
> + p4_system("edit \"%s\"" % (dest))
> if isModeExecChanged(diff['src_mode'], diff['dst_mode']):
> filesToChangeExecBit[dest] = diff['dst_mode']
> os.unlink(dest)
If you rename the file and also cause its perms to change (say
add +x), does it still work if dest is not open?
-- Pete
^ permalink raw reply
* Re: [idea] separate .git dir and the working tree
From: Mike Gant @ 2011-02-06 0:20 UTC (permalink / raw)
To: git; +Cc: Jonathan Nieder, redstun
In-Reply-To: <20110205132708.GA18391@elie>
On Sat, Feb 05, 2011 at 07:27:08AM -0600, Jonathan Nieder wrote:
> (restoring cc list; please do not cull cc's)
My apologies, but I didn't see a cc list in the original. Please
explain.
-Mike
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Johan Herland @ 2011-02-06 0:04 UTC (permalink / raw)
To: Dmitry Potapov
Cc: git, Junio C Hamano, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <20110205214045.GA15668@dpotapov.dyndns.org>
On Saturday 05 February 2011, Dmitry Potapov wrote:
> On Sat, Feb 05, 2011 at 02:18:44AM +0100, Johan Herland wrote:
> > Having said that, there are real situations where users encounter
> > collisions in the shared tag namespace. A rare (but plausible)
> > scenario arise when two developers create (and publish) conflicting
> > tags in their repos. A more common scenario that I have encountered at
> > $dayjob, is where two parallel (semi-related) projects are developed
> > in separate repos (with different versioning because of separate
> > release schedules), and I need to interface with both repos from a
> > single local repo. Each of the remote repos have their own "v1.0" tag,
> > but my repo can only hold one such tag. Which of those tags end up
> > "winning" in my local repo depends on my fetch order.
>
> Well, I agree that this situation requires a better diagnostic, but I
> don't think that having separate namespaces is the right solution in
> general. For your case, where you work on semi-related projects, it is
> could be the right thing to do, but if you work on the same project and
> have more than one source to fetch, then having multiple namespaces can
> lead only to confusion, because tag names must be unique globally to
> make sense to everyone. Actually, even if you have two semi-related
> projects in the same repository, but you have more than one URL per
> project, you want to group tags based on their relation to the project
> and not based on the URL.
I'm not sure what problem you're describing here. Let's assume that my repo
has multiple remotes (URLs), but they're all fundamentally part of the same
project. If there is a tag "foo" in one remote/namespace, and a tag "foo" in
a different remote/namespace, they (in the common case) point to the same
object, since they - as you say - "must be unique globally to make sense to
everyone".
As long as they point to the same object, there's no ambiguity, and when you
simply refer to tag "foo" (without specifying namespace) it all works, like
today. (Read footnote [2] of my proposal for more details on handling
ambiguity in tag names.)
However, when the remote tags point to different objects (i.e. the uncommon
case), there is an ambiguity, and we should deal with that ambiguity
properly, instead of silently adopting one of them arbitrarily.
I don't see how the separate namespaces cause problems here. Also, I don't
know what you're proposing instead, or indeed what other organization of
tags would lead to less confusion.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH] git-send-email.perl: Add --suppress-to
From: Joe Perches @ 2011-02-05 23:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk4jzpq8h.fsf@alter.siamese.dyndns.org>
Add an equivalent command line option to suppress-cc.
Signed-off-by: Joe Perches <joe@perches.com>
---
Documentation/git-send-email.txt | 17 +++++++++++++++++
git-send-email.perl | 33 +++++++++++++++++++++++++++++++--
2 files changed, 48 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index 7ec9dab..69e03e8 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -232,6 +232,23 @@ Automating
cc list. Default is the value of 'sendemail.signedoffbycc' configuration
value; if that is unspecified, default to --signed-off-by-cc.
+--suppress-to=<category>::
+ Specify an additional category of recipients to suppress the
+ auto-to of:
++
+--
+- 'author' will avoid including the patch author
+- 'self' will avoid including the sender
+- 'tocmd' will avoid running the --to-cmd
+- 'bodyto' will avoid including anyone mentioned in To lines in the
+ patch body (commit message) except for self (use 'self' for that)
+- 'all' will suppress all auto to values.
+--
++
+Default is the value of 'sendemail.suppressto' configuration value; if
+that is unspecified, default to 'self' if --suppress-from is
+specified.
+
--suppress-cc=<category>::
Specify an additional category of recipients to suppress the
auto-cc of:
diff --git a/git-send-email.perl b/git-send-email.perl
index 76565de..0365c29 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -74,6 +74,7 @@ git send-email [options] <file | directory | rev-list options >
Automating:
--identity <str> * Use the sendemail.<id> options.
--to-cmd <str> * Email To: via `<str> \$patch_path`
+ --suppress-to <str> * author, self, tocmd, bodyto, all.
--cc-cmd <str> * Email Cc: via `<str> \$patch_path`
--suppress-cc <str> * author, self, sob, cc, cccmd, body, bodycc, all.
--[no-]signed-off-by-cc * Send to Signed-off-by: addresses. Default on.
@@ -196,6 +197,7 @@ my ($smtp_server, $smtp_server_port, @smtp_server_options);
my ($smtp_authuser, $smtp_encryption);
my ($identity, $aliasfiletype, @alias_files, $smtp_domain);
my ($validate, $confirm);
+my (@suppress_to);
my (@suppress_cc);
my ($auto_8bit_encoding);
@@ -226,6 +228,7 @@ my %config_settings = (
"aliasfiletype" => \$aliasfiletype,
"bcc" => \@bcclist,
"aliasesfile" => \@alias_files,
+ "suppressto" => \@suppress_to,
"suppresscc" => \@suppress_cc,
"envelopesender" => \$envelope_sender,
"multiedit" => \$multiedit,
@@ -301,6 +304,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"quiet" => \$quiet,
"cc-cmd=s" => \$cc_cmd,
"suppress-from!" => \$suppress_from,
+ "suppress-to=s" => \@suppress_to,
"suppress-cc=s" => \@suppress_cc,
"signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
"confirm=s" => \$confirm,
@@ -369,6 +373,24 @@ foreach my $setting (values %config_bool_settings) {
# 'default' encryption is none -- this only prevents a warning
$smtp_encryption = '' unless (defined $smtp_encryption);
+# Set TO suppressions
+my(%suppress_to);
+if (@suppress_to) {
+ foreach my $entry (@suppress_to) {
+ die "Unknown --suppress-to field: '$entry'\n"
+ unless $entry =~ /^(?:all|author|self|tocmd|bodyto)$/;
+ $suppress_to{$entry} = 1;
+ }
+}
+
+if ($suppress_to{'all'}) {
+ foreach my $entry (qw (author self tocmd bodyto)) {
+ $suppress_to{$entry} = 1;
+ }
+ delete $suppress_to{'all'};
+}
+$suppress_to{'self'} = $suppress_from if defined $suppress_from;
+
# Set CC suppressions
my(%suppress_cc);
if (@suppress_cc) {
@@ -407,7 +429,11 @@ die "Unknown --confirm setting: '$confirm'\n"
# Debugging, print out the suppressions.
if (0) {
- print "suppressions:\n";
+ print "To suppressions:\n";
+ foreach my $entry (keys %suppress_to) {
+ printf " %-5s -> $suppress_to{$entry}\n", $entry;
+ }
+ print "Cc suppressions:\n";
foreach my $entry (keys %suppress_cc) {
printf " %-5s -> $suppress_cc{$entry}\n", $entry;
}
@@ -1201,6 +1227,9 @@ foreach my $t (@files) {
}
elsif (/^To:\s+(.*)$/) {
foreach my $addr (parse_address_line($1)) {
+
+ next if $suppress_to{'author'};
+ next if $suppress_to{'self'} and $author eq $sender;
printf("(mbox) Adding to: %s from line '%s'\n",
$addr, $_) unless $quiet;
push @to, sanitize_address($addr);
@@ -1269,7 +1298,7 @@ foreach my $t (@files) {
close $fh;
push @to, recipients_cmd("to-cmd", "to", $to_cmd, $t)
- if defined $to_cmd;
+ if defined $to_cmd && !$suppress_to{'tocmd'};
push @cc, recipients_cmd("cc-cmd", "cc", $cc_cmd, $t)
if defined $cc_cmd && !$suppress_cc{'cccmd'};
^ permalink raw reply related
* Re: [1.8.0] Provide proper remote ref namespaces
From: Johan Herland @ 2011-02-05 23:39 UTC (permalink / raw)
To: git
Cc: Nicolas Pitre, Jeff King, Junio C Hamano, Sverre Rabbelier,
Nguyen Thai Ngoc Duy
In-Reply-To: <alpine.LFD.2.00.1102051449420.12104@xanadu.home>
On Saturday 05 February 2011, Nicolas Pitre wrote:
> On Sat, 5 Feb 2011, Jeff King wrote:
> > On Sat, Feb 05, 2011 at 01:39:57PM -0500, Nicolas Pitre wrote:
> > > So that's what has to be fixed. If you get duplicated tag names then
> > > just warn the user and give priority to the local one, or error out
> > > with a "ambiguous tag specification" if no local but multiple remote
> > > tags with the same name are found (the user would have to be more
> > > precise in the tag scope in that case).
> >
> > The latter seems like a regression for the common case of fetching from
> > two upstreams. E.g., I usually pull from Junio, getting
> > remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I
> > pull from him, getting remotes/spearce/v1.7.0, which he previously
> > fetched from Junio. Under the current code, I can still do "git show
> > v1.7.0"; under the scheme described above I now have to say
> > "origin/v1.7.0" to disambiguate.
>
> Let's suppose that both tags are identical, as in your scenario above
> they would be, then there is no need to call for any ambiguity in that
> case.
>
> > The real issue, I think, is that we are claiming ambiguity even though
> > those tags almost certainly point to the same sha1. When handling
> > ambiguous tags, should we perhaps check to see if all of the
> > ambiguities point to the same sha1, and in that case, just pick one at
> > random?
>
> If they're identical then there is no randomness. If they refer to
> different tag objects, even if those tag objects do refer to the same
> commit object, then I'd say there is an ambiguity only if the tag object
> content matters i.e. when displaying the tag content.
>
> > In the case of resolving a ref to a sha1, then by definition they are
> > all equivalent to pick. For things that care (e.g., "git checkout") we
> > should probably still complain (although many of those commands have
> > their own disambiguation code to prefer refs/heads/ or whatever
> > anyway).
>
> We are probably more or less saying the same thing.
Yes, I believe this was all covered by a footnote in my proposal. Quote:
[2]: When looking up a shorthand tag name (e.g. v1.7.4): If a local tag
(refs/tags/v1.7.4) is found, then we have an unambiguous match. If no local
tag is found, we look up the tag name in all configured remotes (using the
method described in [1]). If the tag name exists in one or more remotes, and
those remotes all agree on its ultimate object name (after applying e.g.
^{commit} or whatever is appropriate in the context of the lookup), then we
also have an unambiguous match. However, if the tag name exists in multiple
remotes, and they do NOT all agree on its ultimate object name, then the
shorthand tag name is ambiguous and the lookup fails. The user can always
resolve this ambiguity by creating a local tag (refs/tags/v1.7.4) pointing
to the desired object.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* [PATCH 8/8] git-p4: support clone --bare
From: Pete Wyckoff @ 2011-02-05 22:52 UTC (permalink / raw)
To: git
In-Reply-To: <20110205224848.GA30963@arf.padd.com>
Just like git clone --bare, build a .git directory but no
checked out files.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 17 +++++++++++++----
t/t9800-git-p4.sh | 10 ++++++++++
2 files changed, 23 insertions(+), 4 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 5b08cd6..efc5dce 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1771,10 +1771,13 @@ class P4Clone(P4Sync):
help="where to leave result of the clone"),
optparse.make_option("-/", dest="cloneExclude",
action="append", type="string",
- help="exclude depot path")
+ help="exclude depot path"),
+ optparse.make_option("--bare", dest="cloneBare",
+ action="store_true", default=False),
]
self.cloneDestination = None
self.needsGit = False
+ self.cloneBare = False
# This is required for the "append" cloneExclude action
def ensure_value(self, attr, value):
@@ -1814,11 +1817,16 @@ class P4Clone(P4Sync):
self.cloneDestination = self.defaultDestination(args)
print "Importing from %s into %s" % (', '.join(depotPaths), self.cloneDestination)
+
if not os.path.exists(self.cloneDestination):
os.makedirs(self.cloneDestination)
chdir(self.cloneDestination)
- system("git init")
- self.gitdir = os.getcwd() + "/.git"
+
+ init_cmd = [ "git", "init" ]
+ if self.cloneBare:
+ init_cmd.append("--bare")
+ subprocess.check_call(init_cmd)
+
if not P4Sync.run(self, depotPaths):
return False
if self.branch != "master":
@@ -1828,7 +1836,8 @@ class P4Clone(P4Sync):
masterbranch = "refs/heads/p4/master"
if gitBranchExists(masterbranch):
system("git branch master %s" % masterbranch)
- system("git checkout -f")
+ if not self.cloneBare:
+ system("git checkout -f")
else:
print "Could not detect main branch. No checkout/master branch created."
diff --git a/t/t9800-git-p4.sh b/t/t9800-git-p4.sh
index 72c38af..1e7639b 100755
--- a/t/t9800-git-p4.sh
+++ b/t/t9800-git-p4.sh
@@ -87,6 +87,16 @@ test_expect_success 'wildcard files git-p4 clone' '
rm -rf "$git" && mkdir "$git"
'
+test_expect_success 'clone bare' '
+ "$GITP4" clone --dest="$git" --bare //depot &&
+ cd "$git" &&
+ test ! -d .git &&
+ bare=`git config --get core.bare` &&
+ test "$bare" = true &&
+ cd "$TRASH_DIRECTORY" &&
+ rm -rf "$git" && mkdir "$git"
+'
+
test_expect_success 'shutdown' '
pid=`pgrep -f p4d` &&
test -n "$pid" &&
--
1.7.2.3
^ permalink raw reply related
* [PATCH 7/8] git-p4: decode p4 wildcard characters
From: Pete Wyckoff @ 2011-02-05 22:52 UTC (permalink / raw)
To: git
In-Reply-To: <20110205224848.GA30963@arf.padd.com>
There are four wildcard characters in p4. Files with these
characters can be added to p4 repos using the "-f" option.
They are stored in %xx notation, and when checked out, p4
converts them back to normal.
This patch does the same thing when importing into git,
converting the four special characters. Without this change,
the files appear with literal %xx in their names.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 13 +++++++++++++
t/t9800-git-p4.sh | 22 ++++++++++++++++++++++
2 files changed, 35 insertions(+), 0 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 04e6c3d..5b08cd6 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -884,6 +884,18 @@ class P4Sync(Command):
if gitConfig("git-p4.syncFromOrigin") == "false":
self.syncWithOrigin = False
+ # The p4 wildcards are not allowed in filenames. It complains
+ # if you try to add them, but you can override with "-f", in
+ # which case it translates them into %xx encoding. Search for
+ # and fix just these four characters. Do % last so it does
+ # not inadvertantly create new %-escapes.
+ def wildcard_decode(self, path):
+ path = path.replace("%23", "#") \
+ .replace("%2A", "*") \
+ .replace("%40", "@") \
+ .replace("%25", "%")
+ return path
+
def extractFilesFromCommit(self, commit):
self.cloneExclude = [re.sub(r"\.\.\.$", "", path)
for path in self.cloneExclude]
@@ -962,6 +974,7 @@ class P4Sync(Command):
return
relPath = self.stripRepoPath(file['depotFile'], self.branchPrefixes)
+ relPath = self.wildcard_decode(relPath)
if verbose:
sys.stderr.write("%s\n" % relPath)
diff --git a/t/t9800-git-p4.sh b/t/t9800-git-p4.sh
index 41e57bb..72c38af 100755
--- a/t/t9800-git-p4.sh
+++ b/t/t9800-git-p4.sh
@@ -65,6 +65,28 @@ test_expect_success 'exit when p4 fails to produce marshaled output' '
test_must_fail grep -q Traceback errs
'
+test_expect_success 'add p4 files with wildcards in the names' '
+ cd "$cli" &&
+ echo file-wild-hash >file-wild#hash &&
+ echo file-wild-star >file-wild\*star &&
+ echo file-wild-at >file-wild@at &&
+ echo file-wild-percent >file-wild%percent &&
+ p4 add -f file-wild* &&
+ p4 submit -d "file wildcards" &&
+ cd "$TRASH_DIRECTORY"
+'
+
+test_expect_success 'wildcard files git-p4 clone' '
+ "$GITP4" clone --dest="$git" //depot &&
+ cd "$git" &&
+ test -f file-wild#hash &&
+ test -f file-wild\*star &&
+ test -f file-wild@at &&
+ test -f file-wild%percent &&
+ cd "$TRASH_DIRECTORY" &&
+ rm -rf "$git" && mkdir "$git"
+'
+
test_expect_success 'shutdown' '
pid=`pgrep -f p4d` &&
test -n "$pid" &&
--
1.7.2.3
^ permalink raw reply related
* [PATCH 6/8] git-p4: better message for "git-p4 sync" when not cloned
From: Pete Wyckoff @ 2011-02-05 22:52 UTC (permalink / raw)
To: git
In-Reply-To: <20110205224848.GA30963@arf.padd.com>
A common error is to do "git-p4 sync" in a repository that
was not initialized by "git-p4 clone". There will be no
p4 refs. The error message in this case is a traceback
for an assertion, which is confusing.
Change it instead to explain the likely problem.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 6b847c4..04e6c3d 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1676,6 +1676,8 @@ class P4Sync(Command):
changes.sort()
else:
+ if not self.p4BranchesInGit:
+ die("No remote p4 branches. Perhaps you never did \"git p4 clone\" in here.");
if self.verbose:
print "Getting p4 changes for %s...%s" % (', '.join(self.depotPaths),
self.changeRange)
--
1.7.2.3
^ permalink raw reply related
* [PATCH 5/8] git-p4: reinterpret confusing p4 message
From: Pete Wyckoff @ 2011-02-05 22:52 UTC (permalink / raw)
To: git
In-Reply-To: <20110205224848.GA30963@arf.padd.com>
Error output will look like this:
glom$ git p4 clone //deopt
Importing from //deopt into .
Reinitialized existing Git repository in /tmp/x/.git/
Doing initial import of //deopt from revision #head into refs/remotes/p4/master
p4 returned an error: //deopt/... - must refer to client glom.
This particular p4 error is misleading.
Perhaps the depot path was misspelled.
Depot path: //deopt
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index db19b17..6b847c4 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1445,6 +1445,10 @@ class P4Sync(Command):
if 'code' in info and info['code'] == 'error':
sys.stderr.write("p4 returned an error: %s\n"
% info['data'])
+ if info['data'].find("must refer to client") >= 0:
+ sys.stderr.write("This particular p4 error is misleading.\n")
+ sys.stderr.write("Perhaps the depot path was misspelled.\n");
+ sys.stderr.write("Depot path: %s\n" % " ".join(self.depotPaths))
sys.exit(1)
if 'p4ExitCode' in info:
sys.stderr.write("p4 exitcode: %s\n" % info['p4ExitCode'])
--
1.7.2.3
^ permalink raw reply related
* [PATCH 4/8] git-p4: accommodate new move/delete type in p4
From: Pete Wyckoff @ 2011-02-05 22:52 UTC (permalink / raw)
To: git
In-Reply-To: <20110205224848.GA30963@arf.padd.com>
Change 562d53f (2010-11-21) recognized the new move/delete type
for git-p4 sync, but it can also show up in an initial clone and
labels output. Instead of replicating this in three places,
hoist the definition somewhere global.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index d2ba215..db19b17 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -834,6 +834,8 @@ class P4Submit(Command):
return True
class P4Sync(Command):
+ delete_actions = ( "delete", "move/delete", "purge" )
+
def __init__(self):
Command.__init__(self)
self.options = [
@@ -1038,10 +1040,10 @@ class P4Sync(Command):
if includeFile:
filesForCommit.append(f)
- if f['action'] not in ('delete', 'move/delete', 'purge'):
- filesToRead.append(f)
- else:
+ if f['action'] in self.delete_actions:
filesToDelete.append(f)
+ else:
+ filesToRead.append(f)
# deleted files...
for f in filesToDelete:
@@ -1127,7 +1129,7 @@ class P4Sync(Command):
cleanedFiles = {}
for info in files:
- if info["action"] in ("delete", "purge"):
+ if info["action"] in self.delete_actions:
continue
cleanedFiles[info["depotFile"]] = info["rev"]
@@ -1453,7 +1455,7 @@ class P4Sync(Command):
if change > newestRevision:
newestRevision = change
- if info["action"] in ("delete", "purge"):
+ if info["action"] in self.delete_actions:
# don't increase the file cnt, otherwise details["depotFile123"] will have gaps!
#fileCnt = fileCnt + 1
continue
--
1.7.2.3
^ permalink raw reply related
* [PATCH 3/8] git-p4: add missing newline in initial import message
From: Pete Wyckoff @ 2011-02-05 22:51 UTC (permalink / raw)
To: git
In-Reply-To: <20110205224848.GA30963@arf.padd.com>
The commit message looks wrong without the newline.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 2fefea4..d2ba215 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1429,7 +1429,7 @@ class P4Sync(Command):
print "Doing initial import of %s from revision %s into %s" % (' '.join(self.depotPaths), revision, self.branch)
details = { "user" : "git perforce import user", "time" : int(time.time()) }
- details["desc"] = ("Initial import of %s from the state at revision %s"
+ details["desc"] = ("Initial import of %s from the state at revision %s\n"
% (' '.join(self.depotPaths), revision))
details["change"] = revision
newestRevision = 0
--
1.7.2.3
^ permalink raw reply related
* [PATCH 2/8] git-p4: fix key error for p4 problem
From: Pete Wyckoff @ 2011-02-05 22:51 UTC (permalink / raw)
To: git
In-Reply-To: <20110205224848.GA30963@arf.padd.com>
Some p4 failures result in an error, but the info['code'] is not
set. These include a bad p4 executable, or a core dump from p4,
and other odd internal errors where p4 fails to generate proper
marshaled output.
Make sure the info key exists before using it to avoid a python
traceback.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 5 ++++-
t/t9800-git-p4.sh | 13 +++++++++++++
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 04ce7e3..2fefea4 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1440,10 +1440,13 @@ class P4Sync(Command):
% (p, revision)
for p in self.depotPaths])):
- if info['code'] == 'error':
+ if 'code' in info and info['code'] == 'error':
sys.stderr.write("p4 returned an error: %s\n"
% info['data'])
sys.exit(1)
+ if 'p4ExitCode' in info:
+ sys.stderr.write("p4 exitcode: %s\n" % info['p4ExitCode'])
+ sys.exit(1)
change = int(info["change"])
diff --git a/t/t9800-git-p4.sh b/t/t9800-git-p4.sh
index f4956b7..41e57bb 100755
--- a/t/t9800-git-p4.sh
+++ b/t/t9800-git-p4.sh
@@ -52,6 +52,19 @@ test_expect_success 'basic git-p4 clone' '
rm -rf "$git" && mkdir "$git"
'
+test_expect_success 'exit when p4 fails to produce marshaled output' '
+ badp4dir="$TRASH_DIRECTORY/badp4dir" &&
+ mkdir -p "$badp4dir" &&
+ cat >"$badp4dir"/p4 <<-EOF &&
+ #!$SHELL_PATH
+ exit 1
+ EOF
+ chmod 755 "$badp4dir"/p4 &&
+ PATH="$badp4dir:$PATH" "$GITP4" clone --dest="$git" //depot >errs 2>&1 ; retval=$? &&
+ test $retval -eq 1 &&
+ test_must_fail grep -q Traceback errs
+'
+
test_expect_success 'shutdown' '
pid=`pgrep -f p4d` &&
test -n "$pid" &&
--
1.7.2.3
^ permalink raw reply related
* [PATCH 1/8] git-p4: test script
From: Pete Wyckoff @ 2011-02-05 22:51 UTC (permalink / raw)
To: git
In-Reply-To: <20110205224848.GA30963@arf.padd.com>
Add a basic test script for git-p4.
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9800-git-p4.sh | 62 +++++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 62 insertions(+), 0 deletions(-)
create mode 100755 t/t9800-git-p4.sh
diff --git a/t/t9800-git-p4.sh b/t/t9800-git-p4.sh
new file mode 100755
index 0000000..f4956b7
--- /dev/null
+++ b/t/t9800-git-p4.sh
@@ -0,0 +1,62 @@
+#!/bin/sh
+
+test_description='git-p4 tests'
+
+. ./test-lib.sh
+
+p4 -h >/dev/null 2>&1
+retc=$?
+p4d -h >/dev/null 2>&1
+retd=$?
+if test $retc -ne 0 -o $retd -ne 0
+then
+ skip_all='skipping git-p4 tests; no p4 or p4d'
+ test_done
+fi
+
+GITP4=$GIT_BUILD_DIR/contrib/fast-import/git-p4
+P4DPORT=10669
+
+db="$TRASH_DIRECTORY/db"
+cli="$TRASH_DIRECTORY/cli"
+git="$TRASH_DIRECTORY/git"
+
+test_debug 'echo p4d -q -d -r "$db" -p $P4DPORT'
+test_expect_success setup '
+ mkdir -p "$db" &&
+ p4d -q -d -r "$db" -p $P4DPORT &&
+ # wait for it to finish its initialization
+ sleep 1 &&
+ mkdir -p "$cli" &&
+ mkdir -p "$git" &&
+ export P4PORT=localhost:$P4DPORT
+'
+
+test_expect_success 'add p4 files' '
+ cd "$cli" &&
+ p4 client -i <<-EOF &&
+ Client: client
+ Description: client
+ Root: $cli
+ View: //depot/... //client/...
+ EOF
+ export P4CLIENT=client &&
+ echo file1 >file1 &&
+ p4 add file1 &&
+ p4 submit -d "file1" &&
+ cd "$TRASH_DIRECTORY"
+'
+
+test_expect_success 'basic git-p4 clone' '
+ "$GITP4" clone --dest="$git" //depot &&
+ rm -rf "$git" && mkdir "$git"
+'
+
+test_expect_success 'shutdown' '
+ pid=`pgrep -f p4d` &&
+ test -n "$pid" &&
+ test_debug "ps wl `echo $pid`" &&
+ kill $pid
+'
+
+test_done
--
1.7.2.3
^ permalink raw reply related
* [PATCH 0/8] git-p4 fixes and enhancements
From: Pete Wyckoff @ 2011-02-05 22:48 UTC (permalink / raw)
To: git
I've collected a fair number of fixes and enhancements
to git-p4, and finally cleaned them up to send upstream.
git-p4: test script
git-p4: fix key error for p4 problem
git-p4: add missing newline in initial import message
git-p4: accommodate new move/delete type in p4
git-p4: reinterpret confusing p4 message
git-p4: better message for "git-p4 sync" when not cloned
git-p4: decode p4 wildcard characters
git-p4: support clone --bare
The first one is interesting in that it adds a test for
git-p4. I'd appreciate a careful review of this in
particular.
The other seven fix problems and add small features, with
test cases where it makes sense.
-- Pete
^ permalink raw reply
* Re: [1.8.0] Tracking empty directories
From: Jared Hance @ 2011-02-05 22:37 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: thomas, Jakub Narebski, git
In-Reply-To: <AANLkTikX5Y=TrXayXj-MCaR5p0=Tokc_5ihGqHFL9CQx@mail.gmail.com>
> > - Implement the possibility to checkin empty directories next year, but allow
> > it only, if the user knows that this breaks backwards compatibility of the
> > repo. (Generate warning and require --commit-empty-directories option)
>
> I don't know about this part though.
>
I would say that if we are going to require an option, it should be
core.emptyDirectory , which would default to false. It would be much
more annoying than having to supply an option every time. I also
disagree with warning for this.
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Dmitry Potapov @ 2011-02-05 21:40 UTC (permalink / raw)
To: Johan Herland
Cc: Junio C Hamano, git, Sverre Rabbelier, Jeff King,
Nguyen Thai Ngoc Duy, Nicolas Pitre
In-Reply-To: <201102050218.44325.johan@herland.net>
On Sat, Feb 05, 2011 at 02:18:44AM +0100, Johan Herland wrote:
> On Friday 04 February 2011, Junio C Hamano wrote:
>
> > For some reason, many people seem to be enthused about splitting the tag
> > namespace, but I am not sure if that is a good thing in general.
> > Branches are moving pointers for people to flip around in their local
> > repositories, and it makes sense to say "My master is a bit ahead of the
> > public one", but what would we gain by making it _easier_ to add and
> > exchange many tags with the same name (e.g. refs/remotes/*/tags/v1.7.4
> > vs refs/tags/v1.7.4), other than the extra confusion?
>
> First, I should state that making tags into moving pointers is not something
> I support, nor is it part of this proposal. Tags should still very much
> refuse to be moved (except when forced).
>
> Having said that, there are real situations where users encounter collisions
> in the shared tag namespace. A rare (but plausible) scenario arise when two
> developers create (and publish) conflicting tags in their repos. A more
> common scenario that I have encountered at $dayjob, is where two parallel
> (semi-related) projects are developed in separate repos (with different
> versioning because of separate release schedules), and I need to interface
> with both repos from a single local repo. Each of the remote repos have
> their own "v1.0" tag, but my repo can only hold one such tag. Which of those
> tags end up "winning" in my local repo depends on my fetch order.
Well, I agree that this situation requires a better diagnostic, but I
don't think that having separate namespaces is the right solution in
general. For your case, where you work on semi-related projects, it is
could be the right thing to do, but if you work on the same project and
have more than one source to fetch, then having multiple namespaces can
lead only to confusion, because tag names must be unique globally to
make sense to everyone. Actually, even if you have two semi-related
projects in the same repository, but you have more than one URL per
project, you want to group tags based on their relation to the project
and not based on the URL.
Dmitry
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Nicolas Pitre @ 2011-02-05 19:55 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Johan Herland, git, Sverre Rabbelier,
Nguyen Thai Ngoc Duy
In-Reply-To: <20110205193708.GA2192@sigill.intra.peff.net>
On Sat, 5 Feb 2011, Jeff King wrote:
> On Sat, Feb 05, 2011 at 01:39:57PM -0500, Nicolas Pitre wrote:
>
> > So that's what has to be fixed. If you get duplicated tag names then
> > just warn the user and give priority to the local one, or error out with
> > a "ambiguous tag specification" if no local but multiple remote tags
> > with the same name are found (the user would have to be more precise in
> > the tag scope in that case).
>
> The latter seems like a regression for the common case of fetching from
> two upstreams. E.g., I usually pull from Junio, getting
> remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I
> pull from him, getting remotes/spearce/v1.7.0, which he previously
> fetched from Junio. Under the current code, I can still do "git show
> v1.7.0"; under the scheme described above I now have to say
> "origin/v1.7.0" to disambiguate.
Let's suppose that both tags are identical, as in your scenario above
they would be, then there is no need to call for any ambiguity in that
case.
> The real issue, I think, is that we are claiming ambiguity even though
> those tags almost certainly point to the same sha1. When handling
> ambiguous tags, should we perhaps check to see if all of the ambiguities
> point to the same sha1, and in that case, just pick one at random?
If they're identical then there is no randomness. If they refer to
different tag objects, even if those tag objects do refer to the same
commit object, then I'd say there is an ambiguity only if the tag object
content matters i.e. when displaying the tag content.
> In the case of resolving a ref to a sha1, then by definition they are
> all equivalent to pick. For things that care (e.g., "git checkout") we
> should probably still complain (although many of those commands have
> their own disambiguation code to prefer refs/heads/ or whatever anyway).
We are probably more or less saying the same thing.
Nicolas
^ permalink raw reply
* Re: [1.8.0] Provide proper remote ref namespaces
From: Jeff King @ 2011-02-05 19:37 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Johan Herland, git, Sverre Rabbelier,
Nguyen Thai Ngoc Duy
In-Reply-To: <alpine.LFD.2.00.1102051330270.12104@xanadu.home>
On Sat, Feb 05, 2011 at 01:39:57PM -0500, Nicolas Pitre wrote:
> So that's what has to be fixed. If you get duplicated tag names then
> just warn the user and give priority to the local one, or error out with
> a "ambiguous tag specification" if no local but multiple remote tags
> with the same name are found (the user would have to be more precise in
> the tag scope in that case).
The latter seems like a regression for the common case of fetching from
two upstreams. E.g., I usually pull from Junio, getting
remotes/origin/v1.7.0. One day Shawn is the interim maintainer, and I
pull from him, getting remotes/spearce/v1.7.0, which he previously
fetched from Junio. Under the current code, I can still do "git show
v1.7.0"; under the scheme described above I now have to say
"origin/v1.7.0" to disambiguate.
The real issue, I think, is that we are claiming ambiguity even though
those tags almost certainly point to the same sha1. When handling
ambiguous tags, should we perhaps check to see if all of the ambiguities
point to the same sha1, and in that case, just pick one at random?
In the case of resolving a ref to a sha1, then by definition they are
all equivalent to pick. For things that care (e.g., "git checkout") we
should probably still complain (although many of those commands have
their own disambiguation code to prefer refs/heads/ or whatever anyway).
-Peff
^ permalink raw reply
* Re: ignoring file modes completely
From: Rafael Kitover @ 2011-02-05 19:28 UTC (permalink / raw)
Cc: git
In-Reply-To: <4D4D81C9.5080002@op5.se>
On 2/5/2011 11:58 AM, Andreas Ericsson wrote:
> On 02/05/2011 05:09 PM, Rafael Kitover wrote:
>> On 2/5/2011 11:03 AM, Jared Hance wrote:
>>> On Sat, 2011-02-05 at 10:24 -0500, Rafael Kitover wrote:
>>>> Hello,
>>>>
>>>> I found the core.filemode option, which ignores executable bits, but I
>>>> need an option to ignore all mode differences, and such an option does
>>>> not seem to exist.
>>>
>>> The only mode tracked by Git is the executable bit, so this shouldn't
>>> even be an issue. Are you sure the executable bit isn't the problem?
>>>
>> $ git config --global core.filemode
>> false
>>
>> Output of "git diff HEAD" :
>>
>> diff --git a/Makefile.PL b/Makefile.PL
>> old mode 100755
>> new mode 100644
>> diff --git a/t/02ads.t b/t/02ads.t
>> old mode 100755
>> new mode 100644
>> diff --git a/t/02cxn.t b/t/02cxn.t
>> old mode 100755
>> new mode 100644
>> diff --git a/t/04os.t b/t/04os.t
>> old mode 100755
>> new mode 100644
>
> Those are all executable bit diffs.
>
Ok, but I have core.filemode set to "false" as I showed, why does this
happen then?
^ permalink raw reply
* Re: GIT - cloning torvalds/linux-2.6.git repository trouble.
From: Sverre Rabbelier @ 2011-02-05 19:10 UTC (permalink / raw)
To: Valentin QUEQUET; +Cc: git
In-Reply-To: <AANLkTikYPHhVaKYsQpZ2FhjxAdLetPgkPFQ-b-VtkBTJ@mail.gmail.com>
Heya,
On Sat, Feb 5, 2011 at 20:08, Valentin QUEQUET
<valentin.quequet@gmail.com> wrote:
> This was one of the 1st things I tried in order to get a
> fully-functional repository.
Ok, so what happened when you tried? What did 'git fsck' tell you? If
it doesn't error out, try running 'git repack' followed by 'git
checkout -t origin/master'?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: GIT - cloning torvalds/linux-2.6.git repository trouble.
From: Valentin QUEQUET @ 2011-02-05 19:08 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git
In-Reply-To: <AANLkTi=E3gWG2-3nLBW6JP+Wks2=4oUWSNSpk0=qEaU-@mail.gmail.com>
2011/2/5, Sverre Rabbelier <srabbelier@gmail.com>:
[...]
> What happens if you lay out your repo like the urls? I.e. without the
> "http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git"
> prefix?
I 1st want to thank you for this suggestion.
However,
This was one of the 1st things I tried in order to get a
fully-functional repository.
I think that I should be able to re-construct the whole repository from
this set of a few .pack files (450MiB) I just downloaded.
( .idx files are only there for optimization purpose )
How can I do that ?
! THAT'S THE QUESTION !
Yet,
I thank you for your answer.
Sincerely,
Valentin
^ permalink raw reply
* Re: [1.8.0] Tracking empty directories
From: Sverre Rabbelier @ 2011-02-05 19:00 UTC (permalink / raw)
To: thomas; +Cc: Jakub Narebski, git
In-Reply-To: <201102051931.10979.thomas@koch.ro>
Heya,
On Sat, Feb 5, 2011 at 19:31, Thomas Koch <thomas@koch.ro> wrote:
> - Implement the possibility to checkout/read/handle empty directories as soon
> as possible, even in the next 1.7.x release.
I think regardless of whatever else we do, this makes sense. I think
it's been suggested by Junio in a neighboring thread as well.
> - Implement the possibility to checkin empty directories next year, but allow
> it only, if the user knows that this breaks backwards compatibility of the
> repo. (Generate warning and require --commit-empty-directories option)
I don't know about this part though.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [1.8.0] Tracking empty directories
From: Thomas Koch @ 2011-02-05 18:31 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3zkqe8xc8.fsf_-_@localhost.localdomain>
Jakub Narebski:
> there is (supposedly) problem when checking out such tree (see email
> referenced above) with an old git.
Proposal:
- Implement the possibility to checkout/read/handle empty directories as soon
as possible, even in the next 1.7.x release.
- Don't implement the possibility to create/commit empty directories yet.
- Implement the possibility to checkin empty directories next year, but allow
it only, if the user knows that this breaks backwards compatibility of the
repo. (Generate warning and require --commit-empty-directories option)
Sorry if this should be crap. I'm not a GIT dev.
Best regards,
Thomas Koch, http://www.koch.ro
^ permalink raw reply
* Re: GIT - cloning torvalds/linux-2.6.git repository trouble.
From: Sverre Rabbelier @ 2011-02-05 18:52 UTC (permalink / raw)
To: Valentin QUEQUET; +Cc: git
In-Reply-To: <AANLkTi=FAWh9T3HaocdKB7V4osRPsehTo=hTP0U-JbfR@mail.gmail.com>
Heya,
On Sat, Feb 5, 2011 at 19:45, Valentin QUEQUET
<valentin.quequet@gmail.com> wrote:
> http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/heads/master
> http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/info/packs
>
> http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-0b38509807589c455b1c769368348bd845441959.idx
> http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-c53d2db50f885f3803a3afd46484b54c06b1433e.idx
<snip>
What happens if you lay out your repo like the urls? I.e. without the
"http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git"
prefix?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Fwd: GIT - cloning torvalds/linux-2.6.git repository trouble.
From: Valentin QUEQUET @ 2011-02-05 18:45 UTC (permalink / raw)
To: git
In-Reply-To: <AANLkTikiKagzJMh_xuOSzfA4c-qxOHhVeU2jhmbaDHji@mail.gmail.com>
---------- Forwarded message ----------
From: Valentin QUEQUET <valentin.quequet@gmail.com>
Date: Sat, 5 Feb 2011 18:17:57 +0000
Subject: GIT - cloning torvalds/linux-2.6.git repository trouble.
To: linux-kernel@vger.kernel.org
Hi Dear Linux enthusiasts,
I recently (yesterday) began to fetch (clone, fetch, ...) the current
Linux GIT repository:
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
I first failed to fetch it through any protocol ( git:// , http:// , https:// )
because of my UNRELIABLE WiFi connexion.
I eventually managed to download the following file :
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/refs/heads/master
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/info/packs
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-0b38509807589c455b1c769368348bd845441959.idx
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-c53d2db50f885f3803a3afd46484b54c06b1433e.idx
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-910f14bdd726702c46cfd622ee40fcaf4881a5ec.idx
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-81315ef1065b534c70a409978aa11daf2e27fdb5.idx
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-83898168fc5bce601472bd3260cd6b08f5f4f7b2.idx
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-7ff1ea46fec7532e88a900a9a1340794fb3ffa3f.idx
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-221cb4abe6bb3165bf062219200020148b83948b.idx
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-6576226aba312e2a3b610665e35cfc466f980c55.idx
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-0ab67efdf76cff54cd9fa5166d1df19c8edf685a.idx
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-0b7fc86700a243d2ea341c04926c4425fe85fd26.idx
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-fb3e46067bf5b97b6b49dbda9cda51cf3ef3b660.idx
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-04fb51824d013a5fbac892f95369d92daf60f195.idx
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-76001124ed6335482ee1cea785f93426ab278417.idx
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-0b38509807589c455b1c769368348bd845441959.pack
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-c53d2db50f885f3803a3afd46484b54c06b1433e.pack
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-910f14bdd726702c46cfd622ee40fcaf4881a5ec.pack
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-81315ef1065b534c70a409978aa11daf2e27fdb5.pack
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-83898168fc5bce601472bd3260cd6b08f5f4f7b2.pack
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-7ff1ea46fec7532e88a900a9a1340794fb3ffa3f.pack
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-221cb4abe6bb3165bf062219200020148b83948b.pack
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-6576226aba312e2a3b610665e35cfc466f980c55.pack
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-0ab67efdf76cff54cd9fa5166d1df19c8edf685a.pack
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-0b7fc86700a243d2ea341c04926c4425fe85fd26.pack
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-fb3e46067bf5b97b6b49dbda9cda51cf3ef3b660.pack
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-04fb51824d013a5fbac892f95369d92daf60f195.pack
http://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/objects/pack/pack-76001124ed6335482ee1cea785f93426ab278417.pack
And all these .pack and .idx files appear to be valid ones, with
respect to the "git verify-pack" command.
This set of files seems to be consistent with the current state (by that time)
of the Linux git repository (torvalds/linux-2.6.git)
Now, I would like YOU to tell ME how I can checkout from the PACKs
I've just downloaded.
How may I populate the working directory , objects/xy/... , refs/... ,
... hierarchies to
make my (local) repository usable.
I suspect I shall find this information in documentation related to
the "git fetch" command,
but I haven't managed to get it right.
Your HELP is very welcome.
If you prefer not to pollute LKML, you may choose to aswer me at:
valentin.quequet@gmail.com
Thanks in advance,
Valentin
^ 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