* Re: multiple-commit cherry-pick?
From: Michael Radziej @ 2008-11-07 10:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Alex Riesen, Miles Bader, git
In-Reply-To: <7vskq4gmf5.fsf@gitster.siamese.dyndns.org>
On Thu, Nov 06, Junio C Hamano wrote:
> Or "git show --pretty=email $commit1 $commit2" ... piped to "am"?
Or make git show write shell commands.
I often have commits that later need to be cherry-picked into other
branches. For these, I use a commit message that starts with the name of the
branch, like "implement-foo: make foo barfy". Later when I want to do the
cherry-picking, I use this:
git log t/whatever..master --reverse --pretty=tformat:'git cherry-pick %h #
%s' | sed 's/^\([^:]*\) \([^:]*\):/git checkout \2 \&\& \1/'
giving me output like:
git checkout implement-foo && git cherry-pick 90ce727 # make foo barfy
git checkout ...
... and I'm ready for cut'n'paste.
Michael
--
noris network AG - Deutschherrnstraße 15-19 - D-90429 Nürnberg -
Tel +49-911-9352-0 - Fax +49-911-9352-100
http://www.noris.de - The IT-Outsourcing Company
Vorstand: Ingo Kraupa (Vorsitzender), Joachim Astel, Hansjochen Klenk -
Vorsitzender des Aufsichtsrats: Stefan Schnabel - AG Nürnberg HRB 17689
^ permalink raw reply
* Re: [PATCH] Documentation: Mention that 'bisect' is reserved branch name
From: Abhijit Bhopatkar @ 2008-11-07 10:23 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git, Junio C Hamano
In-Reply-To: <87wsff269h.fsf@iki.fi>
>> "git bisect" uses 'bisect' branch to carry out it's operations.
>> However "git branch" documentation does mention it.
>> Add a note that 'bisect' can not be used as generic branch
>> name by the user.
> Hmm...
> commit 634f246444e6a1675e351f31362e6a375dc44f70
> Author: Christian Couder <chriscool@tuxfamily.org>
> Date: 2008-05-23 01:28:57 +0200
>
> bisect: use a detached HEAD to bisect
Cool, didn't know that ...
Submitted patch must be ignored
Thanks
Abhijit
^ permalink raw reply
* Re: [PATCH] Documentation: Mention that 'bisect' is reserved branch name
From: Teemu Likonen @ 2008-11-07 10:13 UTC (permalink / raw)
To: Abhijit Bhopatkar; +Cc: git, Junio C Hamano
In-Reply-To: <2fcfa6df0811070201g75bfe659x38a4f14b1cf793c6@mail.gmail.com>
Abhijit Bhopatkar (2008-11-07 15:31 +0530) wrote:
> "git bisect" uses 'bisect' branch to carry out it's operations.
> However "git branch" documentation does mention it.
> Add a note that 'bisect' can not be used as generic branch
> name by the user.
Hmm...
commit 634f246444e6a1675e351f31362e6a375dc44f70
Author: Christian Couder <chriscool@tuxfamily.org>
Date: 2008-05-23 01:28:57 +0200
bisect: use a detached HEAD to bisect
^ permalink raw reply
* [PATCH] Documentation: Mention that 'bisect' is reserved branch name
From: Abhijit Bhopatkar @ 2008-11-07 10:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
"git bisect" uses 'bisect' branch to carry out it's operations.
However "git branch" documentation does mention it.
Add a note that 'bisect' can not be used as generic branch
name by the user.
Signed-off-by: Abhijit Bhopatkar <bain@devslashzero.com>
---
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 6103d62..2ea99fd 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -203,6 +203,9 @@ but different purposes:
- `--no-merged` is used to find branches which are candidates for merging
into HEAD, since those branches are not fully contained by HEAD.
+The branch name 'bisect' is reserved for use by "git-bisect" and can not be
+used as a generic branch name.
+
Author
------
Written by Linus Torvalds <torvalds@osdl.org> and Junio C Hamano
<gitster@pobox.com>
^ permalink raw reply related
* [minor usability suggestion] git rebase <upstream> --onto <newbase> ?
From: Ingo Molnar @ 2008-11-07 9:20 UTC (permalink / raw)
To: git
I use git rebase rarely, but i just had one of those exceptions where
it's OK to use it: wanted to zap an unsafe commit [685aebb below] from
a short-lifetime topic branch. With that i had this small usability
incident:
earth4:~/tip> tc
tip/core/urgent 82d4e6e: xen: make sure stray alias mappings are gone
earth4:~/tip> git rebase 685aebb --onto linus
Current branch core/urgent is up to date.
earth4:~/tip> glll
82d4e6e: xen: make sure stray alias mappings are gone before pinning
f6ab176: vmap: cope with vm_unmap_aliases before vmalloc_init()
685aebb: kernel/cpu.c: section mismatch warning fix
earth4:~/tip> git rebase --onto linus 685aebb
First, rewinding head to replay your work on top of it...
Applying: vmap: cope with vm_unmap_aliases before vmalloc_init()
Applying: xen: make sure stray alias mappings are gone before pinning
earth4:~/tip> glll
d05fdf3: xen: make sure stray alias mappings are gone before pinning
9b46333: vmap: cope with vm_unmap_aliases before vmalloc_init()
earth4:~/tip> tc
tip/core/urgent d05fdf3: xen: make sure stray alias mappings are gone
earth4:~/tip> git version
git version 1.6.0.2.GIT
What i tried to achieve was to zap a single commit that was applied
first, and preserve the other two commits - without having to go via
the longer "git rebase -i" path.
It took me some time to figure out that while the principle i applied
was correct, the first rebase command didnt work because i mistakenly
flipped around the "--onto <newbase> <upstream>" arguments to
"<upstream> --onto <newbase>".
Unless the reverse order is meaningful and important, it might make
sense to flip it back implicitly and thus accept that order as well
transparently.
For example "git log" is exemplary in this area as it accepts just
about any permutation of parameters thrown at it, and i love that
aspect of Git commands in general, it's a really nice property.
Or at least we should print some sort of warning/error? The "Current
branch core/urgent is up to date." message definitely did not help me
in noticing my mistake.
Ingo
^ permalink raw reply
* git-push and $GIT_DIR/branches
From: Martin Koegler @ 2008-11-07 8:26 UTC (permalink / raw)
To: git
I think, that the git-push behaviour is a bit unlogical in conjunction
with $GIT_DIR/branches.
If $GIT_DIR/branches/name1 contains "<repository>#name2":
- git-fetch name1
will fetch refs/heads/name2 from <repository> and store it in refs/heads/name1
- git-push name1
will push refs/heads/master to refs/heads/master in <repository>
I would expect, that git-push would somehow honour #name2. As far as I remember,
cg-push name1 would have pushed HEAD to refs/heads/name2 in <repository>.
In remote.c, function read_branches_file the following code
would implement a similar behaviour:
strbuf_init(&push, 0);
strbuf_addstr(&push, "HEAD");
if (frag) {
strbuf_addf(&push, ":refs/heads/%s", frag);
} else
strbuf_addstr(&push, ":refs/heads/master");
add_push_refspec(remote, strbuf_detach(&push, 0));
Options about this?
mfg Martin Kögler
^ permalink raw reply
* Re: Issue updating files during a checkout from a remote push
From: Andreas Ericsson @ 2008-11-07 8:21 UTC (permalink / raw)
To: Steve Walker; +Cc: git
In-Reply-To: <334B3AB1-125A-4163-BEBC-9A73C4F569B5@idibu.com>
Steve Walker wrote:
> Hi there,
>
> Hoping someone could point me in the right direction here.
>
> The overall issue is that with files that have been pushed into our repo
> on our server, when we then check out into local working copy the new
> files appear, but the updated files dont update even though the output
> suggests it has. The flow I'm doing:
>
> 1. The file I'm testing an update to is this:
>
> -rw-r--r-- 1 root www-data 0 2008-11-06 16:13
> steve-git-test3.txt
>
> 2. On my local box I change file, add it, commit, then push it from my
> local box to our server repo:
>
> StevePoota:public_html steve$ vi steve-git-test3.txt
> StevePoota:public_html steve$ git add steve-git-test3.txt
> StevePoota:public_html steve$ git commit
> Created commit e29b724: testing only
> 1 files changed, 1 insertions(+), 0 deletions(-)
> StevePoota:public_html steve$ git push
> ssh://idibu.com/home/beta_idibu/public_html master:master
> Counting objects: 5, done.
> Compressing objects: 100% (2/2), done.
> Writing objects: 100% (3/3), 272 bytes, done.
> Total 3 (delta 1), reused 0 (delta 0)
> To ssh://idibu.com/home/beta_idibu/public_html
> a28332a..e29b724 master -> master
>
> 3. It all looks good, on my server if i do a 'git log' I can see in the
> latest update:
>
> oneworld:/home/beta_idibu/public_html# git log
> commit e29b7246beab458d6a7b53cb245a5596adc8c198
> Author: Steve <steve@StevePoota.local>
> Date: Thu Nov 6 17:55:21 2008 +0100
>
> testing only
>
> 4. So I check out:
>
> oneworld:/home/beta_idibu/public_html# git checkout master
> M .gitignore
> M steve-git-test.txt
> M steve-git-test2.txt
> M steve-git-test3.txt
> Already on branch "master"
> oneworld:/home/beta_idibu/public_html#
>
> and its telling me that file has been modified
>
> but checking my file it hasnt changed by date stamp, and looking insie
> the file my changes arent there :((
>
> -rw-r--r-- 1 root www-data 0 2008-11-06 16:13
> steve-git-test3.txt
>
> I'm stumped. I tried 777'ing that file temporarily in case git couldnt
> write to that file on checkout. What is strange is that when I add new
> files to the system it works - for example this file I'm testing no was
> originally added to the server via an external push.
>
> If anyone could give me some help I'd be very grateful.
>
git reset --hard master
Note that it's definitely not a good idea to push into a non-bare repo
where you modify the worktree, as the workflow requires that you simply
clobber them (or work on a separate branch and then merge with master,
but then you'll have to know *why* things happen and how to fix them).
You'd probably be better off pushing to another repository and fetching
from that other repo into the non-bare one you're using now.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 2/4] repack: don't repack local objects in packs with .keep file
From: Andreas Ericsson @ 2008-11-07 8:14 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Git Mailing List, Shawn O. Pearce, Nicolas Pitre
In-Reply-To: <P5afFyDEMjF9ynd9dfSfGeRo_GFY_K6ZAn2nIYo8_xGgSl4LapbSOA@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> If the user created a .keep file for a local pack, then it can be inferred
> that the user does not want those objects repacked.
>
I disagree. It can be inferred that the user doesn't want those packfiles
*removed*.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 1/4] pack-objects: new option --honor-pack-keep
From: Andreas Ericsson @ 2008-11-07 8:13 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Git Mailing List, Shawn O. Pearce, Nicolas Pitre
In-Reply-To: <oDevG_2ETMLvy6rfSqvxfmFqABeVqlDUcU6FjP07E5IzqLaopWkQbQ@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> This adds a new option to pack-objects which will cause it to ignore an
> object which appears in a local pack which has a .keep file, even if it
> was specified for packing.
>
> This option will be used by the porcelain repack.
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
> ---
>
>
> This series replaces the previous series starting at
> 6ee726bc "pack-objects: honor '.keep' files"
>
> It should be applied on top of
> f34cf12d "packed_git: convert pack_local flag into a bitfield and add pack_keep"
>
> I created the series on top of f34cf12d rebased on top of master.
>
> Suggestions for a more appropriate name for --honor-pack-keep are very welcome.
>
> -brandon
>
>
> Documentation/git-pack-objects.txt | 5 +++++
> builtin-pack-objects.c | 7 +++++++
> 2 files changed, 12 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-pack-objects.txt b/Documentation/git-pack-objects.txt
> index 8c354bd..f9fac2c 100644
> --- a/Documentation/git-pack-objects.txt
> +++ b/Documentation/git-pack-objects.txt
> @@ -109,6 +109,11 @@ base-name::
> The default is unlimited, unless the config variable
> `pack.packSizeLimit` is set.
>
> +--honor-pack-keep::
> + This flag causes an object already in a local pack that
> + has a .keep file to be ignored, even if it appears in the
> + standard input.
> +
Keep-files are *always* honored. Make this option "--ignore-kept" or
something instead, otherwise people will see the synopsis and think
they need to always pass it to not remove .keep-protected packs,
which is stupid.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH v2 3/3] pack-objects: honor '.keep' files
From: Andreas Ericsson @ 2008-11-07 8:12 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Git Mailing List, Shawn O. Pearce, Nicolas Pitre
In-Reply-To: <BgEXN35P6wpio928OZi_34hs22vqUQxIAIGxR5hR8LqmfPIyw565Mg@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> Junio C Hamano wrote:
>> Brandon Casey <casey@nrlssc.navy.mil> writes:
>>
>>> <-a>
>>> -create a new pack containing all objects required by the repository
>>> including those accessible through alternates, but excluding objects
>>> in _local_ packs with .keep
>> I have a feeling that it is debatable if this "fattening to dissociate
>> from alternates" is what people want.
>
> I'm not sure I understand you here.
>
> Andreas has suggested previously that 'repack -a' should pack everything,
> including objects in packs with .keep. Is that what you mean?
>
> With my current understanding it seems that that would muddy the semantics
> of repack. If -a does not honor packs with .keep, then would it be intuitive
> to expect that adding -l (i.e. exclude alternate packed objects) _would_
> honor .keep?
>
Only -d should honor .keep, imo. .keep-files is nothing about "don't copy
objects from this file" and all about "never delete this file".
The only muddying comes from you, who decided that .keep-files should
have impact on anything else than deleting the protected pack. Before that,
.keep files had a clear semantic, and repack's documentation was correct.
How do you explain .keep-files now? "protects pack-files that will forever
be used"? Then why the hell is it called ".keep" instead of "eternal"?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Setting Up a GIT Repository Mirror
From: Yaser Raja @ 2008-11-07 7:17 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <adf1fd3d0811060733t28008f0cld1a3b3c5bf4ff4d8@mail.gmail.com>
On Thu, Nov 6, 2008 at 8:33 PM, Santi Béjar <santi@agolina.net> wrote:
> On Thu, Nov 6, 2008 at 4:08 PM, Yaser Raja <yrraja@gmail.com> wrote:
>> Hi
> [...]
>
>> I came to know about --mirror option of git-clone and used it to make
>> a bare repository replica of the MainRep. Now i am not sure how to
>> keep it in sync with the MainRep.
>
> $ git fetch
>
> as it is bare you cannot merge, so you cannot pull.
>
> HTH,
> Santi
>
Here is what i get when i try to use git-fetch:
# git fetch
ssh: : Name or service not known
fatal: The remote end hung up unexpectedly
Following is the current content of my config file:
[core]
repositoryformatversion = 0
filemode = true
bare = true
[remote "origin"]
url = ssh://gituser@<addr removed>
fetch = +refs/*:refs/*
mirror = yes
I also tried git-fetch with the url as argument but that also gave the
same error. Do i need to do some additional configurations to make
fetch work?
Thanks
Yaser
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Alex Riesen @ 2008-11-07 7:13 UTC (permalink / raw)
To: Miles Bader; +Cc: Linus Torvalds, git
In-Reply-To: <fc339e4a0811062038x22e7a3co503f09678f9ff5aa@mail.gmail.com>
Miles Bader, Fri, Nov 07, 2008 05:38:16 +0100:
> [git-am seems to have some similar features, but I don't know how well
> they work.]
They work well.
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Alex Riesen @ 2008-11-07 7:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, git
In-Reply-To: <7vskq4gmf5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano, Fri, Nov 07, 2008 06:00:46 +0100:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > On Thu, 6 Nov 2008, Alex Riesen wrote:
> >>
> >> git format-patch --full-index --binary --stdout <range...> | git am -3
> >>
> >> This will not work if you want to pick a list, not a range, of
> >> commits.
> >
> > Doesn't "--no-walk" + list commits individually work?
> >
> > So it _should_ be possible to pick a list of commits too. Although I think
> > that git format-patch will reverse the order.
>
> Or "git show --pretty=email $commit1 $commit2" ... piped to "am"?
>
Does not work if there are ranges given :-/
It'd be very nice to have: git show #c1..$c2 $c3 $c4 $c5..$c6
^ permalink raw reply
* Re: Stgit and refresh-temp
From: Karl Hasselström @ 2008-11-07 5:44 UTC (permalink / raw)
To: Jon Smirl; +Cc: Catalin Marinas, Git Mailing List
In-Reply-To: <9e4733910811040537p4e88c09an94370154eca12778@mail.gmail.com>
On 2008-11-04 08:37:24 -0500, Jon Smirl wrote:
> I hit a case when refreshing a buried patch that needed a merge
> conflict sorted out. I'm unable to recover out of the state.
Hmm, so what you're saying is basically that you did something with
"stg refresh -p" that caused a merge conflict, and that messed things
up so that you needed to run "stg repair". Is that right?
Have you been able to reproduce it? (I would like to add the failing
case to the test suite.)
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Miles Bader @ 2008-11-07 5:09 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Deskin Miller, git
In-Reply-To: <20081106122658.GB4192@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>> > git reset --hard C
>> > git rebase --onto ORIG_HEAD A^
>>
>> Is that safe...? Doesn't git-rebase also set ORIG_HEAD?
>
> One of the first things rebase does is validating and resolving its
> arguments. And that's happening before any actions that would touch
> ORIG_HEAD.
Ah, I see.
Hmm, I guess using rebase --abort isn't a very good idea in this case
though... :-/
Kind of a shame, since it's nice being to just abort the whole operation
if it turns out you did something wrong and aren't sure how to recover.
Thanks,
-Miles
--
Kilt, n. A costume sometimes worn by Scotchmen [sic] in America and Americans
in Scotland.
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Junio C Hamano @ 2008-11-07 5:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alex Riesen, Miles Bader, git
In-Reply-To: <alpine.LFD.2.00.0811061925300.3451@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Thu, 6 Nov 2008, Alex Riesen wrote:
>>
>> git format-patch --full-index --binary --stdout <range...> | git am -3
>>
>> This will not work if you want to pick a list, not a range, of
>> commits.
>
> Doesn't "--no-walk" + list commits individually work?
>
> So it _should_ be possible to pick a list of commits too. Although I think
> that git format-patch will reverse the order.
Or "git show --pretty=email $commit1 $commit2" ... piped to "am"?
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Miles Bader @ 2008-11-07 4:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Alex Riesen, git
In-Reply-To: <alpine.LFD.2.00.0811061925300.3451@nehalem.linux-foundation.org>
>> git format-patch --full-index --binary --stdout <range...> | git am -3
>>
>> This will not work if you want to pick a list, not a range, of
>> commits.
>
> Doesn't "--no-walk" + list commits individually work?
>
> So it _should_ be possible to pick a list of commits too. Although I think
> that git format-patch will reverse the order.
Incidentally, the reason I like a rebase-based solution is that many
of the rebase features like -i, --abort, and --continue (after
conflict resolution) are very nice for the multi-cherry-pick case too,
and I'm already very familiar with their operation from using rebase.
[git-am seems to have some similar features, but I don't know how well
they work.]
-Miles
--
Do not taunt Happy Fun Ball.
^ permalink raw reply
* Re: multiple-commit cherry-pick?
From: Linus Torvalds @ 2008-11-07 3:29 UTC (permalink / raw)
To: Alex Riesen; +Cc: Miles Bader, git
In-Reply-To: <20081106213711.GA4334@blimp.localdomain>
On Thu, 6 Nov 2008, Alex Riesen wrote:
>
> git format-patch --full-index --binary --stdout <range...> | git am -3
>
> This will not work if you want to pick a list, not a range, of
> commits.
Doesn't "--no-walk" + list commits individually work?
So it _should_ be possible to pick a list of commits too. Although I think
that git format-patch will reverse the order.
Linus
^ permalink raw reply
* [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-07 3:26 UTC (permalink / raw)
To: git
Implement git-pull --quiet and git-pull --verbose by
adding the options to git-pull and fixing verbosity
handling in git-fetch.
Signed-off-by: Tuncer Ayaz <tuncer.ayaz@gmail.com>
---
Documentation/merge-options.txt | 8 +++++
builtin-fetch.c | 21 +++++++------
builtin-merge.c | 22 ++++++++++----
git-pull.sh | 10 ++++--
t/t5521-pull-options.sh | 60 +++++++++++++++++++++++++++++++++++++++
5 files changed, 101 insertions(+), 20 deletions(-)
create mode 100755 t/t5521-pull-options.sh
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index 007909a..427cdef 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -1,3 +1,11 @@
+-q::
+--quiet::
+ Operate quietly.
+
+-v::
+--verbose::
+ Be verbose.
+
--stat::
Show a diffstat at the end of the merge. The diffstat is also
controlled by the configuration option merge.stat.
diff --git a/builtin-fetch.c b/builtin-fetch.c
index f151cfa..efc5801 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -22,16 +22,17 @@ enum {
TAGS_SET = 2
};
-static int append, force, keep, update_head_ok, verbose, quiet;
+static int append, force, keep, update_head_ok;
static int tags = TAGS_DEFAULT;
static const char *depth;
static const char *upload_pack;
static struct strbuf default_rla = STRBUF_INIT;
static struct transport *transport;
+static enum { QUIET, NORMAL, VERBOSE } verbosity = NORMAL;
static struct option builtin_fetch_options[] = {
- OPT__QUIET(&quiet),
- OPT__VERBOSE(&verbose),
+ OPT_SET_INT('v', "verbose", &verbosity, "be verbose", VERBOSE),
+ OPT_SET_INT('q', "quiet", &verbosity, "operate quietly", QUIET),
OPT_BOOLEAN('a', "append", &append,
"append to .git/FETCH_HEAD instead of overwriting"),
OPT_STRING(0, "upload-pack", &upload_pack, "PATH",
@@ -192,7 +193,6 @@ static int s_update_ref(const char *action,
static int update_local_ref(struct ref *ref,
const char *remote,
- int verbose,
char *display)
{
struct commit *current = NULL, *updated;
@@ -210,7 +210,7 @@ static int update_local_ref(struct ref *ref,
die("object %s not found", sha1_to_hex(ref->new_sha1));
if (!hashcmp(ref->old_sha1, ref->new_sha1)) {
- if (verbose)
+ if (verbosity == VERBOSE)
sprintf(display, "= %-*s %-*s -> %s", SUMMARY_WIDTH,
"[up to date]", REFCOL_WIDTH, remote,
pretty_ref);
@@ -366,18 +366,19 @@ static int store_updated_refs(const char *url, const char *remote_name,
note);
if (ref)
- rc |= update_local_ref(ref, what, verbose, note);
+ rc |= update_local_ref(ref, what, note);
else
sprintf(note, "* %-*s %-*s -> FETCH_HEAD",
SUMMARY_WIDTH, *kind ? kind : "branch",
REFCOL_WIDTH, *what ? what : "HEAD");
if (*note) {
- if (!shown_url) {
+ if (verbosity > QUIET && !shown_url) {
fprintf(stderr, "From %.*s\n",
url_len, url);
shown_url = 1;
}
- fprintf(stderr, " %s\n", note);
+ if (verbosity > QUIET)
+ fprintf(stderr, " %s\n", note);
}
}
fclose(fp);
@@ -637,9 +638,9 @@ int cmd_fetch(int argc, const char **argv, const char *prefix)
remote = remote_get(argv[0]);
transport = transport_get(remote, remote->url[0]);
- if (verbose >= 2)
+ if (verbosity == VERBOSE)
transport->verbose = 1;
- if (quiet)
+ if (verbosity == QUIET)
transport->verbose = -1;
if (upload_pack)
set_option(TRANS_OPT_UPLOADPACK, upload_pack);
diff --git a/builtin-merge.c b/builtin-merge.c
index 5e7910b..76e2890 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -50,6 +50,7 @@ static unsigned char head[20], stash[20];
static struct strategy **use_strategies;
static size_t use_strategies_nr, use_strategies_alloc;
static const char *branch;
+static enum { QUIET, NORMAL, VERBOSE } verbosity = NORMAL;
static struct strategy all_strategy[] = {
{ "recursive", DEFAULT_TWOHEAD | NO_TRIVIAL },
@@ -152,6 +153,8 @@ static int option_parse_n(const struct option *opt,
}
static struct option builtin_merge_options[] = {
+ OPT_SET_INT('v', "verbose", &verbosity, "be verbose", VERBOSE),
+ OPT_SET_INT('q', "quiet", &verbosity, "operate quietly", QUIET),
{ OPTION_CALLBACK, 'n', NULL, NULL, NULL,
"do not show a diffstat at the end of the merge",
PARSE_OPT_NOARG, option_parse_n },
@@ -250,7 +253,8 @@ static void restore_state(void)
/* This is called when no merge was necessary. */
static void finish_up_to_date(const char *msg)
{
- printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
+ if (verbosity > QUIET)
+ printf("%s%s\n", squash ? " (nothing to squash)" : "", msg);
drop_save();
}
@@ -331,14 +335,15 @@ static void finish(const unsigned char *new_head, const char *msg)
if (!msg)
strbuf_addstr(&reflog_message, getenv("GIT_REFLOG_ACTION"));
else {
- printf("%s\n", msg);
+ if (verbosity > QUIET)
+ printf("%s\n", msg);
strbuf_addf(&reflog_message, "%s: %s",
getenv("GIT_REFLOG_ACTION"), msg);
}
if (squash) {
squash_message();
} else {
- if (!merge_msg.len)
+ if (verbosity > QUIET && !merge_msg.len)
printf("No merge message -- not updating HEAD\n");
else {
const char *argv_gc_auto[] = { "gc", "--auto", NULL };
@@ -872,6 +877,8 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, builtin_merge_options,
builtin_merge_usage, 0);
+ if (verbosity > QUIET)
+ show_diffstat = 0;
if (squash) {
if (!allow_fast_forward)
@@ -1013,10 +1020,11 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
strcpy(hex, find_unique_abbrev(head, DEFAULT_ABBREV));
- printf("Updating %s..%s\n",
- hex,
- find_unique_abbrev(remoteheads->item->object.sha1,
- DEFAULT_ABBREV));
+ if (verbosity > QUIET)
+ printf("Updating %s..%s\n",
+ hex,
+ find_unique_abbrev(remoteheads->item->object.sha1,
+ DEFAULT_ABBREV));
strbuf_addstr(&msg, "Fast forward");
if (have_message)
strbuf_addstr(&msg,
diff --git a/git-pull.sh b/git-pull.sh
index 664fe34..8866f2a 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -16,13 +16,17 @@ cd_to_toplevel
test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
-strategy_args= no_stat= no_commit= squash= no_ff= log_arg=
+strategy_args= no_stat= no_commit= squash= no_ff= log_arg= verbosity=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
rebase=$(git config --bool branch.$curr_branch_short.rebase)
while :
do
case "$1" in
+ -q|--quiet)
+ verbosity=-q ;;
+ -v|--verbose)
+ verbosity=-v ;;
-n|--no-stat|--no-summary)
no_stat=-n ;;
--stat|--summary)
@@ -121,7 +125,7 @@ test true = "$rebase" && {
"refs/remotes/$origin/$reflist" 2>/dev/null)"
}
orig_head=$(git rev-parse --verify HEAD 2>/dev/null)
-git fetch --update-head-ok "$@" || exit 1
+git fetch $verbosity --update-head-ok "$@" || exit 1
curr_head=$(git rev-parse --verify HEAD 2>/dev/null)
if test -n "$orig_head" && test "$curr_head" != "$orig_head"
@@ -182,4 +186,4 @@ test true = "$rebase" &&
exec git-rebase $strategy_args --onto $merge_head \
${oldremoteref:-$merge_head}
exec git-merge $no_stat $no_commit $squash $no_ff $log_arg $strategy_args \
- "$merge_name" HEAD $merge_head
+ "$merge_name" HEAD $merge_head $verbosity
diff --git a/t/t5521-pull-options.sh b/t/t5521-pull-options.sh
new file mode 100755
index 0000000..83e2e8a
--- /dev/null
+++ b/t/t5521-pull-options.sh
@@ -0,0 +1,60 @@
+#!/bin/sh
+
+test_description='pull options'
+
+. ./test-lib.sh
+
+D=`pwd`
+
+test_expect_success 'setup' '
+ mkdir parent &&
+ (cd parent && git init &&
+ echo one >file && git add file &&
+ git commit -m one)
+'
+
+cd "$D"
+
+test_expect_success 'git pull -q' '
+ mkdir clonedq &&
+ cd clonedq &&
+ git pull -q "$D/parent" >out 2>err &&
+ test ! -s out
+'
+
+cd "$D"
+
+test_expect_success 'git pull' '
+ mkdir cloned &&
+ cd cloned &&
+ git pull "$D/parent" >out 2>err &&
+ test -s out
+'
+cd "$D"
+
+test_expect_success 'git pull -v' '
+ mkdir clonedv &&
+ cd clonedv &&
+ git pull -v "$D/parent" >out 2>err &&
+ test -s out
+'
+
+cd "$D"
+
+test_expect_success 'git pull -v -q' '
+ mkdir clonedvq &&
+ cd clonedvq &&
+ git pull -v -q "$D/parent" >out 2>err &&
+ test ! -s out
+'
+
+cd "$D"
+
+test_expect_success 'git pull -q -v' '
+ mkdir clonedqv &&
+ cd clonedqv &&
+ git pull -q -v "$D/parent" >out 2>err &&
+ test -s out
+'
+
+test_done
--
1.6.0.2.GIT
^ permalink raw reply related
* Re: [PATCH] Teach/Fix pull/fetch -q/-v options
From: Tuncer Ayaz @ 2008-11-07 3:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <4ac8254d0811011023r10a4ce45ka962344ceef564f0@mail.gmail.com>
On Sat, Nov 1, 2008 at 6:23 PM, Tuncer Ayaz <tuncer.ayaz@gmail.com> wrote:
> On Tue, Oct 28, 2008 at 4:21 AM, Junio C Hamano <gitster@pobox.com> wrote:
>> Nanako Shiraishi <nanako3@lavabit.com> writes:
>>
>>> Quoting Tuncer Ayaz <tuncer.ayaz@gmail.com>:
>>>
>>>> After fixing clone -q I noticed that pull -q does not do what
>>>> it's supposed to do and implemented --quiet/--verbose by
>>>> adding it to builtin-merge and fixing two places in builtin-fetch.
>>>
>>> Junio, may I ask what the status of this patch is? Maybe the patch was
>>> lost in the noise? The commit log message is written very differently from
>>> existing commits in the history of git, and I am thinking that maybe that is
>>> why you did not like the whole patch? Or is it lack of any test script?
>>
>> Well, perhaps you've been with us long enough to get too picky like
>> myself, but this was genuinely lost in the noise and my scrambling to get
>> back to normal. We do not typically say "I did this, I did that", but the
>> first paragraph in Tuncer's message is perfectly fine. I would probably
>> liked the second paragraph better if it were after --- lines (it is more
>> about the possible enhancements in other areas, and does not belong to the
>> commit log message for this change), but it is not a grave enough offence
>> to get the patch rejected.
>
> Should I resend the patch with a short and simple commit message
> like the following?
> --8<--
> Implement git-pull --quiet and --verbose by adding the
> options to git-pull and fixing verbosity handling in git-fetch.
> -->8--
>
>> The patch itself looks Ok; the lack of test script additions does indeed
>> bother me somewhat, but it is not too big a deal.
>
> I took a look at t/ and am not quite sure whether I should test -v/-q
> by analyzing stdout output's length & content.
>
> I think testing -q and -v makes more sense on a global and not
> git-pull or git-fetch level. For that to be possible I envision building
> common verbosity-based logging functions/macros.
>
> I don't like the idea of scanning stdout for length or content as
> long as we're not sure that all errors and warnings are sent
> to stderr and stdout is for info and verbose only.
>
>> P.S. We are having fun at GitTogether'08 in the first half of this week,
>> so please expect slower response than usual.
>
Please see my next patch revision arriving here in a moment.
^ permalink raw reply
* Fwd: Documentation/user-manual.txt, asciidoc and "--" escapes
From: Piotr Findeisen @ 2008-11-07 3:09 UTC (permalink / raw)
To: git
In-Reply-To: <ddb82bf60811061904t5defc492m80cd1b759674eb6@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 918 bytes --]
Hello!
I've been reading
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html till
late night and found that "--" prefixing options names (like in "git
diff --cached") are replaced by asciidoc with a single unicode
character "—" which makes them unsuitable for pasting them to a
terminal.
I've cloned the git repository from
git://git.kernel.org/pub/scm/git/git.git, made some changes to
Documentation/user-manual.txt, tested the results and commited my work
locally.
The attached file is a result of running `git diff HEAD~1`.
My local log message:
------------------
asciidoc escaping of "--"
Asciidoc replaces "--" with "—" when not in verbatim mode. This is
sometimes unwanted -- especially when citing command line options like
"git diff --cached". This commit includes proper quotes in user-manual.txt.
------------------
Hope that's of any use.
Best regards,
Piotr
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: user-manual.txt.patch --]
[-- Type: text/x-diff; name=user-manual.txt.patch, Size: 7018 bytes --]
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 645d752..66d0cca 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -527,8 +527,8 @@ $ git reset --hard fb47ddb2db...
then test, run "bisect good" or "bisect bad" as appropriate, and
continue.
-Instead of "git bisect visualize" and then "git reset --hard
-fb47ddb2db...", you might just want to tell git that you want to skip
+Instead of "git bisect visualize" and then "+++git reset --hard
+fb47ddb2db...+++", you might just want to tell git that you want to skip
the current commit:
-------------------------------------------------
@@ -660,7 +660,7 @@ You can also ask git log to show patches:
$ git log -p
-------------------------------------------------
-See the "--pretty" option in the linkgit:git-log[1] man page for more
+See the "+++--pretty+++" option in the linkgit:git-log[1] man page for more
display options.
Note that git log starts with the most recent commit and works
@@ -900,7 +900,7 @@ $ gitk $( git show-ref --heads ) --not $( git show-ref --tags )
-------------------------------------------------
(See linkgit:git-rev-parse[1] for explanations of commit-selecting
-syntax such as `--not`.)
+syntax such as `+++--not+++`.)
[[making-a-release]]
Creating a changelog and tarball for a software release
@@ -1024,7 +1024,7 @@ at step 3, git maintains a snapshot of the tree's contents in a
special staging area called "the index."
At the beginning, the content of the index will be identical to
-that of the HEAD. The command "git diff --cached", which shows
+that of the HEAD. The command "+++git diff --cached+++", which shows
the difference between the HEAD and the index, should therefore
produce no output at that point.
@@ -1572,7 +1572,7 @@ Recovering lost changes
Reflogs
^^^^^^^
-Say you modify a branch with `linkgit:git-reset[1] --hard`, and then
+Say you modify a branch with `linkgit:git-reset[1] +++--hard+++`, and then
realize that the branch was the only reference you had to that point in
history.
@@ -1701,7 +1701,7 @@ $ git pull
More generally, a branch that is created from a remote branch will pull
by default from that branch. See the descriptions of the
branch.<name>.remote and branch.<name>.merge options in
-linkgit:git-config[1], and the discussion of the `--track` option in
+linkgit:git-config[1], and the discussion of the `+++--track+++` option in
linkgit:git-checkout[1], to learn how to control these defaults.
In addition to saving you keystrokes, "git pull" also helps you by
@@ -1978,8 +1978,8 @@ error: failed to push to 'ssh://yourserver.com/~you/proj.git'
This can happen, for example, if you:
- - use `git-reset --hard` to remove already-published commits, or
- - use `git-commit --amend` to replace already-published commits
+ - use `+++git-reset --hard+++` to remove already-published commits, or
+ - use `+++git-commit --amend+++` to replace already-published commits
(as in <<fixing-a-mistake-by-rewriting-history>>), or
- use `git-rebase` to rebase any already-published commits (as
in <<using-git-rebase>>).
@@ -2088,7 +2088,7 @@ linkgit:git-fetch[1] to keep them up-to-date; see
Now create the branches in which you are going to work; these start out
at the current tip of origin/master branch, and should be set up (using
-the --track option to linkgit:git-branch[1]) to merge changes in from
+the +++--track+++ option to linkgit:git-branch[1]) to merge changes in from
Linus by default.
-------------------------------------------------
@@ -2468,7 +2468,7 @@ $ git rebase --continue
and git will continue applying the rest of the patches.
-At any point you may use the `--abort` option to abort this process and
+At any point you may use the `+++--abort+++` option to abort this process and
return mywork to the state it had before you started the rebase:
-------------------------------------------------
@@ -2539,7 +2539,7 @@ $ gitk origin..mywork &
and browse through the list of patches in the mywork branch using gitk,
applying them (possibly in a different order) to mywork-new using
-cherry-pick, and possibly modifying them as you go using `commit --amend`.
+cherry-pick, and possibly modifying them as you go using `+++commit --amend+++`.
The linkgit:git-gui[1] command may also help as it allows you to
individually select diff hunks for inclusion in the index (by
right-clicking on the diff hunk and choosing "Stage Hunk for Commit").
@@ -2897,7 +2897,7 @@ Commit Object
~~~~~~~~~~~~~
The "commit" object links a physical state of a tree with a description
-of how we got there and why. Use the --pretty=raw option to
+of how we got there and why. Use the +++--pretty=raw+++ option to
linkgit:git-show[1] or linkgit:git-log[1] to examine your favorite
commit:
@@ -3700,16 +3700,16 @@ i.e. it will normally just update existing cache entries.
To tell git that yes, you really do realize that certain files no
longer exist, or that new files should be added, you
-should use the `--remove` and `--add` flags respectively.
+should use the `+++--remove+++` and `+++--add+++` flags respectively.
-NOTE! A `--remove` flag does 'not' mean that subsequent filenames will
+NOTE! A `+++--remove+++` flag does 'not' mean that subsequent filenames will
necessarily be removed: if the files still exist in your directory
structure, the index will be updated with their new status, not
-removed. The only thing `--remove` means is that update-index will be
+removed. The only thing `+++--remove+++` means is that update-index will be
considering a removed file to be a valid thing, and if the file really
does not exist any more, it will update the index accordingly.
-As a special case, you can also do `git update-index --refresh`, which
+As a special case, you can also do `+++git update-index --refresh+++`, which
will refresh the "stat" information of each index to match the current
stat information. It will 'not' update the object status itself, and
it will only update the fields that are used to quickly test whether
@@ -3956,7 +3956,7 @@ entries" in it. Such an index tree can 'NOT' be written out to a tree
object, and you will have to resolve any such merge clashes using
other tools before you can write out the result.
-You can examine such index state with `git ls-files --unmerged`
+You can examine such index state with `+++git ls-files --unmerged+++`
command. An example:
------------------------------------------------
@@ -3967,7 +3967,7 @@ $ git ls-files --unmerged
100644 cc44c73eb783565da5831b4d820c962954019b69 3 hello.c
------------------------------------------------
-Each line of the `git ls-files --unmerged` output begins with
+Each line of the `+++git ls-files --unmerged+++` output begins with
the blob mode bits, blob SHA1, 'stage number', and the
filename. The 'stage number' is git's way to say which tree it
came from: stage 1 corresponds to `$orig` tree, stage 2 `HEAD`
^ permalink raw reply related
* [KORG] Master backend downtime - hardware swap
From: J.H. @ 2008-11-07 1:43 UTC (permalink / raw)
To: users, git, linux-kernel, ftpadmin
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hey everyone,
Just a heads up to everyone, I'm going to be taking the master (hera)
backend server offline for a couple of hours tomorrow (Friday, CST)
afternoon. Downtime is going to get used for finishing flipping over
the master to new hardware, which was very generously donated by
Hewlett-Packard. We are moving up to a new DL380 G5. That said I will
need time to shut everything down, get a current rsync from the old
hardware to the new hardware and confirm that serves are restored on the
new machine.
I'm expecting the entire downtime to only take a couple of hours, but
since we all know things will take longer I'm going to declare the
window from 1200 CST (1800 UTC Friday Nov 7th). Expect the window to
run through 2000 UTC, and if things are up and running before that I'll
let people know. Otherwise if there are problems you'll see another
e-mail from me.
If you have questions, comments, concerns, etc - please send them to me
CC ftpadmin@kernel.org
- - John 'Warthog9' Hawley
Chief Kernel.org Administrator
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (GNU/Linux)
Comment: Using GnuPG with Remi - http://enigmail.mozdev.org
iD8DBQFJE51L/E3kyWU9dicRAs8/AJ9DVJjQxcOt9CUVsQYVM6elJkTr2gCePLJ8
+UuEcZdwUpAICFijAXp9ae4=
=c6vs
-----END PGP SIGNATURE-----
^ permalink raw reply
* [PATCH 4/4] builtin-gc.c: use new pack_keep bitfield to detect .keep file existence
From: Brandon Casey @ 2008-11-07 1:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <-NKrpBlnD0U49OczAyUd7HiIBqhMblkOkU4lOc2bc9qfTrGNrwpLTg@cipher.nrlssc.navy.mil>
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
I think the existing code was broken. Looks like it would only skip
counting a pack if the pack disappeared between the prepare_packed_git()
and the access() call. It never used the path it create with the .keep
extension.
-brandon
builtin-gc.c | 12 +-----------
1 files changed, 1 insertions(+), 11 deletions(-)
diff --git a/builtin-gc.c b/builtin-gc.c
index 7af65bb..781df60 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -131,19 +131,9 @@ static int too_many_packs(void)
prepare_packed_git();
for (cnt = 0, p = packed_git; p; p = p->next) {
- char path[PATH_MAX];
- size_t len;
- int keep;
-
if (!p->pack_local)
continue;
- len = strlen(p->pack_name);
- if (PATH_MAX <= len + 1)
- continue; /* oops, give up */
- memcpy(path, p->pack_name, len-5);
- memcpy(path + len - 5, ".keep", 6);
- keep = access(p->pack_name, F_OK) && (errno == ENOENT);
- if (keep)
+ if (p->pack_keep)
continue;
/*
* Perhaps check the size of the pack and count only
--
1.6.0.3.552.g12334
^ permalink raw reply related
* [PATCH 3/4] repack: do not fall back to incremental repacking with [-a|-A]
From: Brandon Casey @ 2008-11-07 1:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <P5afFyDEMjF9ynd9dfSfGeRo_GFY_K6ZAn2nIYo8_xGgSl4LapbSOA@cipher.nrlssc.navy.mil>
When repack is called with either the -a or -A option, the user has
requested to repack all objects including those referenced by the
alternates mechanism. Currently, if there are no local packs without
.keep files, then repack will call pack-objects with the
'--unpacked --incremental' options which causes it to exclude alternate
packed objects. So, remove this fallback.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
git-repack.sh | 11 ++++-------
1 files changed, 4 insertions(+), 7 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index 8bb2201..4d313d1 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -71,13 +71,10 @@ case ",$all_into_one," in
existing="$existing $e"
fi
done
- fi
- if test -z "$args"
- then
- args='--unpacked --incremental'
- elif test -n "$unpack_unreachable"
- then
- args="$args $unpack_unreachable"
+ if test -n "$args" -a -n "$unpack_unreachable"
+ then
+ args="$args $unpack_unreachable"
+ fi
fi
;;
esac
--
1.6.0.3.552.g12334
^ permalink raw reply related
* [PATCH 2/4] repack: don't repack local objects in packs with .keep file
From: Brandon Casey @ 2008-11-07 1:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Git Mailing List, Shawn O. Pearce, Nicolas Pitre,
Andreas Ericsson
In-Reply-To: <oDevG_2ETMLvy6rfSqvxfmFqABeVqlDUcU6FjP07E5IzqLaopWkQbQ@cipher.nrlssc.navy.mil>
If the user created a .keep file for a local pack, then it can be inferred
that the user does not want those objects repacked.
This fixes the repack bug tested by t7700.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
git-repack.sh | 2 +-
t/t7700-repack.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-repack.sh b/git-repack.sh
index d39eb6c..8bb2201 100755
--- a/git-repack.sh
+++ b/git-repack.sh
@@ -83,7 +83,7 @@ case ",$all_into_one," in
esac
args="$args $local $quiet $no_reuse$extra"
-names=$(git pack-objects --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
+names=$(git pack-objects --honor-pack-keep --non-empty --all --reflog $args </dev/null "$PACKTMP") ||
exit 1
if [ -z "$names" ]; then
if test -z "$quiet"; then
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index 7aaff0b..356afe3 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -4,7 +4,7 @@ test_description='git repack works correctly'
. ./test-lib.sh
-test_expect_failure 'objects in packs marked .keep are not repacked' '
+test_expect_success 'objects in packs marked .keep are not repacked' '
echo content1 > file1 &&
echo content2 > file2 &&
git add . &&
--
1.6.0.3.552.g12334
^ 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