* Re: [PATCH v2] Test t5560: Fix test when run with dash
From: Johannes Sixt @ 2010-01-15 19:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tarmigan Casebolt, Michael Haggerty, git, Shawn O. Pearce
In-Reply-To: <7vljfzz0yd.fsf@alter.siamese.dyndns.org>
On Freitag, 15. Januar 2010, Junio C Hamano wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
> > Tarmigan Casebolt schrieb:
> >> REQUEST_METHOD="GET" some_shell_function
> >>
> >> I can't tell from my reading of the POSIX spec whether my usage was
> >> wrong or if dash is wrong,
> >
> > According to POSIX, variables set as shown above for shell functions are
> > not exported and retain their value after the function returns.
>
> I actually looked for this yesterday, but didn't find a relevant
> definition. But "2.9.5 Function Definition Command" [*1*] seems to
> address the issue: "When a function is executed, it shall have the
> syntax-error and variable-assignment properties described for special
> built-in utilities...".
>
> And "2.14 Special Built-in Utilities" section [*2*] says "2. Variable
> assignments specified with special built-in utilities remain in effect
> after the built-in completes...". Taking both together, it seems that
> the assignment should be in effect after the function returns.
>
> Does my reading match yours,
These are exactly the definitions that I meant. The statement that variables
are not exported is in "2.9.1 Simple Commands"
http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_01
"[If there is a command name], the variable assignments shall be exported for
the execution environment of the command and shall not affect the current
execution environment (except for special built-ins)."
> Yesterday, I saw rebase--interactive has a few codepaths where "output"
> shell function was used with the single-shot export; perhaps they need to
> also be fixed.
I knew these spots, and they were discussed when that code was introduced.
Before I sent out the mail you were responding to, I tried various ways to
show the failure in rebase--interactive, but it didn't fail...
-- Hannes
^ permalink raw reply
* Re: [RFC] Git Wiki Move
From: Johannes Schindelin @ 2010-01-15 19:16 UTC (permalink / raw)
To: Joey Hess; +Cc: git
In-Reply-To: <20100115171752.GA8182@gnu.kitenet.net>
Hi,
On Fri, 15 Jan 2010, Joey Hess wrote:
> Petr Baudis wrote:
> > (ii) Also, I personally think MediaWiki is so much nicer than
> > ikiwiki...
>
> This seems like a non-sequitor, since the git wiki is not using, and
> afaik, has never used ikiwiki.
It was using MoinMoin, but of course there were thoughts of migrating to
something that uses Git as a backend.
This comment is most likely Pasky's attempt to explain why this is not
going to happen, and I agree with the decision (not that I have much say
there).
Ciao,
Dscho
^ permalink raw reply
* Re: git clone against firewall
From: Sebastian Pipping @ 2010-01-15 19:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vzl4fz0zb.fsf@alter.siamese.dyndns.org>
On 01/15/10 19:17, Junio C Hamano wrote:
> What do you exactly mean by "blocking"?
I chose "BLOCK always" as action for that port in my home router
(Netgear ProSafe 802.11g) config. No idea how it's exactly doing that.
> I am guessing that you can resolve the hostname in your environment
> (i.e. you configured your NAT to let DNS go directly outside).
Name resolution works, yes.
> What
> happens when you try the following?
>
> $ telnet git.overlays.gentoo.org 9418
>
> Do you get:
>
> Trying 66.219.59.40...
> telnet: Unable to connect to remote host: Connection refused
>
> If you get something like:
>
> Trying 66.219.59.40...
> Connected to pelican.gentoo.org.
> Escape character is '^]'.
>
> then I don't think you are blocked, and if that is the case, there is not
> much we can do about it.
I get a loop/freeze on
Trying 66.219.59.40...
nothing more. Can you deduce from that, what's happening?
> I think your firewall can help, though, by not pretending to be allowing
> the connection and then blocking you halfway.
I'm afraid I cannot configure that.
Sebastian
^ permalink raw reply
* Re: [PATCH] git push --track
From: Miles Bader @ 2010-01-15 18:54 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Rudolf Polzer, Tay Ray Chuan, git
In-Reply-To: <7vska7z0yp.fsf@alter.siamese.dyndns.org>
On Sat, Jan 16, 2010 at 3:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> And it doesn't add --track to the UI.
>>
>> That's not a positive...
>
> Oh, that is definitely a *HUGE* plus. I wouldn't go so far as to say that
> the word --track was a mistake. But the thing is, unfortunately it has
> already been contaminated by people using it in two completely different
> ways and ended up confusing new people. Some use it to mean "this branch
> forked off of and builds on top of", and others use it to mean "this ref
> holds a copy for reference purposes".
Then the right thing to do is to rename existing uses of --track so
that they're not confusing. Much-wanted functionality should not be
rejected simply because of an earlier mistake which is essentially
orthogonal to it, and which can be corrected easily enough.
So let's just say we're discussing the semantics, and it will use
another option name, which will be then retrofitted to other similar
uses for consistency (as should surely be done regardless of what
happens with this command):
git push --GRUBBLENUT
-Miles
--
Do not taunt Happy Fun Ball.
^ permalink raw reply
* Re: [PATCH] Add push --set-upstream
From: Junio C Hamano @ 2010-01-15 18:19 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1263573407-13642-1-git-send-email-ilari.liusvaara@elisanet.fi>
Very competently done. Will look forward to see the conclusion of the
follow-up discussions I haven't read but see in my mailreader.
Thanks.
^ permalink raw reply
* Re: [PATCH v2] Test t5560: Fix test when run with dash
From: Junio C Hamano @ 2010-01-15 18:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Tarmigan Casebolt, Michael Haggerty, git, Shawn O. Pearce
In-Reply-To: <4B5027B8.2090507@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Tarmigan Casebolt schrieb:
>> REQUEST_METHOD="GET" some_shell_function
>
>> I can't tell from my reading of the POSIX spec whether my usage was
>> wrong or if dash is wrong,
>
> According to POSIX, variables set as shown above for shell functions are
> not exported and retain their value after the function returns.
I actually looked for this yesterday, but didn't find a relevant
definition. But "2.9.5 Function Definition Command" [*1*] seems to
address the issue: "When a function is executed, it shall have the
syntax-error and variable-assignment properties described for special
built-in utilities...".
And "2.14 Special Built-in Utilities" section [*2*] says "2. Variable
assignments specified with special built-in utilities remain in effect
after the built-in completes...". Taking both together, it seems that
the assignment should be in effect after the function returns.
Does my reading match yours, or do you have more definitive descriptions
you can point at in POSIX.1, so that the log message can be improved to
help people avoid this issue in the future?
Yesterday, I saw rebase--interactive has a few codepaths where "output"
shell function was used with the single-shot export; perhaps they need to
also be fixed.
[References]
*1* http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_09_05
*2* http://www.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html#tag_18_14
^ permalink raw reply
* Re: [PATCH] git push --track
From: Junio C Hamano @ 2010-01-15 18:18 UTC (permalink / raw)
To: Miles Bader; +Cc: Rudolf Polzer, Tay Ray Chuan, git
In-Reply-To: <87y6k06wgz.fsf@catnip.gol.com>
Miles Bader <miles@gnu.org> writes:
>> And it doesn't add --track to the UI.
>
> That's not a positive...
Oh, that is definitely a *HUGE* plus. I wouldn't go so far as to say that
the word --track was a mistake. But the thing is, unfortunately it has
already been contaminated by people using it in two completely different
ways and ended up confusing new people. Some use it to mean "this branch
forked off of and builds on top of", and others use it to mean "this ref
holds a copy for reference purposes".
^ permalink raw reply
* Re: git clone against firewall
From: Junio C Hamano @ 2010-01-15 18:17 UTC (permalink / raw)
To: Sebastian Pipping; +Cc: git
In-Reply-To: <4B4FACB1.2080902@hartwork.org>
Sebastian Pipping <webmaster@hartwork.org> writes:
> with a firewall blocking outgoing connections to port 9418 a
>
> git clone git://...
>
> of git 1.6.6 seems to never return, i.e. loop forever. in my rather
> automated environment (gentoo's tool layman calling git) this behavior
> is rather troublesome - i need some kind of abort-and-error instead:
> what i'm trying to do is loop over a number of clone URL alternatives of
> the same repository like ..
>
> git://git.overlays.gentoo.org/dev/dberkholz.git
What do you exactly mean by "blocking"?
In my environment at work, there is a firewall and I immedately get this:
$ git clone git://git.overlays.gentoo.org/dev/dberkholz.git/
Initialized empty Git repository in /var/tmp/dberkholz/.git/
fatal: Unable to look up git.overlays.gentoo.org (port 9418) (Name or service not known)
as my environment is quite isolated (it is not just a "NAT with selective
port blocking").
I am guessing that you can resolve the hostname in your environment
(i.e. you configured your NAT to let DNS go directly outside). What
happens when you try the following?
$ telnet git.overlays.gentoo.org 9418
Do you get:
Trying 66.219.59.40...
telnet: Unable to connect to remote host: Connection refused
If you get something like:
Trying 66.219.59.40...
Connected to pelican.gentoo.org.
Escape character is '^]'.
then I don't think you are blocked, and if that is the case, there is not
much we can do about it.
I think your firewall can help, though, by not pretending to be allowing
the connection and then blocking you halfway.
^ permalink raw reply
* Re: Gitignore matching "git add" wildcard prevents operation
From: Junio C Hamano @ 2010-01-15 18:17 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Jeff King, Junio C Hamano, Marko Poutiainen, git
In-Reply-To: <20100115161107.GC12982@vidovic>
Nicolas Sebrecht <nicolas.s.dev@gmx.fr> writes:
>> My complaint was more that as a user, I am not likely to see this
>> problem and think "I'll bet git-specific globbing can solve it."
>
> Yes. My point is that we are not talking about a Git specific issue.
Actually it is. The thing is, git subcommands do *not* take individual
filenames in general from their command line. They _always_ take pathspecs,
find files in the work tree that match the pathspecs (but excludes ignored
ones), and work on them [*1*].
Other commands usually don't do that.
So "git add ." and "git add 'a.*'" behave exactly the same way. Both find
files that match their respective pathspecs. The former knows that "."
matches "all files that exist in the cwd (excluding ignored ones)" and the
latter knows that "a.*" matches "all files that fnmatch(3) 'a.*' glob
(excluding ignored ones)". Hence you will not get "don't try to add a
file that you said you want to ignore; use -f if you mean it".
[Footnote]
*1* There are exceptions, such as parameters to the "--file" option, and
"git blame".
^ permalink raw reply
* Re: [PATCH] git push --track
From: Junio C Hamano @ 2010-01-15 18:16 UTC (permalink / raw)
To: Rudolf Polzer; +Cc: git, Ilari Liusvaara
In-Reply-To: <20100115140048.GB30986@rm.endoftheinternet.org>
Rudolf Polzer <divVerent@alientrap.org> writes:
> On Thu, Jan 14, 2010 at 09:47:22PM -0800, Junio C Hamano wrote:
>> I have a feeling that it is more appropriate to have the additional code
>> in transport_push(), which gets ls-remote information, runs match_refs()
>> and finally calls transport->push_refs(). I think the extra branch
>> configuration would fit better inside the if block immediately after all
>> that happens, i.e.
>>
>> if (!(flags & TRANSPORT_PUSH_DRY_RUN)) {
>> struct ref *ref;
>> for (ref = remote_refs; ref; ref = ref->next)
>> update_tracking_ref(transport->remote, ref, verbose);
>> + if (flags & TRANSPORT_PUSH_RECONFIGURE_FORK)
>> + configure_forked_branch(...);
>> }
>>
>> in transport.c
>
> I thought about this place when making my patch, but didn't put it there
> because this function is not called in the rsync protocol (which defines
> transport->push).
That's not a very good reasoning. Instead of punishing well behaved
transport that defines push_ref, punish _only_ the transports that does
not define it (see the paragraph at the end of this message).
> But well. Why bother with this, if this feature was rejected before already
> anyway.
Read the thread Nana quoted for you again; I nor anybody ever _rejected_
the ultimate goal, even though I said that the justifications were not
sufficiently convincing for the previous implementation attempts.
I think Ilari's patch is done right and can be extended by anybody who
cares about rsync transport to call an extra ls-remote in the "does this
one lack push_ref but know how to push" codepath.
^ permalink raw reply
* Re: Filenames and prefixes in extended diffs
From: Junio C Hamano @ 2010-01-15 18:09 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20100115223259.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> The output from "git diff --no-index" is an exception to the above rule.
>> It is primarily for people who have unmanaged contents and want to use
>> features of the git diff engine that are not found in other people's diff
>> implementations (e.g. wordwise colored diff),...
>
> Is it possible to give --no-index option to "git grep", please?
Surely. And "grep" is much easier to do than "diff". Will send a patch
perhaps during my lunch break.
^ permalink raw reply
* Re: Gitignore matching "git add" wildcard prevents operation
From: Nicolas Sebrecht @ 2010-01-15 18:06 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Sebrecht, Junio C Hamano, Marko Poutiainen, git
In-Reply-To: <20100115163021.GA1947@coredump.intra.peff.net>
The 15/01/10, Jeff King wrote:
> On Fri, Jan 15, 2010 at 05:11:07PM +0100, Nicolas Sebrecht wrote:
>
> > > I don't understand what you mean. How does "sed" do its own globbing of
> > > the command line?
> >
> > Well, we are in the same dilemma as the other tools. The internal
> > globbing rules are explained in the related man page.
>
> Maybe I wasn't clear: to my knowledge, "sed" does not do any globbing
> itself.
"sed" does /pattern matching/ which is the meaning I give to /globbing/.
Sure, "sed" doesn't do /shell globbing/ but is fed from it. We obviously
agree here. :-)
> But that is not my complaint; my complaint was mainly that
> git's solution to this is not easily discoverable by an uninformed user.
I agree in that it is not easily discoverable. But I don't think Git's
solution is worse than any other tool. The "discoverabiliy" looks equal
to any other tool for me. As you said, to do a good job we should be
able to know what was the original command-line, which isn't possible.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH 3/3] difftool: Use eval to expand '--extcmd' expressions
From: David Aguilar @ 2010-01-15 17:59 UTC (permalink / raw)
To: Johannes Sixt; +Cc: gitster, git
In-Reply-To: <4B502A0C.50108@viscovery.net>
On Fri, Jan 15, 2010 at 09:40:44AM +0100, Johannes Sixt wrote:
> David Aguilar schrieb:
> > - $GIT_DIFFTOOL_EXTCMD "$LOCAL" "$REMOTE"
> > + (eval $GIT_DIFFTOOL_EXTCMD "\"$LOCAL\"" "\"$REMOTE\"")
>
> The new code is broken if $LOCAL or $REMOTE can contain double-quotes. How
> about this alternative:
>
> eval $GIT_DIFFTOOL_EXTCMD '"$LOCAL"' '"$REMOTE"'
>
> which I find more readable as well.
I'll resend a patch later today (can't quite right now, but will
have time later).
> What's the reason for the sub-shell? Do you want to protect from shell
> code in $GIT_DIFFTOOL_EXTCMD that modifies difftool's variables?
>
> -- Hannes
None, really, so we can do without that as well.
Thanks for your notes,
--
David
^ permalink raw reply
* Re: [PATCH] Add push --set-upstream
From: Jeff King @ 2010-01-15 17:42 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20100115171745.GB2115@coredump.intra.peff.net>
On Fri, Jan 15, 2010 at 12:17:45PM -0500, Jeff King wrote:
> The patch below is squash-able, but note that the final test, "git push
> -u HEAD" is marked as broken. We should probably support that. I suspect
> is is an issue of dereferencing symrefs before doing the
> prefixcmp("refs/heads/", ...) but I haven't checked yet.
The patch below fixes it, but I am not 100% happy with it. Calling
resolve_ref means we actually bother to look up the ref again, which is
wasted effort. The ref struct has a "symref" field which should contain
this information, but for some reason it is not recorded. So we can
probably do better by simply recording the information properly when we
resolve the ref in the first place.
Unfortunately, I don't have time to look at it anymore right now, so it
will have to wait.
diff --git a/t/t5523-push-upstream.sh b/t/t5523-push-upstream.sh
index e977553..d43473f 100755
--- a/t/t5523-push-upstream.sh
+++ b/t/t5523-push-upstream.sh
@@ -39,7 +39,7 @@ test_expect_success 'push -u --all' '
check_config all2 upstream refs/heads/all2
'
-test_expect_failure 'push -u HEAD' '
+test_expect_success 'push -u HEAD' '
git checkout -b headbranch &&
git push -u upstream HEAD &&
check_config headbranch upstream refs/heads/headbranch
diff --git a/transport.c b/transport.c
index 956d2ed..01ff364 100644
--- a/transport.c
+++ b/transport.c
@@ -140,6 +140,7 @@ static void set_upstreams(struct transport *trans, struct ref *refs)
{
struct ref *i;
for (i = refs; i; i = i->next) {
+ const char *branch;
/*
* Check suitability for tracking. Must be successful /
* alreay up-to-date ref create/modify (not delete) and
@@ -152,14 +153,20 @@ static void set_upstreams(struct transport *trans, struct ref *refs)
continue;
if (!i->new_sha1 || is_null_sha1(i->new_sha1))
continue;
- if (prefixcmp(i->peer_ref->name, "refs/heads/"))
- continue;
if (prefixcmp(i->name, "refs/heads/"))
continue;
+ if (!prefixcmp(i->peer_ref->name, "refs/heads/"))
+ branch = i->peer_ref->name;
+ else {
+ unsigned char sha1[20];
+ branch = resolve_ref(i->peer_ref->name, sha1, 1, NULL);
+ if (!branch || prefixcmp(branch, "refs/heads/"))
+ continue;
+ }
+
install_branch_config(BRANCH_CONFIG_VERBOSE,
- i->peer_ref->name + 11, trans->remote->name,
- i->name);
+ branch + 11, trans->remote->name, i->name);
}
}
^ permalink raw reply related
* Re: [RFC] Git Wiki Move
From: Joey Hess @ 2010-01-15 17:17 UTC (permalink / raw)
To: git
In-Reply-To: <20100114012449.GB3299@machine.or.cz>
[-- Attachment #1: Type: text/plain, Size: 288 bytes --]
Petr Baudis wrote:
> (ii) Also, I personally think MediaWiki is so much nicer than
> ikiwiki...
This seems like a non-sequitor, since the git wiki is not using, and
afaik, has never used ikiwiki.
--
see shy jo, author of ikiwiki, though not of its excellent git backend :-P
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [PATCH] Add push --set-upstream
From: Jeff King @ 2010-01-15 17:17 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1263573407-13642-1-git-send-email-ilari.liusvaara@elisanet.fi>
On Fri, Jan 15, 2010 at 06:36:47PM +0200, Ilari Liusvaara wrote:
> Frequent complaint is lack of easy way to set up upstream (tracking)
> references for git pull to work as part of push command. So add switch
> --set-upstream (-u) to do just that.
Huzzah, finally this feature is done right. I even like the name.
> Documentation/git-push.txt | 8 +++++++-
> builtin-push.c | 1 +
> transport.c | 35 +++++++++++++++++++++++++++++++++++
> transport.h | 1 +
> 4 files changed, 44 insertions(+), 1 deletions(-)
No tests. But since in writing this you have crossed an item off of my
long-term todo, I feel obliged to help out by providing some. :)
The patch below is squash-able, but note that the final test, "git push
-u HEAD" is marked as broken. We should probably support that. I suspect
is is an issue of dereferencing symrefs before doing the
prefixcmp("refs/heads/", ...) but I haven't checked yet.
diff --git a/t/t5523-push-upstream.sh b/t/t5523-push-upstream.sh
new file mode 100755
index 0000000..e977553
--- /dev/null
+++ b/t/t5523-push-upstream.sh
@@ -0,0 +1,48 @@
+#!/bin/sh
+
+test_description='push with --set-upstream'
+. ./test-lib.sh
+
+test_expect_success 'setup bare parent' '
+ git init --bare parent &&
+ git remote add upstream parent
+'
+
+test_expect_success 'setup local commit' '
+ echo content >file &&
+ git add file &&
+ git commit -m one
+'
+
+check_config() {
+ (echo $2; echo $3) >expect.$1
+ (git config branch.$1.remote
+ git config branch.$1.merge) >actual.$1
+ test_cmp expect.$1 actual.$1
+}
+
+test_expect_success 'push -u master:master' '
+ git push -u upstream master:master &&
+ check_config master upstream refs/heads/master
+'
+
+test_expect_success 'push -u master:other' '
+ git push -u upstream master:other &&
+ check_config master upstream refs/heads/other
+'
+
+test_expect_success 'push -u --all' '
+ git branch all1 &&
+ git branch all2 &&
+ git push -u --all &&
+ check_config all1 upstream refs/heads/all1 &&
+ check_config all2 upstream refs/heads/all2
+'
+
+test_expect_failure 'push -u HEAD' '
+ git checkout -b headbranch &&
+ git push -u upstream HEAD &&
+ check_config headbranch upstream refs/heads/headbranch
+'
+
+test_done
^ permalink raw reply related
* Re: [PATCH] Add push --set-upstream
From: Johannes Schindelin @ 2010-01-15 17:12 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Ilari Liusvaara, git
In-Reply-To: <vpqy6jzuwpv.fsf@bauges.imag.fr>
Hi,
On Fri, 15 Jan 2010, Matthieu Moy wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>
> > + OPT_BIT('u', "set-upstream", &flags, "Set upstream for git pull", TRANSPORT_PUSH_SET_UPSTREAM),
>
> I'd be in favor of --track for the option name. Not that it's the best
> name ever, but this is really doing the same job as branch --track and
> checkout --track, so it should have the same name.
>
> Or the --track option of branch and checkout should be renamed as
> --set-upstream, but that seems a lot of trouble for little benefit.
Junio already complained that it is a bad name, basically because it is
ambiguous. If you are really pushing for --track, you will have to think
of a compelling reasoning.
Ciao,
Dscho
P.S.: FWIW I think --set-upstream is really a good name.
^ permalink raw reply
* Re: [PATCH] Add push --set-upstream
From: Matthieu Moy @ 2010-01-15 17:03 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <1263573407-13642-1-git-send-email-ilari.liusvaara@elisanet.fi>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> +
> +-u::
> +--set-upstream::
> + For every branch that is up to date or successfully pushed, add
> + upstream (tracking) reference for argument-less git pull.
Not just argument-less git pull. git status is also impacted for
example. Actually, we already have documentation for it in git-branch
(--track option), and git-config (branch.<name>.merge configuration
variable), so you should add a pointer to one of them.
How about
--set-upstream::
For every branch that is up to date or successfully pushed, add
upstream (tracking) reference, used by argument-less
linkgit:git-pull[1] and other commands. For more information,
see 'branch.<name>.merge' in linkgit:git-config[1].
?
> + OPT_BIT('u', "set-upstream", &flags, "Set upstream for git pull", TRANSPORT_PUSH_SET_UPSTREAM),
I'd be in favor of --track for the option name. Not that it's the best
name ever, but this is really doing the same job as branch --track and
checkout --track, so it should have the same name.
Or the --track option of branch and checkout should be renamed as
--set-upstream, but that seems a lot of trouble for little benefit.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* git mv oddities (minor bugs)
From: Patrick Boettcher @ 2010-01-15 16:49 UTC (permalink / raw)
To: git
Hi all,
I'm currently using a lot of git mv to clean up some code. This includes
renaming of files and moving them to new pathes inside the clone.
Everything's working very fine except two very small things I've
encountered:
1) git mv from/file to/subdir/ - subdir does not exists
Instead of git telling me that 'subdir' does not exist it is executing the
mv and 'file' is now called 'to/subdir' .
I'm almost sure this is a bug: the trailing / seems to be ignored.
2) git mv from/file to/subdir/new_name - subdir does not exists
Git is telling me the following:
fatal: renaming 'from/file' failed: No such file or directory
This is a little bit misleading as it is 'to/subdir' which is "No such
file or directory" .
I'm not sure what to do with this one - changing the error message a
little bit might a good idea.
I'm using:
$ git --version
git version 1.6.4.4
I was looking for a bug tracker at git-scm.org - didn't find any. So I'm
not sure where to log my findings. How should I continue?
--
Patrick Boettcher - Kernel Labs
http://www.kernellabs.com/
^ permalink raw reply
* [PATCH] Add push --set-upstream
From: Ilari Liusvaara @ 2010-01-15 16:36 UTC (permalink / raw)
To: git
Frequent complaint is lack of easy way to set up upstream (tracking)
references for git pull to work as part of push command. So add switch
--set-upstream (-u) to do just that.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
---
This is built on top of master.
Documentation/git-push.txt | 8 +++++++-
builtin-push.c | 1 +
transport.c | 35 +++++++++++++++++++++++++++++++++++
transport.h | 1 +
4 files changed, 44 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-push.txt b/Documentation/git-push.txt
index e3eb1e8..6c68978 100644
--- a/Documentation/git-push.txt
+++ b/Documentation/git-push.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git push' [--all | --mirror | --tags] [-n | --dry-run] [--receive-pack=<git-receive-pack>]
- [--repo=<repository>] [-f | --force] [-v | --verbose]
+ [--repo=<repository>] [-f | --force] [-v | --verbose] [-u | --set-upstream]
[<repository> <refspec>...]
DESCRIPTION
@@ -122,6 +122,12 @@ nor in any Push line of the corresponding remotes file---see below).
the name "origin" is used. For this latter case, this option
can be used to override the name "origin". In other words,
the difference between these two commands
+
+-u::
+--set-upstream::
+ For every branch that is up to date or successfully pushed, add
+ upstream (tracking) reference for argument-less git pull.
+
+
--------------------------
git push public #1
diff --git a/builtin-push.c b/builtin-push.c
index 28a26e7..75ddaf4 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -218,6 +218,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BOOLEAN( 0 , "thin", &thin, "use thin pack"),
OPT_STRING( 0 , "receive-pack", &receivepack, "receive-pack", "receive pack program"),
OPT_STRING( 0 , "exec", &receivepack, "receive-pack", "receive pack program"),
+ OPT_BIT('u', "set-upstream", &flags, "Set upstream for git pull", TRANSPORT_PUSH_SET_UPSTREAM),
OPT_END()
};
diff --git a/transport.c b/transport.c
index b5332c0..956d2ed 100644
--- a/transport.c
+++ b/transport.c
@@ -8,6 +8,7 @@
#include "bundle.h"
#include "dir.h"
#include "refs.h"
+#include "branch.h"
/* rsync support */
@@ -135,6 +136,33 @@ static void insert_packed_refs(const char *packed_refs, struct ref **list)
}
}
+static void set_upstreams(struct transport *trans, struct ref *refs)
+{
+ struct ref *i;
+ for (i = refs; i; i = i->next) {
+ /*
+ * Check suitability for tracking. Must be successful /
+ * alreay up-to-date ref create/modify (not delete) and
+ * both sides must be local branches.
+ */
+ if (i->status != REF_STATUS_OK &&
+ i->status != REF_STATUS_UPTODATE)
+ continue;
+ if (!i->peer_ref)
+ continue;
+ if (!i->new_sha1 || is_null_sha1(i->new_sha1))
+ continue;
+ if (prefixcmp(i->peer_ref->name, "refs/heads/"))
+ continue;
+ if (prefixcmp(i->name, "refs/heads/"))
+ continue;
+
+ install_branch_config(BRANCH_CONFIG_VERBOSE,
+ i->peer_ref->name + 11, trans->remote->name,
+ i->name);
+ }
+}
+
static const char *rsync_url(const char *url)
{
return prefixcmp(url, "rsync://") ? skip_prefix(url, "rsync:") : url;
@@ -974,6 +1002,10 @@ int transport_push(struct transport *transport,
verify_remote_names(refspec_nr, refspec);
if (transport->push) {
+ /* Maybe FIXME. But no important transport uses this case. */
+ if (flags & TRANSPORT_PUSH_SET_UPSTREAM)
+ die("This transport does not support using --set-upstream");
+
return transport->push(transport, refspec_nr, refspec, flags);
} else if (transport->push_refs) {
struct ref *remote_refs =
@@ -1002,6 +1034,9 @@ int transport_push(struct transport *transport,
verbose | porcelain, porcelain,
nonfastforward);
+ if (flags & TRANSPORT_PUSH_SET_UPSTREAM)
+ set_upstreams(transport, remote_refs);
+
if (!(flags & TRANSPORT_PUSH_DRY_RUN)) {
struct ref *ref;
for (ref = remote_refs; ref; ref = ref->next)
diff --git a/transport.h b/transport.h
index 97ba251..c4314dd 100644
--- a/transport.h
+++ b/transport.h
@@ -91,6 +91,7 @@ struct transport {
#define TRANSPORT_PUSH_VERBOSE 16
#define TRANSPORT_PUSH_PORCELAIN 32
#define TRANSPORT_PUSH_QUIET 64
+#define TRANSPORT_PUSH_SET_UPSTREAM 128
/* Returns a transport suitable for the url */
struct transport *transport_get(struct remote *, const char *);
--
1.6.6.102.gd6f8f.dirty
^ permalink raw reply related
* Re: Gitignore matching "git add" wildcard prevents operation
From: Jeff King @ 2010-01-15 16:30 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Junio C Hamano, Marko Poutiainen, git
In-Reply-To: <20100115161107.GC12982@vidovic>
On Fri, Jan 15, 2010 at 05:11:07PM +0100, Nicolas Sebrecht wrote:
> > I don't understand what you mean. How does "sed" do its own globbing of
> > the command line?
>
> Well, we are in the same dilemma as the other tools. The internal
> globbing rules are explained in the related man page.
Maybe I wasn't clear: to my knowledge, "sed" does not do any globbing
itself. How is this the same situation?
Of course other commands like sed will be fed the expansion of a shell
glob, and there may be times when you want to feed a subset of an
expansion. But that is not my complaint; my complaint was mainly that
git's solution to this is not easily discoverable by an uninformed user.
Most other commands don't even have a solution (you would have to solve
it in the shell to pass the desired expansion to the program).
> > when I look in the manual, I am more likely to look for a command-line
> > option that helps me rather than to read all of the text
>
> True. All I can see is to improve the man page with a dedicated section
> "Globbing" instead of loosing it in a "random" place.
I don't think that would help. The problem is that the user knows they
have an issue with ignored files. The solution is custom globbing, but
they don't know that. So making globbing more prominent doesn't help,
since they will be looking for ignores. You would need to have an
"ignore" section that mentions globbing.
To be clear: I do not have an actual solution, and my initial message
was mostly just grumbling. We _do_ mention globbing and ignores in the
same paragraph, as I quoted earlier. So that is probably enough for a
diligent user to come up with the solution, or at least enough that
trying to improve on it will have diminishing returns.
You could even argue that I was not being such a diligent user in my
initial response. :)
-Peff
^ permalink raw reply
* Re: Gitignore matching "git add" wildcard prevents operation
From: Nicolas Sebrecht @ 2010-01-15 16:11 UTC (permalink / raw)
To: Jeff King; +Cc: Nicolas Sebrecht, Junio C Hamano, Marko Poutiainen, git
In-Reply-To: <20100115154816.GA1579@coredump.intra.peff.net>
The 15/01/10, Jeff King wrote:
> On Fri, Jan 15, 2010 at 04:34:19PM +0100, Nicolas Sebrecht wrote:
>
> > > 1. Most programs don't take their own globs. Without knowing that git
> > > can do so, there is no reason to discover it in this instance. I
> > > can see searching the manpage for options, but not for a discussion
> > > of globbing behavior.
> > >
> > > 2. They would have to know that using a git-glob will magically change
> > > the error-checking behavior.
> >
> > Not sure. This isn't a Git-particular issue.
> >
> > Users may hit this with a lot of other unix tools (sed, grep, find,
> > etc). So, we can expect either
> > they already know the issue;
> > or
> > they are discovering it using Git.
>
> I don't understand what you mean. How does "sed" do its own globbing of
> the command line?
Well, we are in the same dilemma as the other tools. The internal
globbing rules are explained in the related man page.
> > Most of the tools I talk about do have a manual section about globbing.
> > Users could learn globs with Git too and expect the same behaviour
> > somewhere else.
>
> Sure. git-add(1) talks about globbing, too
Oops, I was missing that; thanks.
> My complaint was more that as a user, I am not likely to see this
> problem and think "I'll bet git-specific globbing can solve it."
Yes. My point is that we are not talking about a Git specific issue.
What you're raising here is true whatever the command is. So, as long as
we clearly explain how 'git add' works, we are fine. Don't we?
> And
> when I look in the manual, I am more likely to look for a command-line
> option that helps me rather than to read all of the text
True. All I can see is to improve the man page with a dedicated section
"Globbing" instead of loosing it in a "random" place.
--
Nicolas Sebrecht
^ permalink raw reply
* Re: Gitignore matching "git add" wildcard prevents operation
From: Jeff King @ 2010-01-15 15:48 UTC (permalink / raw)
To: Nicolas Sebrecht; +Cc: Junio C Hamano, Marko Poutiainen, git
In-Reply-To: <20100115153419.GA12982@vidovic>
On Fri, Jan 15, 2010 at 04:34:19PM +0100, Nicolas Sebrecht wrote:
> > 1. Most programs don't take their own globs. Without knowing that git
> > can do so, there is no reason to discover it in this instance. I
> > can see searching the manpage for options, but not for a discussion
> > of globbing behavior.
> >
> > 2. They would have to know that using a git-glob will magically change
> > the error-checking behavior.
>
> Not sure. This isn't a Git-particular issue.
>
> Users may hit this with a lot of other unix tools (sed, grep, find,
> etc). So, we can expect either
> they already know the issue;
> or
> they are discovering it using Git.
I don't understand what you mean. How does "sed" do its own globbing of
the command line?
> Most of the tools I talk about do have a manual section about globbing.
> Users could learn globs with Git too and expect the same behaviour
> somewhere else.
Sure. git-add(1) talks about globbing, too, and it even has a sentence
that explains exactly what is happening in Marko's case:
The git add command will not add ignored files by default. If any
ignored files were explicitly specified on the command line, git add
will fail with a list of ignored files. Ignored files reached by
directory recursion or filename globbing performed by Git (quote your
globs before the shell) will be silently ignored.
My complaint was more that as a user, I am not likely to see this
problem and think "I'll bet git-specific globbing can solve it." And
when I look in the manual, I am more likely to look for a command-line
option that helps me rather than to read all of the text (though the
fact that we specifically mention "ignore" in the same paragraph means
that at least a user searching for "ignore" in the man page will come up
with this paragraph).
-Peff
^ permalink raw reply
* Re: [PATCH] git push --track
From: Miles Bader @ 2010-01-15 15:45 UTC (permalink / raw)
To: Rudolf Polzer; +Cc: Junio C Hamano, git, Ilari Liusvaara
In-Reply-To: <20100115140048.GB30986@rm.endoftheinternet.org>
Rudolf Polzer <divVerent@alientrap.org> writes:
> But well. Why bother with this, if this feature was rejected before already
> anyway.
It's a good feature and people obviously want it, so it's worth trying.
Sometimes it takes a few tries to get a feature added...
-Miles
--
`...the Soviet Union was sliding in to an economic collapse so comprehensive
that in the end its factories produced not goods but bads: finished products
less valuable than the raw materials they were made from.' [The Economist]
^ permalink raw reply
* Re: git checkout -f: What am I missing?
From: Michael J Gruber @ 2010-01-15 15:28 UTC (permalink / raw)
To: Soham Mehta; +Cc: git
In-Reply-To: <4B4F899C.7070800@box.net>
Soham Mehta venit, vidit, dixit 14.01.2010 22:16:
> Hi,
>
> I have a situation with git that I'm trying to understand:
>
> Description:
> 1) GIT_DIR is set to /path/to/repo/.git
> 2) Repository is /not /a bare repo, and all files are nicely checked-out
> in /path/to/repo/
> 3) Somebody pushes to that repo using ssh (any branch, checked-out or not)
> 4) Default post-receive hook runs (it is the only one +x) which sends
> out an email
> (http://repo.or.cz/w/git.git/blob/HEAD:/contrib/hooks/post-receive-email)
> 5) After it is done sending the email, I put "git checkout -f", at the
> end in the same file, in case someone pushes to a checked-out branch
>
> Problem:
> It runs "checkout -f" as if inside .git directory, instead of on the
> parent. i.e. it gets all files from the parent and writes them inside
> .git. Parent is left untouched.
>
> Some more info:
> 0) We don't have GIT_DIR set in the environment. The hook does a
> rev-parse to find it.
> 1) echo of $GIT_DIR right before the checkout -f line gives a "." .
> 2) It works as expected if I do this: cd /path/to/repo && git
> --git-dir=/path/to/repo/.git/ checkout -f
>
> What I do know:
> 1) Pushing to a checked-out branch is not a git best-practice, and some
> git behavior is undefined in that case. We already have plans to go away
> from that.
> 2) Git tends to like full path names instead of relative ones
>
> Can someone help me understand this behavior?
Does the thread
http://permalink.gmane.org/gmane.comp.version-control.git/136267
help by any chance?
You've found the solution, "cd .. && unset GIT_DIR" does it.
Michael
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox