* Re: Mirroring repository state, with branches and submodules.
From: Miklos Vajna @ 2009-03-17 16:56 UTC (permalink / raw)
To: Toby White; +Cc: git
In-Reply-To: <623D3837-E899-49AF-9A37-F667A311EE58@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 489 bytes --]
On Tue, Mar 17, 2009 at 03:21:40PM +0000, Toby White <toby.o.h.white@googlemail.com> wrote:
> git fetch
> for BRANCH in $(git branch -r | cut -d / -f 2); do
> git checkout $BRANCH
> git reset --hard origin/$BRANCH
> done
> git submodule update --init
First, I think you don't handle the case when you have multiple
remotes. I don't know if this is a problem for you or not.
Second, use plumbing in scripts, git for-each-ref has a stable output
format, while git branch may change.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Generate version file by hooks
From: Johannes Sixt @ 2009-03-17 16:54 UTC (permalink / raw)
To: Björn Hendriks; +Cc: git, John Dlugosz, Santi Béjar
In-Reply-To: <200903171740.26575.bjoern01@nurfuerspam.de>
Björn Hendriks schrieb:
> In fact my problem is not to find out the SHA1 of the last commit in a script
> but to have that script called automatically each time git changes the
> commit. My idea was to use the git hooks for that, but as I explained I
> couldn't find hooks for all cases in which a commit changes.
In fact there are so many situations where the current commit changes. You
won't find enough hooks to catch all cases.
You better modify your build system to look for the current commit when it
is needed. That is *much* safer.
-- Hannes
^ permalink raw reply
* Re: [PATCH] disable post-checkout test on Cygwin
From: Junio C Hamano @ 2009-03-17 16:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: Jeff King, layer, git
In-Reply-To: <81b0412b0903170926p4f2d536el2b96a71c79c0159e@mail.gmail.com>
Alex Riesen <raa.lkml@gmail.com> writes:
> It is broken because of the tricks we have to play with
> lstat to get the bearable perfomance out of the call.
> Sadly, it disables access to Cygwin's executable attribute,
> which Windows filesystems do not have at all.
Hmm, perhaps when checking hooks to see if they are executable, Cygwin
port should avoid using the "tricks"? Compared to paths inside the
worktree the number of hooks is a lot smaller, no?
^ permalink raw reply
* Re: [PATCH] git-branch.txt: document -f correctly
From: Michael J Gruber @ 2009-03-17 16:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6v4qf4o.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 17.03.2009 17:37:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> 'git branch -f a b' resets a to b when a exists, rather then deleting a.
>> Say so in the documentation.
>>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>> ---
>> Something like this?
>>
>> BTW, I noticed that 'git-subcmd' is used everywhere in here which does
>> not feel right, but I followed the existing style, leaving a consistent
>> clean-up for a later patch. Also, typesetting is inconsistent:
>> We have <branch> as well as `<branch>` when the text talks about the
>> options. Do we have a style guide or such?
>>
>> Documentation/git-branch.txt | 4 ++--
>> 1 files changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
>> index 6103d62..27b73bc 100644
>> --- a/Documentation/git-branch.txt
>> +++ b/Documentation/git-branch.txt
>> @@ -76,8 +76,8 @@ OPTIONS
>> based sha1 expressions such as "<branchname>@\{yesterday}".
>>
>> -f::
>> - Force the creation of a new branch even if it means deleting
>> - a branch that already exists with the same name.
>> + Reset <branchname> to <startpoint> if <branchname> exists
>> + already. Without `-f` 'git-branch' refuses to change an existing branch.
>
> And what happens if the branchname does not exist?
Well, the standard behaviour of "git branch" is described in the
"description", the meaning of the options under "options"...
We could add
If <branchname> does not exist it is created and '-f' has no effect.
although that seems a bit talkative.
>
>>
>> -m::
>> Move/rename a branch and the corresponding reflog.
>> --
>> 1.6.2.149.g6462
^ permalink raw reply
* RE: fetch and pull
From: John Dlugosz @ 2009-03-17 16:44 UTC (permalink / raw)
Cc: git, Junio C Hamano
In-Reply-To: <76718490903170921r36843c11y5aac537d53384298@mail.gmail.com>
> On Tue, Mar 17, 2009 at 10:58 AM, John Dlugosz
> <JDlugosz@tradestation.com> wrote:
> >> $ git clone git://central/repo.git
> >> $ cd repo
> >> $ git checkout -b topic origin/master
> >> $ edit, commit, edit, commit, looks good
> >> $ git checkout master
> >> $ git pull
> >
> > You checkout master before updating it?
>
> You cannot merge/rebase a branch unless it is checked out.
>
Sure you can.
git rebase upstream topic
But I think I see the point: the implicit merge done by pull uses the current HEAD and config branch.<name>.merge.
My concern is that you establish your working state based on the local 'master', only to immediately change it again when the pull updates master. But that's the way it's supposed to work?
I think the documentation for git-pull might also be garbled from text being of different eras. "Normally the branch merged is the HEAD of the remote"? That will be basically random since the last thing the upstream repo user did will control what his HEAD is.
But, the intention here is
1) direct attention to the desired branch
2) do what is appropriate for the current branch
The key to avoiding massive confusion is making sure that (2) is set up properly. I never know what's going to happen with a pull, and I suppose that's because nothing was set up properly.
--John (still confused)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: Generate version file by hooks
From: Björn Hendriks @ 2009-03-17 16:40 UTC (permalink / raw)
To: git; +Cc: John Dlugosz, Santi Béjar
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A2AF280@EXCHANGE.trad.tradestation.com>
Hi John, hi Santi,
thanks for your help.
On Dienstag 17 März 2009 16:42:01 John Dlugosz wrote:
> Isn't that what the existing file HEAD is for? Possibly with a level of
> indirection. So use
> git rev-parse HEAD
> any time you need that SHA1 value. The HEAD is always updated, since
> that _is_ what defines the "current" commit.
That might be a good alternative to my call of git-log which I was not
absolutely sure if it works under all circumstances.
In fact my problem is not to find out the SHA1 of the last commit in a script
but to have that script called automatically each time git changes the
commit. My idea was to use the git hooks for that, but as I explained I
couldn't find hooks for all cases in which a commit changes.
I need git to do that because my application is a Matlab-project which I
normally do not compile -- although there is a Matlab-compiler to get a
standalone application, but within the Matlab environment you don't need to
compile. It would be the same with my little bash-helper-scripts I manage
also with the great assistance of git.
But now -- as I think of it -- I might as well put a script call into the
Matlab-code to get the last SHA1 and find a different solution for the rare
cases in which I really compile the Matlab-code.
Thanks
Björn
^ permalink raw reply
* Re: [StGit PATCH 4/4] Use a default "hidden" argument in StackTransaction.reorder_patches
From: Karl Hasselström @ 2009-03-17 16:38 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20090317110910.27748.80312.stgit@pc1117.cambridge.arm.com>
On 2009-03-17 11:09:10 +0000, Catalin Marinas wrote:
> This argument is rarely used so adding a default value simplifies
> the calling code.
>
> Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
Acked-by: Karl Hasselström <kha@treskal.com>
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] git-branch.txt: document -f correctly
From: Junio C Hamano @ 2009-03-17 16:37 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <1237298780-11304-1-git-send-email-git@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> 'git branch -f a b' resets a to b when a exists, rather then deleting a.
> Say so in the documentation.
>
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
> Something like this?
>
> BTW, I noticed that 'git-subcmd' is used everywhere in here which does
> not feel right, but I followed the existing style, leaving a consistent
> clean-up for a later patch. Also, typesetting is inconsistent:
> We have <branch> as well as `<branch>` when the text talks about the
> options. Do we have a style guide or such?
>
> Documentation/git-branch.txt | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
> index 6103d62..27b73bc 100644
> --- a/Documentation/git-branch.txt
> +++ b/Documentation/git-branch.txt
> @@ -76,8 +76,8 @@ OPTIONS
> based sha1 expressions such as "<branchname>@\{yesterday}".
>
> -f::
> - Force the creation of a new branch even if it means deleting
> - a branch that already exists with the same name.
> + Reset <branchname> to <startpoint> if <branchname> exists
> + already. Without `-f` 'git-branch' refuses to change an existing branch.
And what happens if the branchname does not exist?
>
> -m::
> Move/rename a branch and the corresponding reflog.
> --
> 1.6.2.149.g6462
^ permalink raw reply
* Re: .gitk should created hidden in windows
From: Steve Wagner @ 2009-03-17 16:35 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A3FC063@EXCHANGE.trad.tradestation.com>
John Dlugosz schrieb:
> Yes, I was thinking that I was confronted by these things more in Vista
> on a desktop, but can't remember exactly. A lot of the directories are
> symbolic links that can't be clicked! I'm running Windows 2003 which I
> think is based on the Vista core, but doesn't have the flashy UI candy,
> for servers.
As far as is know, 2003 is based on xp and the this large amount of
symbolic links are only there to dont break bad develop applications
which are not using variables like APPDATA.
> But, you would not see more clutter if it was in the place where your
> APPDATA environment variable points, right?
Yes this is the better approach on windows, but since it is only one
file, it would be ok to leave it there and make it hidden.
Steve
^ permalink raw reply
* Re: submodules inside submodules?
From: Johannes Schindelin @ 2009-03-17 16:34 UTC (permalink / raw)
To: Matthias Nothhaft; +Cc: git
In-Reply-To: <978bdee00903170907g4cd02b01y971d378295787d50@mail.gmail.com>
Hi.
On Tue, 17 Mar 2009, Matthias Nothhaft wrote:
> can I put submodules into submodules?
Yes.
Ciao,
Dscho
^ permalink raw reply
* Re: [StGit PATCH 3/4] Convert "float" to the lib infrastructure
From: Karl Hasselström @ 2009-03-17 16:34 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20090317110904.27748.38688.stgit@pc1117.cambridge.arm.com>
On 2009-03-17 11:09:04 +0000, Catalin Marinas wrote:
> Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
Acked-by: Karl Hasselström <kha@treskal.com>
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [PATCH] disable post-checkout test on Cygwin
From: Alex Riesen @ 2009-03-17 16:26 UTC (permalink / raw)
To: Jeff King; +Cc: layer, git, Junio C Hamano
[-- Attachment #1: Type: text/plain, Size: 968 bytes --]
It is broken because of the tricks we have to play with
lstat to get the bearable perfomance out of the call.
Sadly, it disables access to Cygwin's executable attribute,
which Windows filesystems do not have at all.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t5403-post-checkout-hook.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
2009/3/3 Jeff King <peff@peff.net>:
> +mkdir -p templates/hooks
> +cat >templates/hooks/post-checkout <<'EOF'
> +#!/bin/sh
> +echo $@ > $GIT_DIR/post-checkout.args
> +EOF
> +chmod +x templates/hooks/post-checkout
> +
> +test_expect_success 'post-checkout hook is triggered by clone' '
> + git clone --template=templates . clone3 &&
> + test -f clone3/.git/post-checkout.args
> +'
This is broken on cygwin: the hook script won't be not marked executable
by copy_file, because the native Win32 stat(2) routines are used and
report the mode of source file as 0666.
[-- Attachment #2: 0001-disable-post-checkout-test-on-Cygwin.diff --]
[-- Type: application/octet-stream, Size: 1235 bytes --]
From e5394ee710460e25369b4755798930a3f19085c5 Mon Sep 17 00:00:00 2001
From: Alex Riesen <raa.lkml@gmail.com>
Date: Tue, 17 Mar 2009 17:22:53 +0100
Subject: [PATCH] disable post-checkout test on Cygwin
It is broken because of the tricks we have to play with
lstat to get the bearable perfomance out of the call.
Sadly, it disables access to Cygwin's executable attribute,
which Windows filesystems do not have at all.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
---
t/t5403-post-checkout-hook.sh | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/t/t5403-post-checkout-hook.sh b/t/t5403-post-checkout-hook.sh
index 4fdb418..5858b86 100755
--- a/t/t5403-post-checkout-hook.sh
+++ b/t/t5403-post-checkout-hook.sh
@@ -71,6 +71,7 @@ test_expect_success 'post-checkout receives the right args when not switching br
test $old = $new -a $flag = 0
'
+if test "$(git config --bool core.filemode)" = true; then
mkdir -p templates/hooks
cat >templates/hooks/post-checkout <<'EOF'
#!/bin/sh
@@ -82,5 +83,6 @@ test_expect_success 'post-checkout hook is triggered by clone' '
git clone --template=templates . clone3 &&
test -f clone3/.git/post-checkout.args
'
+fi
test_done
--
1.6.2.142.gaf8db
^ permalink raw reply related
* Re: [PATCH][v2] http authentication via prompts (with correct line lengths)
From: Daniel Barkalow @ 2009-03-17 16:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Amos King, git
In-Reply-To: <7v8wn4u0ip.fsf@gitster.siamese.dyndns.org>
On Mon, 16 Mar 2009, Junio C Hamano wrote:
> Amos King <amos.l.king@gmail.com> writes:
>
> > Junio,
> >
> > I'm working with Mike on the http auth stuff, and I was testing out
> > your patch. I can get it to work for fetch but push is giving me some
> > grief. Looking through the code I noticed that online 219 of
> > http-push.c that http_init is being called with NULL instead of a
> > remote. If I pass in the remote then there is no remotre-url. I've
> > been digging around and can't find where or when that is being set.
> > It has been a while since I worked with C but I'd love to jump in and
> > help out here. Can you point me in the right direction to get the
> > remote->url[0] set for the http_auth_init to use?
>
> Daniel is the primary culprit who introduced the transport abstraction,
> and I think he muttered something about his work-in-progress that involves
> in some change in the API. Perhaps he has some insights here?
>
> Naah. I forgot that the transport abstraction on the fetch side is much
> more integrated but curl_transport_push() simply launches http-push.c that
> has a world on its own. Worse yet, "remote" in http-push.c is not even
> the "struct remote"; it is something private to http-push.c called "struct
> repo".
>
> I am not sure how much work would be involved in converting (or if it is
> even worth to convert) http-push.c to fit better into the transport API,
> but if that is feasible, it might be a better longer-term solution.
I think it would be a good thing to do. With the new transport push
method, it could even get support for updating the tracking refs that
track the refs you changed, since I broke that out of the git-native
protocol code and into the transport code.
My guess is that converting http-push to be called in-process would
actually be pretty easy, because the two sides don't look at the same data
currently. (Some things were tricky with fetch, because the same process
sometimes wants to do fetches multiple times, for getting tags; this isn't
as big a deal.)
I think it should just be a matter of breaking http-push's main() into a
function that deals with the http-push command line and a function that
does the work, setting up a header file like send-pack.h, and changing
transport.c to just call the function.
> Right now, builtin-push.c does all the remote inspection and when
> http-push is called, the latter gets the information at the lowest level
> only; the higher level information such as what nickname was used by the
> user to initiate the "git push" process and whether the refspecs came from
> the command line or from the config are all lost, which is quite sad.
What I did short-term for the send-pack version was introduce an optional
command line argument, "--remote", that names the remote used, so the
other program could get the configuration as well. It's a pretty easy
step, but I don't think it's too worthwhile in this case.
> But as a much lower impact interim solution, I suspect that you can fake a
> minimally usable remote. The http_push() codepath only cares about
> remote->http_proxy and remote->url settings as far as I can tell, so
> perhaps you can start (with a big warning that the remote you are creating
> is a fake one) by filling the absolute minimum?
>
> That is, something along these lines (this comes on top of an obvious
> patch that renames existing "remote" variable in http-push. to "repo").
>
> diff --git a/http-push.c b/http-push.c
> index dfbb247..f04ac74 100644
> --- a/http-push.c
> +++ b/http-push.c
> @@ -2197,6 +2197,7 @@ int main(int argc, char **argv)
> int new_refs;
> struct ref *ref;
> char *rewritten_url = NULL;
> + struct remote *remote;
>
> git_extract_argv0_path(argv[0]);
>
> @@ -2258,12 +2259,14 @@ int main(int argc, char **argv)
> if (!repo->url)
> usage(http_push_usage);
>
> + remote = remote_get(repo->url);
> +
> if (delete_branch && nr_refspec != 1)
> die("You must specify only one branch name when deleting a remote branch");
>
> memset(remote_dir_exists, -1, 256);
>
> - http_init(NULL);
> + http_init(remote);
>
> no_pragma_header = curl_slist_append(no_pragma_header, "Pragma:");
This should work, although it obviously won't figure out the proxy for the
configuration for the remote that was actually used.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: fetch and pull
From: Jay Soffian @ 2009-03-17 16:21 UTC (permalink / raw)
To: John Dlugosz; +Cc: git, Junio C Hamano
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A2AF22F@EXCHANGE.trad.tradestation.com>
On Tue, Mar 17, 2009 at 10:58 AM, John Dlugosz
<JDlugosz@tradestation.com> wrote:
>> $ git clone git://central/repo.git
>> $ cd repo
>> $ git checkout -b topic origin/master
>> $ edit, commit, edit, commit, looks good
>> $ git checkout master
>> $ git pull
>
> You checkout master before updating it?
You cannot merge/rebase a branch unless it is checked out.
> The developers may not non-ff the dev when they push it. But the repository maintainer may reset dev for some reason, and since topic branches are pushed, he can see that it either doesn't bother anyone that way or knows who to help out. But, it means that in general the pull _could_ be arbitrary and not a ff from his last pull.
>
> For example, developer A checks in a finished topic, then B checks in a finished topic. But A doesn't use a spell checker even though he *really* should, and doesn't proof read even though he **really** should let a native English speaker look at it first. So the repository maintainer rewrites the tip of the dev branch. Next morning, everyone pulls, and both A and B are non-ff even though they have not branched anything from the old A or B.
We seem to not be understanding each other, and I apologize, but I
cannot invest any more time in this thread. Perhaps others better
understand what you are trying to do and can jump in.
j.
^ permalink raw reply
* submodules inside submodules?
From: Matthias Nothhaft @ 2009-03-17 16:07 UTC (permalink / raw)
To: git
Hi,
can I put submodules into submodules? or is nesting submodules not possible?
regards,
Matthias
^ permalink raw reply
* RE: .gitk should created hidden in windows
From: John Dlugosz @ 2009-03-17 16:11 UTC (permalink / raw)
To: Steve Wagner; +Cc: git
In-Reply-To: <49BFCA68.2080800@lanwin.de>
> This is true for XP and before, but in Vista, 2008 and Windows 7 the
> user have directly access to the user profile directory (simply click
> on
> the username in startmenue) and can see the .gitk file.
>
> Steve
Yes, I was thinking that I was confronted by these things more in Vista
on a desktop, but can't remember exactly. A lot of the directories are
symbolic links that can't be clicked! I'm running Windows 2003 which I
think is based on the Vista core, but doesn't have the flashy UI candy,
for servers.
But, you would not see more clutter if it was in the place where your
APPDATA environment variable points, right?
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: [PATCH] git-branch.txt: document -f correctly
From: John Dlugosz @ 2009-03-17 16:07 UTC (permalink / raw)
To: git; +Cc: git
=== Re: ===
BTW, I noticed that 'git-subcmd' is used everywhere in here which does
not feel right, but I followed the existing style, leaving a consistent
clean-up for a later patch. Also, typesetting is inconsistent:
We have <branch> as well as `<branch>` when the text talks about the
options. Do we have a style guide or such?
=== end ===
I would agree that being factually correct and available immediately
trumps being wrong but pretty.
As an experienced writer and editor, the documentation is something I
might hack long before I tackle the code. I see you edited a file with
.txt extension, and some kind of markup that's not the HTML files I'm
reading. Beyond any kind of style guide, is there a guide to the
documentation _system_ in use?
--John
(please excuse the footer; it's not my idea)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: [PATCH] Give error when no remote is configured
From: Daniel Barkalow @ 2009-03-17 16:06 UTC (permalink / raw)
To: Giovanni Bajo; +Cc: Jay Soffian, Junio C Hamano, bernie, git
In-Reply-To: <49BEEAF4.40403@develer.com>
On Tue, 17 Mar 2009, Giovanni Bajo wrote:
> On 3/16/2009 9:01 PM, Jay Soffian wrote:
> > On Mon, Mar 16, 2009 at 12:55 PM, Daniel Barkalow <barkalow@iabervon.org>
> > wrote:
> > > No default remote is configured for your current branch, and the default
> > > remote "origin" is not configured either.
> >
> > The use of "default" twice is slightly confusing. Perhaps:
> >
> > No remote is configured for the current branch, and the default
> > remote "origin" is not configured either.
>
> I'm a total newbie with git. I must say that the above sentence means
> absolutely nothing to me (in either version) because of the confusing usage of
> the word "remote" (twice, one as a substantive, one as an adjective) and the
> word "origin" which is git jargon which I don't master yet.
Actually, it's not that complicated a sentence. In order to
fetch/pull/push, you need to specify some attributes of the other side; at
a minimum, this is the location, but you can also specify other things
(HTTP gateways if you're using HTTP, for example). You can have multiple
of these sets of configuration stored under different names; these are
remotes.
When you run fetch, you can specify the remote on the command line. If you
don't specify, there are two levels of defaults: the first is a setting in
the configuration for whichever branch is current; the second is the
constant "origin".
The message is trying to say that it fell back to looking for a configured
remote named "origin", but there wasn't one configured.
> My suggestion is that you should at least add a sentence that points to a
> likely solution. Something like:
>
> (use "git remote add" to configure a remote URL)
>
> Note that I don't have any clue if this sentece is correct and/or is the
> correct solution. The above is just an example of a helpful error message.
The problem is that there are a number of different sorts of configuration
you might want, and we have no way of knowing which it is.
You might mean to explicitly specify URLs every time to fetch or push in
this repository; you might mean to have a different URL for each branch
you work on; or you might mean to have a general default. It's also
possible that you actually meant "git svn fetch", which uses different
configuration info.
So I think we can only give pointers to the various things it looked for,
and leave it up to the documentation to explain which you want, if any,
and how to get it.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: .gitk should created hidden in windows
From: Steve Wagner @ 2009-03-17 16:06 UTC (permalink / raw)
To: John Dlugosz; +Cc: git
In-Reply-To: <450196A1AAAE4B42A00A8B27A59278E70A2AF295@EXCHANGE.trad.tradestation.com>
> I didn't even notice that file, and I use gitk all the time. That
> directory it put it in, the "top level" user directory based on profile,
> is not something that is directly examined by most users.
This is true for XP and before, but in Vista, 2008 and Windows 7 the
user have directly access to the user profile directory (simply click on
the username in startmenue) and can see the .gitk file.
Steve
John Dlugosz schrieb:
> === Re: ===
> The problem is that windows dose not hides files beginning with a dot as
> it is in unix. So the .gitk file is created as visible in the windows
> user profile. Problematic too is that i can no set the hidden attribute
> to this file, because it is recreated every time i start gitk, so the
> hidden attribute gets lost.
> === end ===
>
> I didn't even notice that file, and I use gitk all the time. That
> directory it put it in, the "top level" user directory based on profile,
> is not something that is directly examined by most users. It is
> probably used as roughly equivalent to the home directory under Unix,
> but is not exactly---Windows has separate defined locations for
> programs's settings, user documents, and desktop among others. I think
> this file properly belongs in %APPDATA%, which is a hidden directory.
> The stuff in that directory is not itself hidden.
>
> That is, use the APPDATA environment variable to locate the file, rather
> than the HOME environment variable.
>
> --John
>
>
>
>
> TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibite
d. If you received this in error, please contact the sender and delete the material from any computer.
>
^ permalink raw reply
* Re: [PATCH v2 1/2] Introduce config variable "diff.defaultOptions"
From: Keith Cascio @ 2009-03-17 16:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20090203071516.GC21367@sigill.intra.peff.net>
Peff,
I'm replying to http://permalink.gmane.org/gmane.comp.version-control.git/108158
On Tue, 3 Feb 2009, Jeff King wrote:
> All in all, this was a lot more complicated than I was expecting. Why isn't
> the behavior of "diff.primer" simply "pretend as if the options in diff.primer
> were prepended to the command line"? That is easy to explain, and easy to
> implement (the only trick is that you have to do an extra pass to find
> --[no-]primer). Is there some drawback to such a simple scheme that I am
> missing?
In order to answer your questions as convincingly as possible, I wrote up a
one-page PDF document, downloadable here:
http://preview.tinyurl.com/c769dd
You will see I clarified my arguments, and I found very compelling reasons for
my design. Also, BTW, v3 supports all diff options under the sun, instead of a
limited subset. That addresses your primary complaint WRT functionality.
Please take a look at the PDF and I hope you agree.
-- Keith
^ permalink raw reply
* Re: .gitk should created hidden in windows
From: John Dlugosz @ 2009-03-17 15:56 UTC (permalink / raw)
To: git; +Cc: lists
=== Re: ===
The problem is that windows dose not hides files beginning with a dot as
it is in unix. So the .gitk file is created as visible in the windows
user profile. Problematic too is that i can no set the hidden attribute
to this file, because it is recreated every time i start gitk, so the
hidden attribute gets lost.
=== end ===
I didn't even notice that file, and I use gitk all the time. That
directory it put it in, the "top level" user directory based on profile,
is not something that is directly examined by most users. It is
probably used as roughly equivalent to the home directory under Unix,
but is not exactly---Windows has separate defined locations for
programs's settings, user documents, and desktop among others. I think
this file properly belongs in %APPDATA%, which is a hidden directory.
The stuff in that directory is not itself hidden.
That is, use the APPDATA environment variable to locate the file, rather
than the HOME environment variable.
--John
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: Generate version file by hooks
From: Santi Béjar @ 2009-03-17 15:43 UTC (permalink / raw)
To: Björn Hendriks; +Cc: git
In-Reply-To: <200903171626.01102.bjoern01@nurfuerspam.de>
2009/3/17 Björn Hendriks <bjoern01@nurfuerspam.de>:
>
> Hello,
>
> I'd like to put the SHA1 of the current commit into a source file so that my
> program can further process it -- put it into a log file for example.
You can look at what is done in git itself with the version number.
There is a GIT-VERSION-GEN that generates a GIT-VERSION-FILE with the
version number (it only updates the file if the version number has
changed). Then in the makefile you specify how to create it and which
programs depend on the GIT-VERSION-FILE:
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL_PATH) ./GIT-VERSION-GEN
-include GIT-VERSION-FILE
program: GIT-VERSION-FILE
HTH,
Santi
^ permalink raw reply
* Re: [PATCH] builtin-tag.c: remove global variable to use the callback data of git-config.
From: Johannes Schindelin @ 2009-03-17 15:47 UTC (permalink / raw)
To: Carlos Rica; +Cc: gitster, git
In-Reply-To: <1237301031.10001.13.camel@equipo-loli>
Hi,
On Tue, 17 Mar 2009, Carlos Rica wrote:
> By using strbuf to save the signing-key id, it also imposes no limit
> to the length of the string obtained from the config or command-line.
> This string is then passed to gpg to sign the tag, when appropriate.
>
> Signed-off-by: Carlos Rica <jasampler@gmail.com>
> ---
>
>
> QUESTION: Is it safe to remove this limit?
I think so. GPG should return an error if it thinks it is too large.
> @@ -164,11 +162,10 @@ static int do_sign(struct strbuf *buffer)
> int len;
> int i, j;
>
> - if (!*signingkey) {
> - if (strlcpy(signingkey, git_committer_info(IDENT_ERROR_ON_NO_NAME),
> - sizeof(signingkey)) > sizeof(signingkey) - 1)
> - return error("committer info too long.");
> - bracket = strchr(signingkey, '>');
> + if (!signingkey->buf[0]) {
It is probably better to ask for !signingkey->len (think of trying to
understand the code in 6 months from now).
Other than that, very nice!
Ciao,
Dscho
^ permalink raw reply
* Re: Generate version file by hooks
From: John Dlugosz @ 2009-03-17 15:42 UTC (permalink / raw)
To: git; +Cc: bjoern01
=== Re: ===
I'd like to put the SHA1 of the current commit into a source file so
that my
program can further process it -- put it into a log file for example.
=== end ===
Isn't that what the existing file HEAD is for? Possibly with a level of
indirection. So use
git rev-parse HEAD
any time you need that SHA1 value. The HEAD is always updated, since
that _is_ what defines the "current" commit.
--John
(please excuse the footer; it's not my idea)
TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and subscription company, and TradeStation Europe Limited, a United Kingdom, FSA-authorized introducing brokerage firm. None of these companies provides trading or investment advice, recommendations or endorsements of any kind. The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited.
If you received this in error, please contact the sender and delete the material from any computer.
^ permalink raw reply
* Re: [StGit PATCH 2/4] Add automatic git-mergetool invocation to the new infrastructure
From: Karl Hasselström @ 2009-03-17 15:30 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20090317110858.27748.21534.stgit@pc1117.cambridge.arm.com>
On 2009-03-17 11:08:58 +0000, Catalin Marinas wrote:
> This patch adds the IndexAndWorktree.mergetool() function
> responsible for calling 'git mergetool' to interactively solve
> conflicts. The function may also be called from
> IndexAndWorktree.merge() if the standard 'git merge-recursive' fails
> and 'interactive == True'. The 'allow_interactive' parameter is
> passed to Transaction.push_patch() from the functions allowing
> interactive merging.
Acked-by: Karl Hasselström <kha@treskal.com>
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ 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