* [PATCH] git-pickaxe: look for files relative to current path
From: Jeff King @ 2006-11-02 7:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andy Whitcroft
In-Reply-To: <45496432.80503@shadowen.org>
Signed-off-by: Jeff King <peff@peff.net>
---
Andy Whitcroft writes:
> We seem to have a difference in the handling of relative filenames
> within a repository between git blame and git pickaxe. Specifically git
> pickaxe seems to always require names as if it were run in the top of
> the project:
This simple patch seems to fix it (but is not extensively tested).
builtin-pickaxe.c | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/builtin-pickaxe.c b/builtin-pickaxe.c
index c9405e9..3e76258 100644
--- a/builtin-pickaxe.c
+++ b/builtin-pickaxe.c
@@ -1413,6 +1413,13 @@ static void sanity_check_refcnt(struct s
}
}
+static const char *add_prefix(const char *prefix, const char *path)
+{
+ if (!prefix || !prefix[0])
+ return path;
+ return prefix_path(prefix, strlen(prefix), path);
+}
+
static int has_path_in_work_tree(const char *path)
{
struct stat st;
@@ -1548,7 +1555,7 @@ int cmd_pickaxe(int argc, const char **a
/* (1) */
if (argc <= i)
usage(pickaxe_usage);
- path = argv[i];
+ path = add_prefix(prefix, argv[i]);
if (i + 1 == argc - 1) {
if (unk != 1)
usage(pickaxe_usage);
@@ -1566,13 +1573,13 @@ int cmd_pickaxe(int argc, const char **a
if (seen_dashdash) {
if (seen_dashdash + 1 != argc - 1)
usage(pickaxe_usage);
- path = argv[seen_dashdash + 1];
+ path = add_prefix(prefix, argv[seen_dashdash + 1]);
for (j = i; j < seen_dashdash; j++)
argv[unk++] = argv[j];
}
else {
/* (3) */
- path = argv[i];
+ path = add_prefix(prefix, argv[i]);
if (i + 1 == argc - 1) {
final_commit_name = argv[i + 1];
@@ -1580,7 +1587,7 @@ int cmd_pickaxe(int argc, const char **a
* old-style
*/
if (unk == 1 && !has_path_in_work_tree(path)) {
- path = argv[i + 1];
+ path = add_prefix(prefix, argv[i + 1]);
final_commit_name = argv[i];
}
}
--
^ permalink raw reply related
* Re: weird strncmp usage?
From: Jeff King @ 2006-11-02 6:51 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: hanwen, git
In-Reply-To: <45494D84.2060402@shadowen.org>
On Thu, Nov 02, 2006 at 01:44:36AM +0000, Andy Whitcroft wrote:
> That said if you know its constant you can also use sizeof("foo") and
> that is done at compile time. Something like:
>
> #define strxcmp(x, y) strncmp((x), (y), sizeof((y))
You would, of course, need to use sizeof(y)-1 to avoid comparing the NUL
termination. :)
This is a slightly dangerous macro, because it _only_ works for string
literals, but not pointers (which is fine in this case, but its
limitations need to be documented).
^ permalink raw reply
* git bug? + question
From: Miles Bader @ 2006-11-02 5:56 UTC (permalink / raw)
To: git
Hi,
I tried the following sequence of commands to make two clones of a
remote repository, but got an error:
$ git clone --use-separate-remote ssh://fp.gnu.org/~/git/snogray.git snogray-git
$ git clone --use-separate-remote --reference snogray-git ssh://fp.gnu.org/~/git/snogray.git imp-sample
error: refs/reference-tmp/refs/remotes/origin/HEAD points nowhere!
Is this a real error, or bad usage?
Also, a question: Is there anyway to make git-clone use
--use-separate-remote by default? I'm trying for a "lots of branches in
a single shared remote repository" style, and use-separate-remote seems
more sane for this usage.
I'm using git version 1.4.3.3.
Thanks,
-Miles
--
"I distrust a research person who is always obviously busy on a task."
^ permalink raw reply
* Re: [PATCH 6/6] remove .keep pack lock files when done with refs update
From: Junio C Hamano @ 2006-11-02 5:27 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <11624187883225-git-send-email-nico@cam.org>
Nicolas Pitre <nico@cam.org> writes:
> --- a/git-fetch.sh
> +++ b/git-fetch.sh
> @@ -51,7 +51,7 @@ do
> verbose=Yes
> ;;
> -k|--k|--ke|--kee|--keep)
> - keep=--keep
> + keep=-k -k
> ;;
> --reflog-action=*)
> rloga=`expr "z$1" : 'z-[^=]*=\(.*\)'`
Micronit. This cannot be right without quoting.
^ permalink raw reply
* Re: [PATCH 6/6] remove .keep pack lock files when done with refs update
From: Shawn Pearce @ 2006-11-02 5:18 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <11624187883225-git-send-email-nico@cam.org>
Nicolas Pitre <nico@cam.org> wrote:
> This makes both git-fetch and git-push (fetch-pack and receive-pack)
> safe against a possible race with aparallel git-repack -a -d that could
> prune the new pack while it is not yet referenced, and remove the .keep
> file after refs have been updated.
Thanks for finishing this series out. I've gotten sidetracked the
past two days and wasn't able to finish it myself. Nicely done
too, your code looks much better than my drafts... :-)
--
^ permalink raw reply
* Re: git_get_projects_list and $projects_list
From: Aneesh Kumar @ 2006-11-02 4:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Git Mailing List
In-Reply-To: <ei7f7o$bgi$1@sea.gmane.org>
[-- Attachment #1: Type: text/plain, Size: 131 bytes --]
On 10/31/06, Jakub Narebski <jnareb@gmail.com> wrote:
> $dir =~ s!/+$!!;
>
That works. Attaching the diff below
-aneesh
[-- Attachment #2: gitweb.diff --]
[-- Type: text/x-patch, Size: 367 bytes --]
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index bf5f829..4343450 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -897,6 +897,8 @@ sub git_get_projects_list {
if (-d $projects_list) {
# search in directory
my $dir = $projects_list;
+ # remove the trailing "/"
+ $dir =~ s!/+$!!;
my $pfxlen = length("$dir");
File::Find::find({
^ permalink raw reply related
* Re: [PATCH 1/6] Allow pack header preprocessing before unpack-objects/index-pack.
From: Nicolas Pitre @ 2006-11-02 3:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v3b92zpzj.fsf@assigned-by-dhcp.cox.net>
On Wed, 1 Nov 2006, Junio C Hamano wrote:
> Rather nicely done. I see upto 2/6 are identical to what has
> sitting in "pu" for the past few days, modulo some indentation?
Yes. I just inserted them in the serie as I didn't see them in pu until
a very recent pull.
> I wonder how much testing has this series seen, by the way.
It has been tested a bit. At least until it started behaving
correctly for me. There might still be bugs remaining, but nothing that
should screw a repository up. I think it should be good enough for next.
> Also, I wonder what happens after 5/6 errors out. It dies and
> the caller (typically receive-pack) reports it back, which would
> fail the push (and does not update the refs). Retrying in such
> a case would probably use the same set of refs on both ends,
> resulting in exactly the same pack...
Well, the purpose of 5/6 is to avoid creating a .keep file if it already
exists. This is more a security thing so if you decide to mark one of
your pack with .keep (say an history pack that doesn't need to be
repacked) then you don't want a funny git server to send you the same
pack just for the purpose of overwriting the same .keep file (that could
be removed right away if it ends up being considered as a lock file).
This is made more obvious with 6/6 as the .keep file is not removed if
it was there before. So this is not actually an error if creating a
.keep file fails with EEXIST.
As for index-pack dying, it will be reported the same way as
unpack-objects dying -- no difference there. Of course if it dies on
the first push, it is likely to die on all subsequent pushes since the
condition for that to happen is most probably due to a serious problem
(out of disk space, corruption in the existing objects in the
repository, etc).
The pack is put in place with move_temp_to_file() so if a previous
attempt already stored a pack with the same name before successfully
updating corresponding refs then the old pack will silently be kept
since we know both packs contain the same objects when they have the
same name. When a pack is moved it is always complete so there
shouldn't be any (new) instance of repository corruption in normal
circumbstances even in the presence of index-pack dying.
^ permalink raw reply
* git pickaxe -- problems with relative filenames
From: Andy Whitcroft @ 2006-11-02 3:21 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
We seem to have a difference in the handling of relative filenames
within a repository between git blame and git pickaxe. Specifically git
pickaxe seems to always require names as if it were run in the top of
the project:
apw@pinky$ pwd
/home/apw/git/git/Documentation
apw@pinky$ git blame git.txt | head -2
7984eabe (Sebastian Kuzminsky 2005-05-19 10:24:54 -0600 1) git(7)
2cf565c5 (David Greaves 2005-05-10 22:32:30 +0100 2) ======
apw@pinky$ git pickaxe git.txt | head -2
fatal: cannot stat path git.txt: No such file or directory
apw@pinky$ git pickaxe Documentation/git.txt | head -2
7984eabe (Sebastian Kuzminsky 2005-05-19 10:24:54 -0600 1) git(7)
2cf565c5 (David Greaves 2005-05-10 22:32:30 +0100 2) ======
This seems inconsistent? Is this expected behaviour?
^ permalink raw reply
* Re: Suggestion: drop 'g' in git-describe suffix
From: Andy Whitcroft @ 2006-11-02 1:47 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <eibh94$t7n$1@sea.gmane.org>
Han-Wen Nienhuys wrote:
>
> hi,
>
> the convention to use a 'g' in the output of git-describe, eg.
>
> [lilydev@haring lilypond]$ git describe --abbrev=39
> lilypond_2_9_7-g47778d2297276484c861fc7536da13feb2d5fe8
>
>
> is confusing: the g is also a hex digit, and without reading the manual
> carefully, you'd think this is the commit g4777.
>
> Proposal: why not use
>
> tag#sha1
>
> or some other non-hex character.
g is not a hex digit, hex is 0-f ??
In current versions of git, this whole string is also a valid name for
the commit ie you can do the following:
git show lilypond_2_9_7-g47778d2297276484c861fc7536da13feb2d5fe8
-apw
^ permalink raw reply
* Re: weird strncmp usage?
From: Andy Whitcroft @ 2006-11-02 1:44 UTC (permalink / raw)
To: hanwen; +Cc: git
In-Reply-To: <eibhga$tpg$1@sea.gmane.org>
Han-Wen Nienhuys wrote:
>
> Hi,
>
> the git source seems full of calls similar to
>
> strncmp (x, "constant string", 15)
>
> is there a reason not to use something like
>
> int
> strxmp (char const *x, char const *y)
> {
> return strncmp (x, y, strlen (y));
> }
>
> everywhere?
If you are doing these a _lot_ then there is a significant additional
cost to using strlen on a constant string.
That said if you know its constant you can also use sizeof("foo") and
that is done at compile time. Something like:
#define strxcmp(x, y) strncmp((x), (y), sizeof((y))
-apw
^ permalink raw reply
* weird strncmp usage?
From: Han-Wen Nienhuys @ 2006-11-02 1:26 UTC (permalink / raw)
To: git
Hi,
the git source seems full of calls similar to
strncmp (x, "constant string", 15)
is there a reason not to use something like
int
strxmp (char const *x, char const *y)
{
return strncmp (x, y, strlen (y));
}
everywhere?
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* Suggestion: drop 'g' in git-describe suffix
From: Han-Wen Nienhuys @ 2006-11-02 1:23 UTC (permalink / raw)
To: git
hi,
the convention to use a 'g' in the output of git-describe, eg.
[lilydev@haring lilypond]$ git describe --abbrev=39
lilypond_2_9_7-g47778d2297276484c861fc7536da13feb2d5fe8
is confusing: the g is also a hex digit, and without reading the manual
carefully, you'd think this is the commit g4777.
Proposal: why not use
tag#sha1
or some other non-hex character.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
^ permalink raw reply
* [PATCH] sanitize --abbrev option for describe
From: Han-Wen Nienhuys @ 2006-11-02 1:15 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 289 bytes --]
Hi,
the --abbrev option doesn't allow a 40 digit SHA1 output.
The following patch fixes this, and uses a IMHO more logical way to
compute the abbrev parameter, so --abbrev=52 will still yield a 40 digit
SHA1.
--
Han-Wen Nienhuys - hanwen@xs4all.nl - http://www.xs4all.nl/~hanwen
[-- Attachment #2: ps --]
[-- Type: text/plain, Size: 1059 bytes --]
commit 62ab49fb3a050cb2a4c96fa0ab8064742544369b
Author: Han-Wen Nienhuys <hanwen@lilypond.org>
Date: Thu Nov 2 02:12:11 2006 +0100
use constant variable for storing "--abbrev=". Use 40 and
MINIMUM_ABBREV as bounds for --abbrev= argument.
diff --git a/describe.c b/describe.c
index ab192f8..973520c 100644
--- a/describe.c
+++ b/describe.c
@@ -141,6 +141,7 @@ static void describe(const char *arg, in
int main(int argc, char **argv)
{
+ char const *abbrev_option = "--abbrev=";
int i;
for (i = 1; i < argc; i++) {
@@ -152,10 +153,10 @@ int main(int argc, char **argv)
all = 1;
else if (!strcmp(arg, "--tags"))
tags = 1;
- else if (!strncmp(arg, "--abbrev=", 9)) {
- abbrev = strtoul(arg + 9, NULL, 10);
- if (abbrev < MINIMUM_ABBREV || 40 < abbrev)
- abbrev = DEFAULT_ABBREV;
+ else if (!strncmp(arg, abbrev_option, strlen (abbrev_option))) {
+ abbrev = strtoul(arg + strlen (abbrev_option), NULL, 10);
+ abbrev = MAX(MINIMUM_ABBREV, abbrev);
+ abbrev = MIN(40, abbrev);
}
else
usage(describe_usage);
^ permalink raw reply related
* Re: [PATCH 4/n] gitweb: Secure against commit-ish/tree-ish with the same name as path
From: Junio C Hamano @ 2006-11-02 1:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200611010140.56834.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
>> [PATCH/RFC 1/n] gitweb: Better git-unquoting and gitweb-quoting of p...
>>
>> Marked preliminary, perhaps need some discussion and rerolling
>> but I haven't looked at it.
>
> I'm not sure if without this patch (well, the unquote part) gitweb
> can work with filenames which git quotes using escape sequences,
I am reasonably sure it wouldn't, and it sounded like you wanted
to fix it better than the preliminary one, so I think we are in
agreement.
>> [PATCH 2/n] gitweb: Use '&iquot;' instead of '?' in esc_path
>>
>> Discussed; we agreed that showing byte values in different
>> colors is preferable. Waiting for re-roll.
>
> The problem with using text color or background color is that
> the filenames tends to be shown with different color and background
> color: "tree" view, parts of difftree, parts of diff header, etc.
> Perhaps text-decoration: overline;? Just kidding...
Use of overstrike may actually not be a bad thing. It _is_
unusual situation after all.
>> [PATCH 3/n] gitweb: Use 's' regexp modifier to secure against filena...
>>
>> I looked at it although haven't said anything yet. Probably a
>> safe and good change but I wonder how LF at the end of the line
>> matches /...(.+)$/s pattern; iow, if we do not use -z does it
>> still do the right thing? Otherwise I suspect you would perhaps
>> need to chomp?
>
> We always pass chomped lines. First chunk is unnecessary (we care only
> for type), without second "tree" view look strange for files with
> embedded newline in filename.
The codepath affected by the first chunk does not chomp, which
was what I was referring to. So in the meantime will apply only
the second hunk.
>> [PATCH 4/n] gitweb: Secure against commit-ish/tree-ish with the same...
>>
>> Good fix and even improves readability; will apply after
>> dropping -- from ls-tree args.
I just applied this. I'll be pushing out a "master" update
sometime today, and do not expect to be able to get to your "n
turned out to be ten" series, so it might be worthwhile to
reroll the remaining bits that you still care about on top of
what I push out tonight to make sure we are on the same page.
Preferably:
- you should avoid making a series out of more-or-less
unrelated things;
- if you are doing related things in one series, do not send
half-baked early parts out until you are finished and are
confident with it. If you do not know how many patches you
need to complete that logically single topic yet, that is a
sure sign that you are not done. Instead, finish writing and
testing it, and if your test finds an earlier mistake,
especially a trivial one, go back and fix it in the earlier
patch in the series. Everybody makes mistakes so fixing up
before submission is a norm, and other people do not have to
be forced to see your "oops" in the development history.
Thanks.
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-11-02 0:53 UTC (permalink / raw)
To: git
* The 'maint' branch has these fixes since the last announcement.
We have one semantic fix in "maint". To the revision traversal
machinery, --unpacked used to mean that any commit that is in a
pack is uninteresting and tainted its ancestors also
uninteresting. Updated semantics of --unpacked is just an
output filter -- it traverses ancestry chain as usual, but does
not show unpacked commits. This made what "git repack" does
actually make sense when the repository is partly packed in the
half-way (the earlier logic worked fine only if all ancestors of
a packed commit were all packed).
A few minor "diff --cc" output fixes are also in "maint". It
now honours --no-commit-id option and shows function names on
the @@@ ... @@@ line just like normal diffs do.
Christian Couder (2):
Documentation: add upload-archive service to git-daemon.
Documentation: add git in /etc/services.
Edgar Toernig (1):
Use memmove instead of memcpy for overlapping areas
Jakub Narebski (2):
diff-format.txt: Correct information about pathnames quoting in
patch format
gitweb: Check git base URLs before generating URL from it
Jan Harkes (1):
Continue traversal when rev-list --unpacked finds a packed commit.
Junio C Hamano (7):
combine-diff: a few more finishing touches.
combine-diff: fix hunk_comment_line logic.
combine-diff: honour --no-commit-id
Surround "#define DEBUG 0" with "#ifndef DEBUG..#endif"
quote.c: ensure the same quoting across platforms.
revision traversal: --unpacked does not limit commit list anymore.
link_temp_to_file: don't leave the path truncated on
adjust_shared_perm failure
Nicolas Pitre (1):
pack-objects doesn't create random pack names
Rene Scharfe (1):
git-cherry: document limit and add diagram
* The 'master' branch has these since the last announcement.
Linus's packed-refs work with associated refs handling
clean-ups are out on "master", but there is one disclaimer.
Commit walkers cannot fetch from a repository whose refs are
packed and then pruned yet, so people with public repositories
that are expected to be fetched via http should not run
git-pack-refs just yet. I think it is probably just the
matter of updating git-fetch.sh to run ls-remote against the
repository upfront, and use the SHA-1 of wanted branch tip
instead of the branch tip name when running the low-level
git-http-fetch.
git-branch and git-cherry are now built-in.
Andy Parkins (1):
Make filenames line up in git-status output
Christian Couder (14):
Add [-s|--hash] option to Linus' show-ref.
Use Linus' show ref in "git-branch.sh".
Document git-show-ref [-s|--hash] option.
Fix show-ref usage for --dereference.
Add pack-refs and show-ref test cases.
When creating branch c/d check that branch c does not already exists.
Uncomment test case: git branch c/d should barf if branch c exists.
Fix a remove_empty_dir_recursive problem.
Clean up "git-branch.sh" and add remove recursive dir test cases.
Use git-update-ref to delete a tag instead of rm()ing the ref file.
Check that a tag exists using show-ref instead of looking for the
ref file.
Do not create tag leading directories since git update-ref does it.
Documentation: add upload-archive service to git-daemon.
Documentation: add git in /etc/services.
Dennis Stosberg (3):
lock_ref_sha1_basic does not remove empty directories on BSD
Remove bashism from t3210-pack-refs.sh
Bash completion support for aliases
Edgar Toernig (2):
Use memmove instead of memcpy for overlapping areas
Use memmove instead of memcpy for overlapping areas
Jakub Narebski (8):
gitweb: Use --no-commit-id in git_commit and git_commitdiff
diff-format.txt: Correct information about pathnames quoting in
patch format
gitweb: Check git base URLs before generating URL from it
Documentation: Update information about <format> in git-for-each-ref
gitweb: Move git_get_last_activity subroutine earlier
gitweb: Add "next" link to commitdiff view
gitweb: Secure against commit-ish/tree-ish with the same name as path
gitweb: Use 's' regexp modifier to secure against filenames with LF
Jan Harkes (1):
Continue traversal when rev-list --unpacked finds a packed commit.
Jeff King (3):
wt-status: use simplified resolve_ref to find current branch
gitignore: git-pack-refs is a generated file.
gitignore: git-show-ref is a generated file.
Johannes Schindelin (2):
Fix git-update-index --again
show-branch: mark active branch with a '*' again
Jonas Fonseca (1):
Add man page for git-show-ref
Junio C Hamano (42):
Fix t1400-update-ref test minimally
fsck-objects: adjust to resolve_ref() clean-up.
symbolit-ref: fix resolve_ref conversion.
Add callback data to for_each_ref() family.
Tell between packed, unpacked and symbolic refs.
pack-refs: do not pack symbolic refs.
git-pack-refs --prune
pack-refs: fix git_path() usage.
lock_ref_sha1_basic: remove unused parameter "plen".
Clean-up lock-ref implementation
update-ref: -d flag and ref creation safety.
update a few Porcelain-ish for ref lock safety.
Teach receive-pack about ref-log
receive-pack: call setup_ident before git_config
ref locking: allow 'foo' when 'foo/bar' used to exist but not anymore.
refs: minor restructuring of cached refs data.
lock_ref_sha1(): do not sometimes error() and sometimes die().
lock_ref_sha1(): check D/F conflict with packed ref when creating.
delete_ref(): delete packed ref
git-branch: remove D/F check done by hand.
show-ref --hash=len, --abbrev=len, and --abbrev
git-fetch: adjust to packed-refs.
Fix refs.c;:repack_without_ref() clean-up path
git-fetch: do not look into $GIT_DIR/refs to see if a tag exists.
pack-refs: use lockfile as everybody else does.
pack-refs: call fflush before fsync.
ref-log: allow ref@{count} syntax.
core.logallrefupdates create new log file only for branch heads.
git-pack-refs --all
core.logallrefupdates thinko-fix
ref-log: fix D/F conflict coming from deleted refs.
sha1_name.c: avoid compilation warnings.
t3200: git-branch testsuite update
combine-diff: fix hunk_comment_line logic.
combine-diff: honour --no-commit-id
tests: merge-recursive is usable without Python
Documentation: fix git-format-patch mark-up and link it from git.txt
Surround "#define DEBUG 0" with "#ifndef DEBUG..#endif"
quote.c: ensure the same quoting across platforms.
revision traversal: --unpacked does not limit commit list anymore.
link_temp_to_file: don't leave the path truncated on
adjust_shared_perm failure
branch: work in subdirectories.
Lars Hjemli (2):
Make git-branch a builtin
Fix show-ref usagestring
Linus Torvalds (6):
Add "git show-ref" builtin command
Teach "git checkout" to use git-show-ref
Start handling references internally as a sorted in-memory list
Add support for negative refs
Make ref resolution saner
Enable the packed refs file format
Luben Tuikov (2):
git-revert with conflicts to behave as git-merge with conflicts
gitweb: esc_html() author in blame
Nicolas Pitre (1):
pack-objects doesn't create random pack names
Petr Baudis (3):
Fix broken sha1 locking
Fix buggy ref recording
gitweb: Fix up bogus $stylesheet declarations
Rene Scharfe (3):
Built-in cherry
Make git-cherry handle root trees
git-cherry: document limit and add diagram
Robin Rosenberg (2):
Mention that pull can work locally in the synopsis
Swap the porcelain and plumbing commands in the git man page
Sasha Khapyorsky (1):
git-svnimport: support for partial imports
Sergey Vlasov (2):
git-send-email: Document support for local sendmail instead of
SMTP server
git-send-email: Read the default SMTP server from the GIT config file
Shawn Pearce (1):
Move deny_non_fast_forwards handling completely into receive-pack.
* The 'next' branch, in addition, has these.
The largest one is "pickaxe"; I think it is ready for wider
testing if not for production use, and it is a new command so
it should be relatively safe to push it out anytime on "master".
Nico did a lot of work on index-pack and with help from Shawn
pushing many objects without exploding them into loose objects
at the other end is becoming reality. The latest part of
their series is not in "next" nor "pu" yet, though.
Linus pointed out that when merging a branch based on an older
codebase that used to have a path into your branch that does
not have that path tracked anymore triggers a bogus safety
valve; I've done both merge-resolve and merge-recursive to
handle this situation but the result needs to be sanity
checked. We are _loosening_ safety valve and need to be extra
cautious not to overloosen it.
Junio C Hamano (28):
upload-pack: stop the other side when they have more roots than we do.
git-pickaxe: blame rewritten.
git-pickaxe -M: blame line movements within a file.
git-pickaxe -C: blame cut-and-pasted lines.
git-pickaxe: pagenate output by default.
git-pickaxe: fix nth_line()
git-pickaxe: improve "best match" heuristics
git-pickaxe: introduce heuristics to avoid "trivial" chunks
git-pickaxe: do not keep commit buffer.
git-pickaxe: do not confuse two origins that are the same.
git-pickaxe: get rid of wasteful find_origin().
git-pickaxe: swap comparison loop used for -C
merge: loosen overcautious "working file will be lost" check.
merge-recursive: use abbreviated commit object name.
merge-recursive: make a few functions static.
merge-recursive: adjust to loosened "working file clobbered" check
t6022: ignoring untracked files by merge-recursive when they do not
matter
send-pack --keep: do not explode into loose objects on the receiving end.
git-pickaxe: WIP to refcount origin structure.
git-pickaxe: allow -Ln,m as well as -L n,m
git-pickaxe: refcount origin correctly in find_copy_in_parent()
git-pickaxe: tighten sanity checks.
Revert "send-pack --keep: do not explode into loose objects on the
receiving end."
git-pickaxe: split find_origin() into find_rename() and find_origin().
git-pickaxe: cache one already found path per commit.
Introduce a new revision set operator <rev>^!
Linus Torvalds (2):
Allow '-' in config variable names
git push: add verbose flag and allow overriding of default target
repository
Nicolas Pitre (8):
enable index-pack streaming capability
make index-pack able to complete thin packs.
add progress status to index-pack
mimic unpack-objects when --stdin is used with index-pack
enhance clone and fetch -k experience
index-pack: minor fixes to comment and function name
missing small substitution
make git-push a bit more verbose
Petr Baudis (1):
gitweb: Support for 'forks'
Shawn Pearce (4):
Allow short pack names to git-pack-objects --unpacked=.
Only repack active packs by skipping over kept packs.
Teach git-index-pack how to keep a pack file.
Remove unused variable in receive-pack.
* The 'pu' branch, in addition, has these.
Johannes's "shallow" was marked as "pu" material so I've based
the series on the tip of "next" (which means we cannot
directly merge that into "next" or "master" without rebasing
it to "master" first) and parked it in "pu". I have given
only a cursory look to it but it looks promising.
Nico's latest 6-series builds on top of what Shawn has here
(the first two from Nico are the same), but I haven't gotten
around to them yet.
Johannes Schindelin (6):
upload-pack: no longer call rev-list
support fetching into a shallow repository
allow cloning a repository "shallowly"
allow deepening of a shallow repository
add tests for shallow stuff
Build in shortlog
Junio C Hamano (4):
rev-list --left-right
git-diff/git-apply: make diff output a bit friendlier to GNU
patch (part 2)
para-walk: walk n trees, index and working tree in parallel
git-commit: show --summary after successful commit.
Shawn Pearce (2):
Allow pack header preprocessing before unpack-objects/index-pack.
Teach receive-pack how to keep pack files based on object count.
^ permalink raw reply
* Re: [PATCH 1/6] Allow pack header preprocessing before unpack-objects/index-pack.
From: Junio C Hamano @ 2006-11-01 23:50 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <11624187853116-git-send-email-nico@cam.org>
Rather nicely done. I see upto 2/6 are identical to what has
sitting in "pu" for the past few days, modulo some indentation?
I wonder how much testing has this series seen, by the way.
Also, I wonder what happens after 5/6 errors out. It dies and
the caller (typically receive-pack) reports it back, which would
fail the push (and does not update the refs). Retrying in such
a case would probably use the same set of refs on both ends,
resulting in exactly the same pack...
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Junio C Hamano @ 2006-11-01 23:39 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611012309.42675.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Wednesday 2006, November 01 22:08, Junio C Hamano wrote:
>
>> That's the "mechanical point of view only" description I was
>> afraid of having. While I think I now see why they can be
>
> I must have a "mechanical point of view" brain. I can't see
> any further than the gear wheels.
I care more about how something is useful than how faithfully
something is implemented to the specification, which in turn
means the specification needs to obviously indicate why it is
useful.
A gadget may pick up a nearby baseball bat and jump up and down
three times while holding it, but I do not want to have a
description about the gadget that just says it is designed to do
that. I want the the description to be obvious that everybody
who reads it understands why that gadget is useful in what
situations. That's why I feel the examples need to be extended.
But if I understand correctly, you are suggesting two different
modes of operation, namely, with path limiters HEAD is not
moved?
That is not something other git commands with pathspec does.
Path limiters tell command to "do your thing only for paths that
match these patterns, while you usually handle all paths; your
behaviour shall otherwise not be any different in other aspects
between the case you got no limiter and the case you got _all_
paths as limiters." So I do not think making path-only mode and
pathless mode behave differently is a good idea from the UI
point of view.
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Andy Parkins @ 2006-11-01 23:09 UTC (permalink / raw)
To: git
In-Reply-To: <7vodrq251z.fsf@assigned-by-dhcp.cox.net>
On Wednesday 2006, November 01 22:08, Junio C Hamano wrote:
> > x --- y --- z
>
> I assume when you do the following operation your .git/HEAD
> points at 'y' which is already committed, and 'z' does not exist
> yet (it does not come into the scenario you describe below).
Sorry, yes, it's there merely to get in the way.
> You forgot to mention at the same time it makes .git/HEAD point
> at 'x'. That's the part I am not so sure about.
Hmmm, no I had imagined that in path mode HEAD would not be updated because
that would change the whole commit instead of just the particular file.
> Ah (lightbulb goes on). So after the above reset, you would do
> a "git commit" with or without -a to create a fixed-up 'y' that
> does not have changes to 'frotz'?
That's the one. It was described in another response as cherry-picking
content instead of commits.
> Then it sort of makes sense. --soft with paths specifier does
> not make much sense (paths specifier is a no-op in that case
> because --soft does not touch index nor working tree), but I
Agreed. --soft + path can't have any effect because it only updates HEAD,
which has no meaning in reset-path mode.
> Ok, that workflow certainly makes sense.
When this thread gets looked back upon, is it going to be strange that you
say "yes, making crazy changes makes sense"? :-)
> That's the "mechanical point of view only" description I was
> afraid of having. While I think I now see why they can be
I must have a "mechanical point of view" brain. I can't see any further than
the gear wheels.
Andy
--
Dr Andrew Parkins, M Eng (Hons), AMIEE
^ permalink raw reply
* exclude in diff
From: Luben Tuikov @ 2006-11-01 22:39 UTC (permalink / raw)
To: git
Hi,
Anyone up for adding -x and -X (--exclude and --exclude-from) options
to git-diff and friends?
Thanks,
Luben
^ permalink raw reply
* [PATCH] pack-objects doesn't create random pack names
From: Nicolas Pitre @ 2006-11-01 22:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Documentation for pack-objects seems to be out of date in this regard.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
index a1e5505..9bd1e39 100644
--- a/Documentation/git-pack-objects.txt
+++ b/Documentation/git-pack-objects.txt
@@ -47,9 +47,8 @@ base-name::
<base-name> to determine the name of the created file.
When this option is used, the two files are written in
<base-name>-<SHA1>.{pack,idx} files. <SHA1> is a hash
- of object names (currently in random order so it does
- not have any useful meaning) to make the resulting
- filename reasonably unique, and written to the standard
+ of the sorted object names to make the resulting filename
+ based on the pack content, and written to the standard
output of the command.
^ permalink raw reply related
* Re: Restore a single file in the index back to HEAD
From: Robin Rosenberg @ 2006-11-01 22:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andy Parkins, git
In-Reply-To: <7vbqnq51v4.fsf@assigned-by-dhcp.cox.net>
onsdag 01 november 2006 21:49 skrev Junio C Hamano:
> Andy Parkins <andyparkins@gmail.com> writes:
> > On Wednesday 2006, November 01 18:28, Junio C Hamano wrote:
> >> So from that point of view, the above commandline perfectly
> >> makes sense. However, giving anything but HEAD with path makes
> >> us go "Huh?" It is unclear what this should mean:
> >>
> >> git-reset [--hard | --mixed] HEAD^ oops/file1
> >
> > I don't understand. Why wouldn't that mean reset oops/file1 to the state
> > it had in HEAD^?
>
> Path limiters everywhere in git means "do this only for paths
> that match this pattern, and empty path means the pattern match
> every path -- the command's behaviour is not different in any
> other aspect between the case you gave no limiter and the case
> you gave _all_ paths as limiters". So the other paths remain as
> they were (both index and working tree), and HEAD needs to be
> updated to HEAD^ in the above example.
>
> While that perfect makes sense from mechanical point of view, I
> am not sure what it _means_ to keep some paths from now
> abandoned future while having some other paths reset to the
> rewound commit, from the point of view of end-user operation.
>
> In other words, I do not have a good explanation on what "git
> reset [--hard|--mixed] <commit> <path>..." does that I can write
> in the documentation.
You could refer to git-checkout although checkout doesn't have something
corresponding to --mixed. The --hard option would correspond to the -f flag
in checkout.
It is like "cherrypicking" content (not changes) from a particular commit.
Where did the soft option go?
Since checkout already does the work.. Is there any need for extending
git-reset, other than that's where people look for this feature. The man page
could be extended instead.
^ permalink raw reply
* Re: Problem with git-push
From: Junio C Hamano @ 2006-11-01 22:11 UTC (permalink / raw)
To: Florent Thoumie; +Cc: Johannes Schindelin, git
In-Reply-To: <1162421693.93716.22.camel@localhost>
Florent Thoumie <flz@xbsd.org> writes:
> On Wed, 2006-11-01 at 13:43 -0800, Junio C Hamano wrote:
>> Junio C Hamano <junkio@cox.net> writes:
>>
>> Actually, Florent's said the directory permission was screwed up
>> to begin with, so after following the code a bit more I can see
>> why it said "is a directory".
>
> I screwed the perms. I have a cron job that does automatic imports and
> it's running as root. I've been lured by the fact that it uses my name
> and email address to do those imports, so I thought it was running under
> my unprivileged account.
Thanks for a honest clarification. I was starting to worry if
this is a BSD vs Linux filesystem gotcha that is harder to debug
without having an actual box.
^ permalink raw reply
* Re: Restore a single file in the index back to HEAD
From: Junio C Hamano @ 2006-11-01 22:08 UTC (permalink / raw)
To: Andy Parkins; +Cc: git
In-Reply-To: <200611012118.11558.andyparkins@gmail.com>
Andy Parkins <andyparkins@gmail.com> writes:
> On Wednesday 2006, November 01 20:49, Junio C Hamano wrote:
>
>> >> git-reset [--hard | --mixed] HEAD^ oops/file1
>> While that perfect makes sense from mechanical point of view, I
>> am not sure what it _means_ to keep some paths from now
>> abandoned future while having some other paths reset to the
>> rewound commit, from the point of view of end-user operation.
>
> Isn't that exactly what the user would be asking for when they are doing a
> per-file reset? This is a contrived example as git makes it easier to do it
> in far more sensible ways; but I've done this before now in subversion...
> What if I want to try out some radical change? It goes like this:
>
> x --- y --- z
I assume when you do the following operation your .git/HEAD
points at 'y' which is already committed, and 'z' does not exist
yet (it does not come into the scenario you describe below).
> Where x is some stable commit; y is a load of crazy changes;
> we discover that the crazy changes are all fine except for
> one, and so want to rollback one file, without yet commiting:
>
> git-reset --hard HEAD^ frotz
>
> Git would get frotz from HEAD^ and write it to the working directory and the
> index (or just index with --mixed).
You forgot to mention at the same time it makes .git/HEAD point
at 'x'. That's the part I am not so sure about.
Ah (lightbulb goes on). So after the above reset, you would do
a "git commit" with or without -a to create a fixed-up 'y' that
does not have changes to 'frotz'?
Then it sort of makes sense. --soft with paths specifier does
not make much sense (paths specifier is a no-op in that case
because --soft does not touch index nor working tree), but I
wonder what workflow --mixed would help. It resets the index
for frotz from 'x', while your crazy changes of 'y' is still in
the working tree. You can "git commit" without -a to create the
same fixed-up 'y' that does not have changes to 'frotz', and
then keep working on 'y' to make it into less crazy.
Ok, that workflow certainly makes sense.
>> In other words, I do not have a good explanation on what "git
>> reset [--hard|--mixed] <commit> <path>..." does that I can write
>> in the documentation.
>
> --mixed
> Resets the index but not the working tree (i.e., the changed files are
> preserved but not marked for commit) and reports what has not been
> updated. This is the default action. If <path> is given then only that
> path will be reset to the state that <path> had in <commit-ish>. The
> working tree will be untouched.
>
> --hard
> Matches the working tree and index to that of the tree being switched to.
> Any changes to tracked files in the working tree since <commit-ish> are
> lost. If <path> is given then only that path will be reset in both the
> working tree and the index to the state that <path> had in <commit-ish>.
That's the "mechanical point of view only" description I was
afraid of having. While I think I now see why they can be
useful, we would need to extend the examples section to
demonstrate how they help workflows to readers.
^ permalink raw reply
* [PATCH 4/6] improve fetch-pack's handling of kept packs
From: Nicolas Pitre @ 2006-11-01 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre
In-Reply-To: <1162418786895-git-send-email-nico@cam.org>
Since functions in fetch-clone.c were only used from fetch-pack.c,
its content has been merged with fetch-pack.c. This allows for better
coupling of features with much simpler implementations.
One new thing is that the (abscence of) --thin also enforce it on
index-pack now, such that index-pack will abort if a thin pack was
_not_ asked for.
The -k or --keep, when provided twice, now causes the fetched pack
to be left as a kept pack just like receive-pack currently does.
Eventually this will be used to close a race against concurrent
repacking.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
Documentation/git-fetch-pack.txt | 3 +-
Makefile | 2 +-
cache.h | 4 --
fetch-clone.c | 87 ------------------------------
fetch-pack.c | 110 +++++++++++++++++++++++++++++++++++---
5 files changed, 106 insertions(+), 100 deletions(-)
diff --git a/Documentation/git-fetch-pack.txt b/Documentation/git-fetch-pack.txt
index bff9aa6..3e6cd88 100644
--- a/Documentation/git-fetch-pack.txt
+++ b/Documentation/git-fetch-pack.txt
@@ -32,7 +32,8 @@ OPTIONS
-k::
Do not invoke 'git-unpack-objects' on received data, but
create a single packfile out of it instead, and store it
- in the object database.
+ in the object database. If provided twice then the pack is
+ locked against repacking.
--exec=<git-upload-pack>::
Use this to specify the path to 'git-upload-pack' on the
diff --git a/Makefile b/Makefile
index 28a5d91..80d4a4e 100644
--- a/Makefile
+++ b/Makefile
@@ -260,7 +260,7 @@ LIB_OBJS = \
quote.o read-cache.o refs.o run-command.o dir.o object-refs.o \
server-info.o setup.o sha1_file.o sha1_name.o strbuf.o \
tag.o tree.o usage.o config.o environment.o ctype.o copy.o \
- fetch-clone.o revision.o pager.o tree-walk.o xdiff-interface.o \
+ revision.o pager.o tree-walk.o xdiff-interface.o \
write_or_die.o trace.o list-objects.o grep.o \
alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
color.o wt-status.o archive-zip.o archive-tar.o
diff --git a/cache.h b/cache.h
index 6cb7e1d..f2ec5c8 100644
--- a/cache.h
+++ b/cache.h
@@ -416,10 +416,6 @@ extern int copy_fd(int ifd, int ofd);
extern void write_or_die(int fd, const void *buf, size_t count);
extern int write_or_whine(int fd, const void *buf, size_t count, const char *msg);
-/* Finish off pack transfer receiving end */
-extern int receive_unpack_pack(int fd[2], const char *me, int quiet, int);
-extern int receive_keep_pack(int fd[2], const char *me, int quiet, int);
-
/* pager.c */
extern void setup_pager(void);
extern int pager_in_use;
diff --git a/fetch-clone.c b/fetch-clone.c
deleted file mode 100644
index f629d8d..0000000
--- a/fetch-clone.c
+++ /dev/null
@@ -1,87 +0,0 @@
-#include "cache.h"
-#include "exec_cmd.h"
-#include "pkt-line.h"
-#include "sideband.h"
-#include <sys/wait.h>
-
-static pid_t setup_sideband(int sideband, const char *me, int fd[2], int xd[2])
-{
- pid_t side_pid;
-
- if (!sideband) {
- fd[0] = xd[0];
- fd[1] = xd[1];
- return 0;
- }
- /* xd[] is talking with upload-pack; subprocess reads from
- * xd[0], spits out band#2 to stderr, and feeds us band#1
- * through our fd[0].
- */
- if (pipe(fd) < 0)
- die("%s: unable to set up pipe", me);
- side_pid = fork();
- if (side_pid < 0)
- die("%s: unable to fork off sideband demultiplexer", me);
- if (!side_pid) {
- /* subprocess */
- close(fd[0]);
- if (xd[0] != xd[1])
- close(xd[1]);
- if (recv_sideband(me, xd[0], fd[1], 2))
- exit(1);
- exit(0);
- }
- close(xd[0]);
- close(fd[1]);
- fd[1] = xd[1];
- return side_pid;
-}
-
-static int get_pack(int xd[2], const char *me, int sideband, const char **argv)
-{
- int status;
- pid_t pid, side_pid;
- int fd[2];
-
- side_pid = setup_sideband(sideband, me, fd, xd);
- pid = fork();
- if (pid < 0)
- die("%s: unable to fork off %s", me, argv[0]);
- if (!pid) {
- dup2(fd[0], 0);
- close(fd[0]);
- close(fd[1]);
- execv_git_cmd(argv);
- die("%s exec failed", argv[0]);
- }
- close(fd[0]);
- close(fd[1]);
- while (waitpid(pid, &status, 0) < 0) {
- if (errno != EINTR)
- die("waiting for %s: %s", argv[0], strerror(errno));
- }
- if (WIFEXITED(status)) {
- int code = WEXITSTATUS(status);
- if (code)
- die("%s died with error code %d", argv[0], code);
- return 0;
- }
- if (WIFSIGNALED(status)) {
- int sig = WTERMSIG(status);
- die("%s died of signal %d", argv[0], sig);
- }
- die("%s died of unnatural causes %d", argv[0], status);
-}
-
-int receive_unpack_pack(int xd[2], const char *me, int quiet, int sideband)
-{
- const char *argv[3] = { "unpack-objects", quiet ? "-q" : NULL, NULL };
- return get_pack(xd, me, sideband, argv);
-}
-
-int receive_keep_pack(int xd[2], const char *me, int quiet, int sideband)
-{
- const char *argv[5] = { "index-pack", "--stdin", "--fix-thin",
- quiet ? NULL : "-v", NULL };
- return get_pack(xd, me, sideband, argv);
-}
diff --git a/fetch-pack.c b/fetch-pack.c
index 36ea092..0a169dc 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -3,6 +3,9 @@
#include "pkt-line.h"
#include "commit.h"
#include "tag.h"
+#include "exec_cmd.h"
+#include "sideband.h"
+#include <sys/wait.h>
static int keep_pack;
static int quiet;
@@ -416,6 +419,103 @@ static int everything_local(struct ref *
return retval;
}
+static pid_t setup_sideband(int fd[2], int xd[2])
+{
+ pid_t side_pid;
+
+ if (!use_sideband) {
+ fd[0] = xd[0];
+ fd[1] = xd[1];
+ return 0;
+ }
+ /* xd[] is talking with upload-pack; subprocess reads from
+ * xd[0], spits out band#2 to stderr, and feeds us band#1
+ * through our fd[0].
+ */
+ if (pipe(fd) < 0)
+ die("fetch-pack: unable to set up pipe");
+ side_pid = fork();
+ if (side_pid < 0)
+ die("fetch-pack: unable to fork off sideband demultiplexer");
+ if (!side_pid) {
+ /* subprocess */
+ close(fd[0]);
+ if (xd[0] != xd[1])
+ close(xd[1]);
+ if (recv_sideband("fetch-pack", xd[0], fd[1], 2))
+ exit(1);
+ exit(0);
+ }
+ close(xd[0]);
+ close(fd[1]);
+ fd[1] = xd[1];
+ return side_pid;
+}
+
+static int get_pack(int xd[2], const char **argv)
+{
+ int status;
+ pid_t pid, side_pid;
+ int fd[2];
+
+ side_pid = setup_sideband(fd, xd);
+ pid = fork();
+ if (pid < 0)
+ die("fetch-pack: unable to fork off %s", argv[0]);
+ if (!pid) {
+ dup2(fd[0], 0);
+ close(fd[0]);
+ close(fd[1]);
+ execv_git_cmd(argv);
+ die("%s exec failed", argv[0]);
+ }
+ close(fd[0]);
+ close(fd[1]);
+ while (waitpid(pid, &status, 0) < 0) {
+ if (errno != EINTR)
+ die("waiting for %s: %s", argv[0], strerror(errno));
+ }
+ if (WIFEXITED(status)) {
+ int code = WEXITSTATUS(status);
+ if (code)
+ die("%s died with error code %d", argv[0], code);
+ return 0;
+ }
+ if (WIFSIGNALED(status)) {
+ int sig = WTERMSIG(status);
+ die("%s died of signal %d", argv[0], sig);
+ }
+ die("%s died of unnatural causes %d", argv[0], status);
+}
+
+static int explode_rx_pack(int xd[2])
+{
+ const char *argv[3] = { "unpack-objects", quiet ? "-q" : NULL, NULL };
+ return get_pack(xd, argv);
+}
+
+static int keep_rx_pack(int xd[2])
+{
+ const char *argv[6];
+ char keep_arg[256];
+ int n = 0;
+
+ argv[n++] = "index-pack";
+ argv[n++] = "--stdin";
+ if (!quiet)
+ argv[n++] = "-v";
+ if (use_thin_pack)
+ argv[n++] = "--fix-thin";
+ if (keep_pack > 1) {
+ int s = sprintf(keep_arg, "--keep=fetch-pack %i on ", getpid());
+ if (gethostname(keep_arg + s, sizeof(keep_arg) - s))
+ strcpy(keep_arg + s, "localhost");
+ argv[n++] = keep_arg;
+ }
+ argv[n] = NULL;
+ return get_pack(xd, argv);
+}
+
static int fetch_pack(int fd[2], int nr_match, char **match)
{
struct ref *ref;
@@ -447,17 +547,13 @@ static int fetch_pack(int fd[2], int nr_
goto all_done;
}
if (find_common(fd, sha1, ref) < 0)
- if (!keep_pack)
+ if (keep_pack != 1)
/* When cloning, it is not unusual to have
* no common commit.
*/
fprintf(stderr, "warning: no common commits\n");
- if (keep_pack)
- status = receive_keep_pack(fd, "git-fetch-pack", quiet, use_sideband);
- else
- status = receive_unpack_pack(fd, "git-fetch-pack", quiet, use_sideband);
-
+ status = (keep_pack) ? keep_rx_pack(fd) : explode_rx_pack(fd);
if (status)
die("git-fetch-pack: fetch failed.");
@@ -494,7 +590,7 @@ int main(int argc, char **argv)
continue;
}
if (!strcmp("--keep", arg) || !strcmp("-k", arg)) {
- keep_pack = 1;
+ keep_pack++;
continue;
}
if (!strcmp("--thin", arg)) {
--
1.4.3.3.g87b2-dirty
^ permalink raw reply related
* [PATCH 5/6] have index-pack create .keep file more carefully
From: Nicolas Pitre @ 2006-11-01 22:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nicolas Pitre
In-Reply-To: <1162418786390-git-send-email-nico@cam.org>
If by chance we receive a pack which content (list of objects) matches
another pack that we already have, and if that pack is marked with a
.keep file, then we should not overwrite it.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
index-pack.c | 17 ++++++++++-------
1 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index a3b55f9..8d64a88 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -788,14 +788,17 @@ static void final(const char *final_pack
get_object_directory(), sha1_to_hex(sha1));
keep_name = name;
}
- keep_fd = open(keep_name, O_RDWR | O_CREAT, 0600);
- if (keep_fd < 0)
- die("cannot write keep file");
- if (keep_msg_len > 0) {
- write_or_die(keep_fd, keep_msg, keep_msg_len);
- write_or_die(keep_fd, "\n", 1);
+ keep_fd = open(keep_name, O_RDWR|O_CREAT|O_EXCL, 0600);
+ if (keep_fd < 0) {
+ if (errno != EEXIST)
+ die("cannot write keep file");
+ } else {
+ if (keep_msg_len > 0) {
+ write_or_die(keep_fd, keep_msg, keep_msg_len);
+ write_or_die(keep_fd, "\n", 1);
+ }
+ close(keep_fd);
}
- close(keep_fd);
}
if (final_pack_name != curr_pack_name) {
--
1.4.3.3.g87b2-dirty
^ permalink raw reply related
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