* Re: gitosis-lite
From: Sitaram Chamarty @ 2009-08-25 3:00 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Jakub Narebski, Git Mailing List, Tommi Virtanen
In-Reply-To: <20090824151051.GB1033@spearce.org>
On Mon, Aug 24, 2009 at 8:40 PM, Shawn O. Pearce<spearce@spearce.org> wrote:
> Sitaram Chamarty <sitaramc@gmail.com> wrote:
>> I'll be honest: I
>> came away feeling very stupid after trying to read and
>> understand that program. It was... humbling :(
> *sigh* That's not good, the hook is meant as a practical example,
> if it was too complex to understand, I did a poor job of writing it.
Hmmm no. It was just doing too much to grasp in one
reading, especially by someone whose perl seems to have
rusted a wee bit, if you've seen Jakub's reply :)
I took a slightly longer look after your mail and I grokked
it a lot better. And wow... I guess you called it
"paranoid" for a reason :-)
In the environments I'm catering to, every commit will be
reviewed by someone else (usually someone more experienced,
and having a bigger picture), so "you're not allowed to
touch this file" type of thing will all come out.
All I need is to make sure the important branches can only
be pushed to by certain people; the "process" will take care
of the rest.
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Junio C Hamano @ 2009-08-25 2:13 UTC (permalink / raw)
To: Jeff King; +Cc: Kirill A. Korinskiy, gitster, git
In-Reply-To: <20090825015726.GB7655@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Aug 25, 2009 at 12:42:48AM +0400, Kirill A. Korinskiy wrote:
>
>> Sometimes (especially on production systems) we need to use only one
>> remote branch for building software. It really annoying to clone
>> origin and then swith branch by hand everytime. So this patch provide
>> functionality to clone remote branch with one command without using
>> checkout after clone.
>
> If you are doing this a lot, it is probably a sign that you should
> repoint the "HEAD" of the parent repository.
>
> That being said, you may want one branch half the time, and another
> branch the other half. So I think this is a good feature.
>
> A few comments:
Very good review snipped, as I agree with everything you said (except that
you did not point out the lack of sign-off).
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Shawn O. Pearce @ 2009-08-25 2:12 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Julian Phillips, Daniel Barkalow, Junio C Hamano,
Johannes Schindelin, git
In-Reply-To: <alpine.LFD.2.00.0908242001250.6044@xanadu.home>
Nicolas Pitre <nico@cam.org> wrote:
> Well... Johan Herland says he has to deal with repositories containing
> around 50000 refs. So in that case it is certainly a good idea not to
> send the whole 50000 refs back if only one or two (or a hundred) need to
> be updated. And quickfetch() won't help in that case since its purpose
> is only to determine if there is anything at all to update.
...
> 50000 refs * 45 bytes each = 2.25 MB. That's all wasted bandwidth if
> only one ref needs updating.
Not just Johan Herland. Gerrit Code Review creates a new ref
for every patch proposed for review. Imagine taking every email
message on git ML that has "[PATCH]" in the subject, and creating
a new ref for that in a git.git clone.
We aren't quite at the 50k ref stage yet, but we're starting to
consider that some of our repositories have a ton of refs, and
that the initial advertisement for either fetch or push is horrid.
Since the refs are immutable I could actually teach the JGit
daemon to hide them from JGit's receive-pack, thus cutting down the
advertisement on push, but the refs exist so you can literally say:
git fetch URL refs/changes/88/4488/2
git show FETCH_HEAD
to inspect the "v2" version of whatever 4488 is, and if 4488 was
the last commit in a patch series, you'd also be able to do:
git log -p --reverse ..FETCH_HEAD
to see the complete series.
Given how infrequent it is to grab a given change is though, I'm
starting to consider either a protocol extension that allows the
client to probe for a ref which wasn't in the initial advertisement,
or take it on a command line flag, e.g.:
git fetch --uploadpack='git upload-pack --ref refs/changes/88/4488/2' URL refs/changes/88/4488/2
Personally I'd prefer extending the protocol, because making the
end user supply information twice is stupid.
I don't know enough about Johan's case though to know whether or
not he can get away with hiding the bulk of the refs in the initial
advertisement. In the case of Gerrit Code Review, the bulk of the
refs is under refs/changes/, only a handful of things are under the
refs/heads/ and ref/tags/ namespace, and most fetches actually are
for only refs/heads/ and refs/tags/. So hiding the refs/changes/
namespace would make large improvement in the advertisement cost.
--
Shawn.
^ permalink raw reply
* Re: Possible regression: overwriting untracked files in a fresh repo
From: Junio C Hamano @ 2009-08-25 2:11 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20090825013601.GA3515@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> diff --git a/builtin-checkout.c b/builtin-checkout.c
> index 8a9a474..1f2f84d 100644
> --- a/builtin-checkout.c
> +++ b/builtin-checkout.c
> @@ -402,7 +402,9 @@ static int merge_working_tree(struct checkout_opts *opts,
> topts.dir = xcalloc(1, sizeof(*topts.dir));
> topts.dir->flags |= DIR_SHOW_IGNORED;
> topts.dir->exclude_per_dir = ".gitignore";
> - tree = parse_tree_indirect(old->commit->object.sha1);
> + tree = parse_tree_indirect(old->commit ?
> + old->commit->object.sha1 :
> + (unsigned char *)EMPTY_TREE_SHA1_BIN);
> init_tree_desc(&trees[0], tree->buffer, tree->size);
> tree = parse_tree_indirect(new->commit->object.sha1);
> init_tree_desc(&trees[1], tree->buffer, tree->size);
This looks a lot saner; I like it. Care to wrap it up with the usual
supporting material?
I think the "You appear to be" can just go, but I do not feel very
strongly either way.
^ permalink raw reply
* Re: [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Jeff King @ 2009-08-25 1:57 UTC (permalink / raw)
To: Kirill A. Korinskiy; +Cc: gitster, git
In-Reply-To: <1251146568-25248-1-git-send-email-catap@catap.ru>
On Tue, Aug 25, 2009 at 12:42:48AM +0400, Kirill A. Korinskiy wrote:
> Sometimes (especially on production systems) we need to use only one
> remote branch for building software. It really annoying to clone
> origin and then swith branch by hand everytime. So this patch provide
> functionality to clone remote branch with one command without using
> checkout after clone.
If you are doing this a lot, it is probably a sign that you should
repoint the "HEAD" of the parent repository.
That being said, you may want one branch half the time, and another
branch the other half. So I think this is a good feature.
A few comments:
> ---
> Documentation/git-clone.txt | 4 ++++
> builtin-clone.c | 26 +++++++++++++++++++++++---
> 2 files changed, 27 insertions(+), 3 deletions(-)
Tests?
> - const struct ref *refs, *head_points_at, *remote_head, *mapped_refs;
> - struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
> + const struct ref *refs, *head_points_at, *remote_head = NULL, *mapped_refs;
> + struct strbuf key = STRBUF_INIT, value = STRBUF_INIT, branch_head = STRBUF_INIT;
Style nit: I don't know if we have a style guideline for declaring
variables, but I find these "many variables on a line" declarations
annoying for reviewing, since it is hard to see what actually changed
(and yes, you only added a declaration on one, so I am partially
complaining about the person who came before you :) ).
> + if (option_branch)
> + die("--bare and --branch %s options are incompatible.",
> + option_branch);
Hmm. Would it perhaps make sense to have "--bare --branch foo" point the
HEAD of the newly created bare repo, but not impact the (nonexistent)
working tree?
-Peff
^ permalink raw reply
* Re: Possible regression: overwriting untracked files in a fresh repo
From: Jeff King @ 2009-08-25 1:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <20090825013601.GA3515@coredump.intra.peff.net>
On Mon, Aug 24, 2009 at 09:36:01PM -0400, Jeff King wrote:
> I don't think this is the right thing to do. We have _no_ current
> branch, which means that everything in the working tree can be
> considered untracked (and therefore precious). So I think the right
> thing to do is barf and say "this untracked file would be overwritten".
> The user can sort it out as appropriate, either deleting files that are
> in the way, or using "-f" themselves (after they make the decision that
> what they have can be overwritten).
Actually, let me clarify that a bit. If we have no branch _and_ we have
no index, then everything is untracked. If we do have an index, then we
do a two-way merge from the HEAD. So if we have no branch in that case,
it makes sense to me to treat every element of the index as an addition,
meaning that anything in the new tree that is different should be a
conflict.
And that is what my patch does: it pretends that the HEAD is the empty
tree, which should produce sane output in both cases:
$ echo content >file
$ git checkout -b foo origin ;# origin has 'file' in it
error: Untracked working tree file 'file' would be overwritten by merge.
$ git add file
$ git checkout -b foo origin
error: Entry 'file' would be overwritten by merge. Cannot merge.
and it even handles the matching-index case when the merge is a no-op:
$ git show origin:file >file ;# match contents
$ git checkout -b foo origin
error: Untracked working tree file 'file' would be overwritten by merge.
$ git add file
$ git checkout -b foo origin
Switched to a new branch 'foo'
-Peff
^ permalink raw reply
* Re: Possible regression: overwriting untracked files in a fresh repo
From: Jeff King @ 2009-08-25 1:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vab1o3ikz.fsf@alter.siamese.dyndns.org>
On Mon, Aug 24, 2009 at 04:20:12PM -0700, Junio C Hamano wrote:
> I do not think that this is the correct fix, but it should be a good start
> for other people to take a look at the issue. With this change, any
> leftover work tree files will remain, but it has an interesting effect.
>
> $ git checkout maint
> $ echo 'ref: refs/heads/nosuch' >.git/HEAD
> $ git checkout -b foo master
>
> You will notice that the index matches master (as expected), but the work
> tree mostly matches maint. Knowing what these files are (i.e. "these are
> git.git source files that match 'maint' branch, and are vastly behind what
> are in 'master' branch we are switching to"), this result is utterly
> counterintuitive and feels wrong, but if you consider a case like what
> Dscho brought up originally in the thread of having a freshly initialized
> empty repository with some uncommitted files, totally unrelated to what
> you are checking out, I think you could argue that it is the right thing.
I don't think this is the right thing to do. We have _no_ current
branch, which means that everything in the working tree can be
considered untracked (and therefore precious). So I think the right
thing to do is barf and say "this untracked file would be overwritten".
The user can sort it out as appropriate, either deleting files that are
in the way, or using "-f" themselves (after they make the decision that
what they have can be overwritten).
Something like the patch below seems to work on the test case I posted
earlier, and passes the test suite (but other than that, I am very
unconfident, never having really looked at the checkout code before).
As an aside, if an unborn branch stops implying "-f", should we bother
even mentioning it? It seems superfluous now.
---
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 8a9a474..1f2f84d 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -402,7 +402,9 @@ static int merge_working_tree(struct checkout_opts *opts,
topts.dir = xcalloc(1, sizeof(*topts.dir));
topts.dir->flags |= DIR_SHOW_IGNORED;
topts.dir->exclude_per_dir = ".gitignore";
- tree = parse_tree_indirect(old->commit->object.sha1);
+ tree = parse_tree_indirect(old->commit ?
+ old->commit->object.sha1 :
+ (unsigned char *)EMPTY_TREE_SHA1_BIN);
init_tree_desc(&trees[0], tree->buffer, tree->size);
tree = parse_tree_indirect(new->commit->object.sha1);
init_tree_desc(&trees[1], tree->buffer, tree->size);
@@ -541,13 +543,8 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
parse_commit(new->commit);
}
- if (!old.commit && !opts->force) {
- if (!opts->quiet) {
- warning("You appear to be on a branch yet to be born.");
- warning("Forcing checkout of %s.", new->name);
- }
- opts->force = 1;
- }
+ if (!old.commit && !opts->force && !opts->quiet)
+ warning("You appear to be on a branch yet to be born.");
ret = merge_working_tree(opts, &old, new);
if (ret)
^ permalink raw reply related
* Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Brandon Casey @ 2009-08-25 0:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vy6p86f9y.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:
>
>> Nicolas is right, the code compiles and executes correctly on Solaris as-is.
>>
>> Here is the state of the two unsubmitted optimization patches:
>>
>> 1) Change things like __i386__ to __i386 since GCC defines both, but
>> SUNWspro only defines __i386.
>>
>> This works correctly in my testing. I'm assuming that a test for
>> __amd64 is not necessary and expect that __x86_64 is set whenever
>> __amd64 is set.
>>
>> 2) Set __GNUC__ on SUNWspro v5.10 and up.
>>
>> This compiles correctly and passes the test suite, but produces
>> warnings for __attribute__'s that sun's compiler has not implemented.
>> This produces a very noisy compile.
>>
>> I've wanted to do some performance testing to see whether this actually
>> produces an _improvement_. I'll try today.
>
> Thanks.
>
> I agree (1) would be a reasonable thing to do.
>
> (2) feels very iffy/hacky. As far as I can see, by defining __GNUC__,
> Solaris would also use builtin-alloca in compat/regex/regex.c, which may
> or may not be what you want.
>
> It might be cleaner to do:
>
> #if __GNUC__ || SUNWspro > 5.10
> #define GCC_LIKE_INLINE_ASM
> #define GCC_LIKE_STMT_EXPR
> #endif
>
> and use them, instead of __GNUC__, to enable the inline assembly used in
> the block sha1 codepath.
Yes, this sounds saner, but alas it will have to be tomorrow...
-brandon
^ permalink raw reply
* Re: git-mail-commits (Re:What's a good setup for submitting patches to the list properly?)
From: Nicolas Sebrecht @ 2009-08-25 0:14 UTC (permalink / raw)
To: Julian Phillips; +Cc: Nicolas Sebrecht, Christian Couder, Thell Fowler, git
In-Reply-To: <alpine.LNX.2.00.0908250102580.28400@reaper.quantumfyre.co.uk>
The 25/08/09, Julian Phillips wrote:
> On Mon, 24 Aug 2009, Nicolas Sebrecht wrote:
>
> > I think it worth. That said, I would first add some config options like
> > mail-commits.cc (not reviewed that much yet) to be a bit more consistent
> > with the send-email program. I would also add README and INSTALL files.
>
> Yeah ... it would be nice to have more options settable via config. Some
> form of documentation would also be a good idea, and I would like to tidy
> the code up a bit. Kinda sort on tuits just at the moment though ... :(
Will have help from me. I find it nice to have a python alternative to
send-email. ,-p
> > Could you please consider to place your code under GPLv2?
>
> I have added a license statement.
Thank you. Patches comming.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Nicolas Pitre @ 2009-08-25 0:18 UTC (permalink / raw)
To: Julian Phillips; +Cc: Daniel Barkalow, Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <alpine.LNX.2.00.0908242212260.26869@reaper.quantumfyre.co.uk>
On Mon, 24 Aug 2009, Julian Phillips wrote:
> On Mon, 24 Aug 2009, Daniel Barkalow wrote:
>
> > On Sun, 23 Aug 2009, Junio C Hamano wrote:
> >
> > > What is the point of not asking for the refs that we know are the same?
> >
> > This code is part of the original C implementation of fetch; I suspect the
> > optimization was somehow in the shell version and made sense there,
> > perhaps because there wasn't a quickfetch in the shell version or that
> > there was some non-negligable per-ref cost in the code around there, since
> > it was calling helper programs and such.
>
> I don't remember copying it from the shell version but my memory is terrible,
> so I could easily be wrong. The relevant commit message was:
>
> "git-fetch2: remove ref_maps that are not interesting
>
> Once we have the full list of ref_maps, remove any where the local
> and remote sha1s are the same - as we don't need to do anything for
> them."
>
> So that doesn't help. I was very concerned about performance though (which
> was why I wanted fetch in C in the first place), so may have added it to speed
> up fetches that have only updated a few refs - and I assume that quickfetch
> was something that came along later after you absorbed the work into the
> transport series?
Well... Johan Herland says he has to deal with repositories containing
around 50000 refs. So in that case it is certainly a good idea not to
send the whole 50000 refs back if only one or two (or a hundred) need to
be updated. And quickfetch() won't help in that case since its purpose
is only to determine if there is anything at all to update.
> > Anyway, I think it makes sense to remove the filtering from
> > transport_fetch_refs(), like your patch does.
> >
> > If it makes a difference for the actual protocol, fetch_refs_via_pack()
> > could filter them at that stage.
>
> I think it would certainly be worth investigating the performance aspects ...
> no time tonight, but maybe tomorrow.
50000 refs * 45 bytes each = 2.25 MB. That's all wasted bandwidth if
only one ref needs updating.
Nicolas
^ permalink raw reply
* Re: git-mail-commits (Re:What's a good setup for submitting patches to the list properly?)
From: Julian Phillips @ 2009-08-25 0:06 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Christian Couder, Thell Fowler, git
In-Reply-To: <20090823234108.GB3526@vidovic>
On Mon, 24 Aug 2009, Nicolas Sebrecht wrote:
> The 24/08/09, Julian Phillips wrote:
>> On Sun, 23 Aug 2009, Christian Couder wrote:
>>
>> Using the awsome power of git I have managed to extract it from my random
>> tools private repo to here as if I had written it to be a separate entity
>> from the start:
>>
>> git://git.q42.co.uk/mail_commits.git
>> (gitweb: http://git.q42.co.uk/w/mail_commits.git)
>
> Thanks a lot.
>
>> If it would be considered useful, then I can also create a patch to add
>> it to contrib
>
> I think it worth. That said, I would first add some config options like
> mail-commits.cc (not reviewed that much yet) to be a bit more consistent
> with the send-email program. I would also add README and INSTALL files.
Yeah ... it would be nice to have more options settable via config. Some
form of documentation would also be a good idea, and I would like to tidy
the code up a bit. Kinda sort on tuits just at the moment though ... :(
> Could you please consider to place your code under GPLv2?
I have added a license statement.
--
Julian
---
Thus spake the master programmer:
"When a program is being tested, it is too late to make design changes."
-- Geoffrey James, "The Tao of Programming"
^ permalink raw reply
* Re: Possible regression: overwriting untracked files in a fresh repo
From: Junio C Hamano @ 2009-08-24 23:20 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20090824190710.GB25168@coredump.intra.peff.net>
reset_tree() is used from two places in checkout.
(1) When --force is given, to reset potentially unmerged state away and
forcibly switch to the destination branch. We do an equivalent of
"reset --hard";
(2) When switching from a dirty work tree using --merge, we first write
out the current index + any local changes in the work tree as a tree
object (thus ensuring that the index is merged at this point), and
then switch forcibly to the new branch by calling the function.
After switching to the new branch, we merge the difference between
the old commit and the tree that represents the dirty work tree,
but then reset the index to the new branch.
The "checking out a real branch from an unborn branch" codepath was
reusing codepath for (1), essentially doing "reset --hard new". This of
course allows any work tree cruft that gets in the way removed.
The patch changes it not to force, but adds another call style for the
reset_tree() function that does not do the hard reset, and uses it when
you are switching from an unborn branch (or a broken one).
I do not think that this is the correct fix, but it should be a good start
for other people to take a look at the issue. With this change, any
leftover work tree files will remain, but it has an interesting effect.
$ git checkout maint
$ echo 'ref: refs/heads/nosuch' >.git/HEAD
$ git checkout -b foo master
You will notice that the index matches master (as expected), but the work
tree mostly matches maint. Knowing what these files are (i.e. "these are
git.git source files that match 'maint' branch, and are vastly behind what
are in 'master' branch we are switching to"), this result is utterly
counterintuitive and feels wrong, but if you consider a case like what
Dscho brought up originally in the thread of having a freshly initialized
empty repository with some uncommitted files, totally unrelated to what
you are checking out, I think you could argue that it is the right thing.
I dunno.
builtin-checkout.c | 14 ++++++++------
1 files changed, 8 insertions(+), 6 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 8a9a474..2930bd6 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -309,16 +309,17 @@ static void describe_detached_head(char *msg, struct commit *commit)
strbuf_release(&sb);
}
-static int reset_tree(struct tree *tree, struct checkout_opts *o, int worktree)
+static int reset_tree(struct tree *tree, struct checkout_opts *o, int flags)
{
struct unpack_trees_options opts;
struct tree_desc tree_desc;
+ int worktree = !!(flags & 01);
memset(&opts, 0, sizeof(opts));
opts.head_idx = -1;
opts.update = worktree;
opts.skip_unmerged = !worktree;
- opts.reset = 1;
+ opts.reset = !(flags & 02);
opts.merge = 1;
opts.fn = oneway_merge;
opts.verbose_update = !o->quiet;
@@ -373,6 +374,10 @@ static int merge_working_tree(struct checkout_opts *opts,
ret = reset_tree(new->commit->tree, opts, 1);
if (ret)
return ret;
+ } else if (!old->commit) {
+ ret = reset_tree(new->commit->tree, opts, 2);
+ if (ret)
+ return ret;
} else {
struct tree_desc trees[2];
struct tree *tree;
@@ -542,11 +547,8 @@ static int switch_branches(struct checkout_opts *opts, struct branch_info *new)
}
if (!old.commit && !opts->force) {
- if (!opts->quiet) {
+ if (!opts->quiet)
warning("You appear to be on a branch yet to be born.");
- warning("Forcing checkout of %s.", new->name);
- }
- opts->force = 1;
}
ret = merge_working_tree(opts, &old, new);
^ permalink raw reply related
* Re: git list binary and/or non-binary files?
From: skillzero @ 2009-08-24 22:39 UTC (permalink / raw)
To: Johan Herland; +Cc: git
In-Reply-To: <200908250014.03585.johan@herland.net>
On Mon, Aug 24, 2009 at 3:14 PM, Johan Herland<johan@herland.net> wrote:
> I use the following to list files that contain CRs, but that are not
> considered binary by Git:
>
> git grep --cached -I -l -e $'\r'
Thanks, that's what I needed. I needed it to build a list to pass to a
script so I used 'git grep -I --name-only -z -e "" | xargs -o ...'
^ permalink raw reply
* Re: Possible regression: overwriting untracked files in a fresh repo
From: Junio C Hamano @ 2009-08-24 22:39 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, git
In-Reply-To: <20090824190710.GB25168@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> However, if I then do this:
>
> (cd parent && echo content >another && git add . && git commit -m more)
> (cd child && git fetch ../parent && git checkout -b new FETCH_HEAD)
>
> then it does complain. I'm guessing there is a different code path for
> the case that we have no index at all, and that it is not properly
> checking for overwrites.
I think it is this "opts->force = 1" done when you are on an unborn
branch.
if (!old.commit && !opts->force) {
if (!opts->quiet) {
warning("You appear to be on a branch yet to be born.");
warning("Forcing checkout of %s.", new->name);
}
opts->force = 1;
}
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Julian Phillips @ 2009-08-24 22:30 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Junio C Hamano, Nicolas Pitre, Johannes Schindelin, git
In-Reply-To: <alpine.LNX.2.00.0908240144530.28290@iabervon.org>
On Mon, 24 Aug 2009, Daniel Barkalow wrote:
> On Sun, 23 Aug 2009, Junio C Hamano wrote:
>
>> But it makes me wonder if this logic to filter refs is buying us anything.
>>
>>> for (rm = refs; rm; rm = rm->next) {
>>> + nr_refs++;
>>> if (rm->peer_ref &&
>>> !hashcmp(rm->peer_ref->old_sha1, rm->old_sha1))
>>> continue;
>> ALLOC_GROW(heads, nr_heads + 1, nr_alloc);
>> heads[nr_heads++] = rm;
>> }
>>
>> What is the point of not asking for the refs that we know are the same?
>
> This code is part of the original C implementation of fetch; I suspect the
> optimization was somehow in the shell version and made sense there,
> perhaps because there wasn't a quickfetch in the shell version or that
> there was some non-negligable per-ref cost in the code around there, since
> it was calling helper programs and such.
I don't remember copying it from the shell version but my memory is
terrible, so I could easily be wrong. The relevant commit message was:
"git-fetch2: remove ref_maps that are not interesting
Once we have the full list of ref_maps, remove any where the local
and remote sha1s are the same - as we don't need to do anything for
them."
So that doesn't help. I was very concerned about performance though
(which was why I wanted fetch in C in the first place), so may have added
it to speed up fetches that have only updated a few refs - and I assume
that quickfetch was something that came along later after you absorbed the
work into the transport series?
> Anyway, I think it makes sense to remove the filtering from
> transport_fetch_refs(), like your patch does.
>
> If it makes a difference for the actual protocol, fetch_refs_via_pack()
> could filter them at that stage.
I think it would certainly be worth investigating the performance aspects
... no time tonight, but maybe tomorrow.
--
Julian
---
Some circumstantial evidence is very strong, as when you find a trout in
the milk.
-- Thoreau
^ permalink raw reply
* Re: [PATCH] fix simple deepening of a repo
From: Junio C Hamano @ 2009-08-24 22:21 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Daniel Barkalow, Johannes Schindelin, git
In-Reply-To: <alpine.LFD.2.00.0908240946390.6044@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> If you really want to get rid of that filtering, I'd still do it in a
> separate patch. That way if any issue appears because of that then
> bissection will point directly to that removal alone.
Fair enough.
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-24 22:17 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Nanako Shiraishi, Thell Fowler, git, Johannes.Schindelin
In-Reply-To: <20090824071711.GE3526@vidovic>
Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
> ... But isn't the following mark a bit
> too much permissive?
>
> ->8
Yeah, I agree that we should require a bit longer perforation, and perhaps
we should tighten the rules a bit, while at the same time not limiting the
request to cut to the exact phrase "cut here". As you pointed out, we do
not want to be too lenient to allow misidentification, but at the same
time it is nicer to be accomodating and treat something like this as a
scissors line:
- - - >8 - - - remove everything above this line - - - >8 - - -
I think we have bikeshedded long enough, so I won't be touching this code
any further only to change the definition of what a scissors mark looks
like, but here is what I did during lunch break, with another comment
added later to hint what s_hdr_data[] stands for after reading response
from Don Zickus.
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Subject: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
This teaches mailinfo the scissors -- >8 -- mark; the command ignores
everything before it in the message body.
For lefties among us, we also support -- 8< -- ;-)
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-mailinfo.c | 71 ++++++++++++++++++++++++++++++++++++++++-
t/t5100-mailinfo.sh | 2 +-
t/t5100/info0014 | 5 +++
t/t5100/msg0014 | 4 ++
t/t5100/patch0014 | 64 ++++++++++++++++++++++++++++++++++++
t/t5100/sample.mbox | 89 +++++++++++++++++++++++++++++++++++++++++++++++++++
6 files changed, 233 insertions(+), 2 deletions(-)
create mode 100644 t/t5100/info0014
create mode 100644 t/t5100/msg0014
create mode 100644 t/t5100/patch0014
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index b0b5d8f..7e09b51 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -712,6 +712,56 @@ static inline int patchbreak(const struct strbuf *line)
return 0;
}
+static int is_scissors_line(const struct strbuf *line)
+{
+ size_t i, len = line->len;
+ int scissors = 0, gap = 0;
+ int first_nonblank = -1;
+ int last_nonblank = 0, visible, perforation, in_perforation = 0;
+ const char *buf = line->buf;
+
+ for (i = 0; i < len; i++) {
+ if (isspace(buf[i])) {
+ if (in_perforation) {
+ perforation++;
+ gap++;
+ }
+ continue;
+ }
+ last_nonblank = i;
+ if (first_nonblank < 0)
+ first_nonblank = i;
+ if (buf[i] == '-') {
+ in_perforation = 1;
+ perforation++;
+ continue;
+ }
+ if (i + 1 < len &&
+ (!memcmp(buf + i, ">8", 2) || !memcmp(buf + i, "8<", 2))) {
+ in_perforation = 1;
+ perforation += 2;
+ scissors += 2;
+ i++;
+ continue;
+ }
+ in_perforation = 0;
+ }
+
+ /*
+ * The mark must be at least 8 bytes long (e.g. "-- >8 --").
+ * Even though there can be arbitrary cruft on the same line
+ * (e.g. "cut here"), in order to avoid misidentification, the
+ * perforation must occupy more than a third of the visible
+ * width of the line, and dashes and scissors must occupy more
+ * than half of the perforation.
+ */
+
+ visible = last_nonblank - first_nonblank + 1;
+ return (scissors && 8 <= visible &&
+ visible < perforation * 3 &&
+ gap * 2 < perforation);
+}
+
static int handle_commit_msg(struct strbuf *line)
{
static int still_looking = 1;
@@ -723,7 +773,8 @@ static int handle_commit_msg(struct strbuf *line)
strbuf_ltrim(line);
if (!line->len)
return 0;
- if ((still_looking = check_header(line, s_hdr_data, 0)) != 0)
+ still_looking = check_header(line, s_hdr_data, 0);
+ if (still_looking)
return 0;
}
@@ -731,6 +782,24 @@ static int handle_commit_msg(struct strbuf *line)
if (metainfo_charset)
convert_to_utf8(line, charset.buf);
+ if (is_scissors_line(line)) {
+ int i;
+ rewind(cmitmsg);
+ ftruncate(fileno(cmitmsg), 0);
+ still_looking = 1;
+
+ /*
+ * We may have already read "secondary headers"; purge
+ * them to give ourselves a clean restart.
+ */
+ for (i = 0; header[i]; i++) {
+ if (s_hdr_data[i])
+ strbuf_release(s_hdr_data[i]);
+ s_hdr_data[i] = NULL;
+ }
+ return 0;
+ }
+
if (patchbreak(line)) {
fclose(cmitmsg);
cmitmsg = NULL;
diff --git a/t/t5100-mailinfo.sh b/t/t5100-mailinfo.sh
index e70ea94..e848556 100755
--- a/t/t5100-mailinfo.sh
+++ b/t/t5100-mailinfo.sh
@@ -11,7 +11,7 @@ test_expect_success 'split sample box' \
'git mailsplit -o. "$TEST_DIRECTORY"/t5100/sample.mbox >last &&
last=`cat last` &&
echo total is $last &&
- test `cat last` = 13'
+ test `cat last` = 14'
for mail in `echo 00*`
do
diff --git a/t/t5100/info0014 b/t/t5100/info0014
new file mode 100644
index 0000000..ab9c8d0
--- /dev/null
+++ b/t/t5100/info0014
@@ -0,0 +1,5 @@
+Author: Junio C Hamano
+Email: gitster@pobox.com
+Subject: Teach mailinfo to ignore everything before -- >8 -- mark
+Date: Thu, 20 Aug 2009 17:18:22 -0700
+
diff --git a/t/t5100/msg0014 b/t/t5100/msg0014
new file mode 100644
index 0000000..259c6a4
--- /dev/null
+++ b/t/t5100/msg0014
@@ -0,0 +1,4 @@
+This teaches mailinfo the scissors -- >8 -- mark; the command ignores
+everything before it in the message body.
+
+Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/t/t5100/patch0014 b/t/t5100/patch0014
new file mode 100644
index 0000000..124efd2
--- /dev/null
+++ b/t/t5100/patch0014
@@ -0,0 +1,64 @@
+---
+ builtin-mailinfo.c | 37 ++++++++++++++++++++++++++++++++++++-
+ 1 files changed, 36 insertions(+), 1 deletions(-)
+
+diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
+index b0b5d8f..461c47e 100644
+--- a/builtin-mailinfo.c
++++ b/builtin-mailinfo.c
+@@ -712,6 +712,34 @@ static inline int patchbreak(const struct strbuf *line)
+ return 0;
+ }
+
++static int scissors(const struct strbuf *line)
++{
++ size_t i, len = line->len;
++ int scissors_dashes_seen = 0;
++ const char *buf = line->buf;
++
++ for (i = 0; i < len; i++) {
++ if (isspace(buf[i]))
++ continue;
++ if (buf[i] == '-') {
++ scissors_dashes_seen |= 02;
++ continue;
++ }
++ if (i + 1 < len && !memcmp(buf + i, ">8", 2)) {
++ scissors_dashes_seen |= 01;
++ i++;
++ continue;
++ }
++ if (i + 7 < len && !memcmp(buf + i, "cut here", 8)) {
++ i += 7;
++ continue;
++ }
++ /* everything else --- not scissors */
++ break;
++ }
++ return scissors_dashes_seen == 03;
++}
++
+ static int handle_commit_msg(struct strbuf *line)
+ {
+ static int still_looking = 1;
+@@ -723,10 +751,17 @@ static int handle_commit_msg(struct strbuf *line)
+ strbuf_ltrim(line);
+ if (!line->len)
+ return 0;
+- if ((still_looking = check_header(line, s_hdr_data, 0)) != 0)
++ still_looking = check_header(line, s_hdr_data, 0);
++ if (still_looking)
+ return 0;
+ }
+
++ if (scissors(line)) {
++ fseek(cmitmsg, 0L, SEEK_SET);
++ still_looking = 1;
++ return 0;
++ }
++
+ /* normalize the log message to UTF-8. */
+ if (metainfo_charset)
+ convert_to_utf8(line, charset.buf);
+--
+1.6.4.1
diff --git a/t/t5100/sample.mbox b/t/t5100/sample.mbox
index c3074ac..13fa4ae 100644
--- a/t/t5100/sample.mbox
+++ b/t/t5100/sample.mbox
@@ -561,3 +561,92 @@ From: <a.u.thor@example.com> (A U Thor)
Date: Fri, 9 Jun 2006 00:44:16 -0700
Subject: [PATCH] a patch
+From nobody Mon Sep 17 00:00:00 2001
+From: Junio Hamano <junkio@cox.net>
+Date: Thu, 20 Aug 2009 17:18:22 -0700
+Subject: Why doesn't git-am does not like >8 scissors mark?
+
+Subject: [PATCH] BLAH ONE
+
+In real life, we will see a discussion that inspired this patch
+discussing related and unrelated things around >8 scissors mark
+in this part of the message.
+
+Subject: [PATCH] BLAH TWO
+
+And then we will see the scissors.
+
+ This line is not a scissors mark -- >8 -- but talks about it.
+ - - >8 - - please remove everything above this line - - >8 - -
+
+Subject: [PATCH] Teach mailinfo to ignore everything before -- >8 -- mark
+From: Junio C Hamano <gitster@pobox.com>
+
+This teaches mailinfo the scissors -- >8 -- mark; the command ignores
+everything before it in the message body.
+
+Signed-off-by: Junio C Hamano <gitster@pobox.com>
+---
+ builtin-mailinfo.c | 37 ++++++++++++++++++++++++++++++++++++-
+ 1 files changed, 36 insertions(+), 1 deletions(-)
+
+diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
+index b0b5d8f..461c47e 100644
+--- a/builtin-mailinfo.c
++++ b/builtin-mailinfo.c
+@@ -712,6 +712,34 @@ static inline int patchbreak(const struct strbuf *line)
+ return 0;
+ }
+
++static int scissors(const struct strbuf *line)
++{
++ size_t i, len = line->len;
++ int scissors_dashes_seen = 0;
++ const char *buf = line->buf;
++
++ for (i = 0; i < len; i++) {
++ if (isspace(buf[i]))
++ continue;
++ if (buf[i] == '-') {
++ scissors_dashes_seen |= 02;
++ continue;
++ }
++ if (i + 1 < len && !memcmp(buf + i, ">8", 2)) {
++ scissors_dashes_seen |= 01;
++ i++;
++ continue;
++ }
++ if (i + 7 < len && !memcmp(buf + i, "cut here", 8)) {
++ i += 7;
++ continue;
++ }
++ /* everything else --- not scissors */
++ break;
++ }
++ return scissors_dashes_seen == 03;
++}
++
+ static int handle_commit_msg(struct strbuf *line)
+ {
+ static int still_looking = 1;
+@@ -723,10 +751,17 @@ static int handle_commit_msg(struct strbuf *line)
+ strbuf_ltrim(line);
+ if (!line->len)
+ return 0;
+- if ((still_looking = check_header(line, s_hdr_data, 0)) != 0)
++ still_looking = check_header(line, s_hdr_data, 0);
++ if (still_looking)
+ return 0;
+ }
+
++ if (scissors(line)) {
++ fseek(cmitmsg, 0L, SEEK_SET);
++ still_looking = 1;
++ return 0;
++ }
++
+ /* normalize the log message to UTF-8. */
+ if (metainfo_charset)
+ convert_to_utf8(line, charset.buf);
+--
+1.6.4.1
--
1.6.4.1
^ permalink raw reply related
* Re: git list binary and/or non-binary files?
From: Johan Herland @ 2009-08-24 22:14 UTC (permalink / raw)
To: git; +Cc: skillzero
In-Reply-To: <2729632a0908241450m1651c77ata9744058c5d42672@mail.gmail.com>
On Monday 24 August 2009, skillzero@gmail.com wrote:
> Is there a way to list the files git considers binary in a repository
> (and alternatively, the ones it considers text)? I have a large
> repository and I want to fix line endings for text files that were
> accidentally checked in using CRLF and can't just use the file
> extension alone because some files with the same extension may be
> binary and others not (e.g. UTF-8 .strings file is text, but a UTF-16
> .strings file is binary...git already figured out based on the content
> that one is binary).
>
> I thought maybe git ls-files, but I didn't see anything in there I can
> use for binary vs text.
I use the following to list files that contain CRs, but that are not
considered binary by Git:
git grep --cached -I -l -e $'\r'
'git help grep' explains all the options...
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Junio C Hamano @ 2009-08-24 22:03 UTC (permalink / raw)
To: Brandon Casey; +Cc: Nicolas Pitre, git
In-Reply-To: <YE4QMh4rA1r2X3ZG5TvGJZspm0UdCWyP-r6KFthp8PuFewAhHPJ3GQ@cipher.nrlssc.navy.mil>
Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:
> Nicolas is right, the code compiles and executes correctly on Solaris as-is.
>
> Here is the state of the two unsubmitted optimization patches:
>
> 1) Change things like __i386__ to __i386 since GCC defines both, but
> SUNWspro only defines __i386.
>
> This works correctly in my testing. I'm assuming that a test for
> __amd64 is not necessary and expect that __x86_64 is set whenever
> __amd64 is set.
>
> 2) Set __GNUC__ on SUNWspro v5.10 and up.
>
> This compiles correctly and passes the test suite, but produces
> warnings for __attribute__'s that sun's compiler has not implemented.
> This produces a very noisy compile.
>
> I've wanted to do some performance testing to see whether this actually
> produces an _improvement_. I'll try today.
Thanks.
I agree (1) would be a reasonable thing to do.
(2) feels very iffy/hacky. As far as I can see, by defining __GNUC__,
Solaris would also use builtin-alloca in compat/regex/regex.c, which may
or may not be what you want.
It might be cleaner to do:
#if __GNUC__ || SUNWspro > 5.10
#define GCC_LIKE_INLINE_ASM
#define GCC_LIKE_STMT_EXPR
#endif
and use them, instead of __GNUC__, to enable the inline assembly used in
the block sha1 codepath.
^ permalink raw reply
* git list binary and/or non-binary files?
From: skillzero @ 2009-08-24 21:50 UTC (permalink / raw)
To: git
Is there a way to list the files git considers binary in a repository
(and alternatively, the ones it considers text)? I have a large
repository and I want to fix line endings for text files that were
accidentally checked in using CRLF and can't just use the file
extension alone because some files with the same extension may be
binary and others not (e.g. UTF-8 .strings file is text, but a UTF-16
.strings file is binary...git already figured out based on the content
that one is binary).
I thought maybe git ls-files, but I didn't see anything in there I can
use for binary vs text.
^ permalink raw reply
* Re: [PATCH] Re: Teach mailinfo to ignore everything before -- >8 -- mark
From: Junio C Hamano @ 2009-08-24 21:48 UTC (permalink / raw)
To: Don Zickus
Cc: Nicolas Sebrecht, Junio C Hamano, Thell Fowler, Nanako Shiraishi,
git, Johannes.Schindelin
In-Reply-To: <20090824140223.GA22198@redhat.com>
Don Zickus <dzickus@redhat.com> writes:
> From what I remember, I used p_hdr to designate primary headers, ie the
> original mail headers. s_hdr was supposed to represent the secondary
> headers, ie the embedded mail headers in the body of the email that could
> override the original primary mail headers.
Ah, p for primary and s for secondary. Now it makes sense.
Thanks.
^ permalink raw reply
* Re: bundles with multiple branches
From: Adam Brewster @ 2009-08-24 21:42 UTC (permalink / raw)
To: Jeffrey Ratcliffe; +Cc: git
In-Reply-To: <30e395780908231404k7240dbacu5c258d9816e35dd7@mail.gmail.com>
>
> 2009/8/23 Adam Brewster <adambrewster@gmail.com>:
>> git remote add bundle /media/cdrom
>> git config --replace-all remotes.bundle.fetch refs/heads/*:refs/remotes/bundle/*
>> git config --add remotes.bundle.fetch refs/remotes/*:refs/remotes/*
>
> On
>
> $ git pull bundle
>
> or
>
> $ git fetch bundle
>
> I get
>
> fatal: '/media/cdrom': unable to chdir or not a git archive
> fatal: The remote end hung up unexpectedly
>
Sorry, that's supposed to be /media/cdrom/name-of-bundle
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #04; Sun, 23)
From: Brandon Casey @ 2009-08-24 21:29 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.LFD.2.00.0908232117460.6044@xanadu.home>
Nicolas Pitre wrote:
> On Sun, 23 Aug 2009, Junio C Hamano wrote:
>
>> * lt/block-sha1 (2009-08-17) 4 commits
>> (merged to 'next' on 2009-08-18 at 67a1ce8)
>> + remove ARM and Mozilla SHA1 implementations
>> + block-sha1: guard gcc extensions with __GNUC__
>> + make sure byte swapping is optimal for git
>> + block-sha1: make the size member first in the context struct
>>
>> Finishing touches ;-) There were a few Solaris portability patches
>> floated around that I didn't pick up, waiting for them to finalize.
>
> Those would be described better as Solaris _optimization_ patches. The
> code is already fully portable as it is, except not necessarily optimal
> in some cases.
Nicolas is right, the code compiles and executes correctly on Solaris as-is.
Here is the state of the two unsubmitted optimization patches:
1) Change things like __i386__ to __i386 since GCC defines both, but
SUNWspro only defines __i386.
This works correctly in my testing. I'm assuming that a test for
__amd64 is not necessary and expect that __x86_64 is set whenever
__amd64 is set.
2) Set __GNUC__ on SUNWspro v5.10 and up.
This compiles correctly and passes the test suite, but produces
warnings for __attribute__'s that sun's compiler has not implemented.
This produces a very noisy compile.
I've wanted to do some performance testing to see whether this actually
produces an _improvement_. I'll try today.
-brandon
^ permalink raw reply
* [PATCH] Add option -b/--branch to clone for select a new HEAD
From: Kirill A. Korinskiy @ 2009-08-24 20:42 UTC (permalink / raw)
To: gitster; +Cc: git, Kirill A. Korinskiy
Sometimes (especially on production systems) we need to use only one
remote branch for building software. It really annoying to clone
origin and then swith branch by hand everytime. So this patch provide
functionality to clone remote branch with one command without using
checkout after clone.
---
Documentation/git-clone.txt | 4 ++++
builtin-clone.c | 26 +++++++++++++++++++++++---
2 files changed, 27 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 2c63a0f..50446d2 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -127,6 +127,10 @@ objects from the source repository into a pack in the cloned repository.
Instead of using the remote name 'origin' to keep track
of the upstream repository, use <name>.
+--branch <name>::
+-b <name>::
+ Instead of using the remote HEAD as master, use <name> branch.
+
--upload-pack <upload-pack>::
-u <upload-pack>::
When given, and the repository to clone from is accessed
diff --git a/builtin-clone.c b/builtin-clone.c
index 32dea74..4420c68 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -41,6 +41,7 @@ static int option_quiet, option_no_checkout, option_bare, option_mirror;
static int option_local, option_no_hardlinks, option_shared;
static char *option_template, *option_reference, *option_depth;
static char *option_origin = NULL;
+static char *option_branch = NULL;
static char *option_upload_pack = "git-upload-pack";
static int option_verbose;
@@ -65,6 +66,8 @@ static struct option builtin_clone_options[] = {
"reference repository"),
OPT_STRING('o', "origin", &option_origin, "branch",
"use <branch> instead of 'origin' to track upstream"),
+ OPT_STRING('b', "branch", &option_branch, "branch",
+ "use <branch> from 'origin' as HEAD"),
OPT_STRING('u', "upload-pack", &option_upload_pack, "path",
"path to git-upload-pack on the remote"),
OPT_STRING(0, "depth", &option_depth, "depth",
@@ -347,8 +350,8 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
const char *repo_name, *repo, *work_tree, *git_dir;
char *path, *dir;
int dest_exists;
- const struct ref *refs, *head_points_at, *remote_head, *mapped_refs;
- struct strbuf key = STRBUF_INIT, value = STRBUF_INIT;
+ const struct ref *refs, *head_points_at, *remote_head = NULL, *mapped_refs;
+ struct strbuf key = STRBUF_INIT, value = STRBUF_INIT, branch_head = STRBUF_INIT;
struct strbuf branch_top = STRBUF_INIT, reflog_msg = STRBUF_INIT;
struct transport *transport = NULL;
char *src_ref_prefix = "refs/heads/";
@@ -372,6 +375,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
if (option_origin)
die("--bare and --origin %s options are incompatible.",
option_origin);
+ if (option_branch)
+ die("--bare and --branch %s options are incompatible.",
+ option_branch);
option_no_checkout = 1;
}
@@ -518,7 +524,21 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
mapped_refs = write_remote_refs(refs, refspec, reflog_msg.buf);
- remote_head = find_ref_by_name(refs, "HEAD");
+ if (option_branch) {
+ strbuf_addf(&branch_head, "%s%s", src_ref_prefix, option_branch);
+
+ remote_head = find_ref_by_name(refs, branch_head.buf);
+ }
+
+ if (!remote_head) {
+ if (option_branch)
+ warning("Remote branch %s not found in upstream %s"
+ ", using HEAD instead",
+ option_branch, option_origin);
+
+ remote_head = find_ref_by_name(refs, "HEAD");
+ }
+
head_points_at = guess_remote_head(remote_head, mapped_refs, 0);
}
else {
--
1.6.2
^ permalink raw reply related
* [PATCH v4 4/4] fast-import: test the new option command
From: Sverre Rabbelier @ 2009-08-24 20:52 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List
Cc: Sverre Rabbelier
In-Reply-To: <1251147156-19279-4-git-send-email-srabbelier@gmail.com>
Test three options (quiet and import/export-marks) and verify that the
commandline options override these.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Unchanged from v3.
t/t9300-fast-import.sh | 58 ++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/t/t9300-fast-import.sh b/t/t9300-fast-import.sh
index 821be7c..62369e5 100755
--- a/t/t9300-fast-import.sh
+++ b/t/t9300-fast-import.sh
@@ -1088,4 +1088,62 @@ INPUT_END
test_expect_success 'P: fail on blob mark in gitlink' '
test_must_fail git fast-import <input'
+###
+### series Q (options)
+###
+
+cat >input << EOF
+option quiet
+blob
+data 3
+hi
+
+EOF
+
+touch empty
+
+test_expect_success 'Q: quiet option results in no stats being output' '
+ cat input | git fast-import 2> output &&
+ test_cmp empty output
+'
+
+cat >input << EOF
+option export-marks=git.marks
+blob
+mark :1
+data 3
+hi
+
+EOF
+
+test_expect_success \
+ 'Q: export-marks option results in a marks file being created' \
+ 'cat input | git fast-import &&
+ grep :1 git.marks'
+
+test_expect_success \
+ 'Q: export-marks options can be overriden by commandline options' \
+ 'cat input | git fast-import --export-marks=other.marks &&
+ grep :1 other.marks'
+
+cat >input << EOF
+option import-marks=marks.out
+option export-marks=marks.new
+EOF
+
+test_expect_success \
+ 'Q: import to output marks works without any content' \
+ 'cat input | git fast-import &&
+ test_cmp marks.out marks.new'
+
+cat >input <<EOF
+option import-marks=nonexistant.marks
+option export-marks=marks.new
+EOF
+
+test_expect_success \
+ 'Q: import marks uses the commandline marks file when the stream specifies one' \
+ 'cat input | git fast-import --import-marks=marks.out &&
+ test_cmp marks.out marks.new'
+
test_done
--
1.6.4.16.g72c66.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