* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-20 14:00 UTC (permalink / raw)
To: Mikael Magnusson
Cc: Santi Béjar, Wincent Colaiuta, Shawn O. Pearce,
Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git
In-Reply-To: <237967ef0903200553v58af40b5sfbfa0bbb1f9d96eb@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1920 bytes --]
Hi,
On Fri, 20 Mar 2009, Mikael Magnusson wrote:
> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Fri, 20 Mar 2009, Santi Béjar wrote:
> >
> >> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >>
> >> > On Fri, 20 Mar 2009, Wincent Colaiuta wrote:
> >> >
> >> >> El 20/3/2009, a las 10:29, Johannes Schindelin escribió:
> >> >>
> >> >> >Often, it is quite interesting to inspect the branch tracked by a
> >> >> >given branch. This patch introduces a nice notation to get at the
> >> >> >tracked branch: 'BEL<branch>' can be used to access that tracked
> >> >> >branch.
> >> >> >
> >> >> >A special shortcut 'BEL' refers to the branch tracked by the current
> >> >> >branch.
> >> >> >
> >> >> >Suggested by Pasky and Shawn.
> >> >>
> >> >> What does BEL actually stand for? I read Shawn's suggestion, but it's
> >> >> not immediately clear to me what "BEL" means.
> >> >
> >> > It is the ASCII "bell" character, 007 (I always wanted to write that
> >> > magic identifier into a patch).
> >> >
> >> > FWIW you could type it in a regular ANSI terminal using Control-v
> >> > Control-g.
> >>
> >> Can we use branch^{origin} instead? It is longer to type, but uses the
> >> same syntax as the ^{tree}, ^{commit}, ^{tag} and you don't have to know
> >> how to produce the bell character.
> >
> > I think I addressed that issue already. (Summary: I do not like it)
> >
> > Let me spell it out if it was not obvious yet: the BEL patch was meant as
> > a more or less funny reminder that the issue is not solved and that I need
> > help.
>
> Would :%:foo work? I thought about the reserved prefix :/! , but :/!!
> isn't reserved so I don't think that would work. And it's pretty
> annoying to type too.
Or maybe :%foo?
That would have a rather nasty interaction with code I have in my tree to
refer to the cache-trees via ':<path>', but I guess I can live with that.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Define a version of lstat(2) with posix semantics
From: Johannes Schindelin @ 2009-03-20 13:52 UTC (permalink / raw)
To: Alex Riesen
Cc: Git Mailing List, Johannes Sixt, Jeff King, layer, Junio C Hamano
In-Reply-To: <81b0412b0903200639v6d99067csb7715d9a5a3f0ba4@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2243 bytes --]
Hi,
On Fri, 20 Mar 2009, Alex Riesen wrote:
> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> > On Fri, 20 Mar 2009, Alex Riesen wrote:
> >
> >> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> >> > Now, we _do_ have msysGit, you _do_ have shown the capability to
> >> > fix issues when they arise, so I do _not_ see any obstacle why you
> >> > should not go msysGit, rather than staying with the pain of trying
> >> > to stay POSIX-compatible, but not quite all the time.
> >>
> >> I understand. It is not pure POSIX compatibility I seek. I just can't
> >> use MinGW port, because I absolutely must use the cygwin environment
> >> (for "hysterical" reasons) and they don't play well together (tried,
> >> yes. Conflicting libraries, but you already know that).
> >
> > Maybe we can work on those conflicting libraries? After all, we do
> > have a "rebase.exe" tool now (for all those as puzzled by the naming
> > as I was: the rebase.exe tool can shift the memory range used by a
> > .dll so that it does not overlap with that one of another .dll).
>
> As long as they can be made to coexist I'm fine. Wasn't the problem that
> MinGW/MSYS used cygwin1.dll if it were in PATH? Or was it something else
> with their supporting libraries?
I think it is the fact that msys-1.0.dll is a stripped-down fork of
cygwin1.dll.
It is needed to run shell and perl scripts.
(Unfortunately, a few important parts of Git are still implemented as
shell scripts: bisect, pull and rebase being the most obvious to me, but
repack, stash and submodule are not too unimportant, either.)
> My other problem is that the cygwin programs, and the worst of all - a
> proprietary compiler based on cygwin, must be in PATH. AFAIR, the
> presence of cygwin in PATH broken shell scripting.
If it is a PATH issue, then it should be fixable by teaching msysGit to
prepend $GIT_ROOT/bin and $GIT_ROOT/libexec/git-core to the PATH, but
AFAIR we already do that.
*clicketyclick*
Yep, from reading setup_path() in exec_cmd.c, it appears that we prepend
the PATH correctly.
Traditionally, we did have problems with Cygwin, that is correct, but I
think with your help we can resolve the interaction issues.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Define a version of lstat(2) with posix semantics
From: Rogan Dawes @ 2009-03-20 13:49 UTC (permalink / raw)
To: Alex Riesen
Cc: Johannes Schindelin, Git Mailing List, Johannes Sixt, Jeff King,
layer, Junio C Hamano
In-Reply-To: <81b0412b0903200639v6d99067csb7715d9a5a3f0ba4@mail.gmail.com>
Alex Riesen wrote:
> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> On Fri, 20 Mar 2009, Alex Riesen wrote:
>>
>>> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>>> Now, we _do_ have msysGit, you _do_ have shown the capability to fix
>>>> issues when they arise, so I do _not_ see any obstacle why you should
>>>> not go msysGit, rather than staying with the pain of trying to stay
>>>> POSIX-compatible, but not quite all the time.
>>> I understand. It is not pure POSIX compatibility I seek. I just can't
>>> use MinGW port, because I absolutely must use the cygwin environment
>>> (for "hysterical" reasons) and they don't play well together (tried,
>>> yes. Conflicting libraries, but you already know that).
>> Maybe we can work on those conflicting libraries? After all, we do have a
>> "rebase.exe" tool now (for all those as puzzled by the naming as I was:
>> the rebase.exe tool can shift the memory range used by a .dll so that it
>> does not overlap with that one of another .dll).
>
> As long as they can be made to coexist I'm fine. Wasn't the problem
> that MinGW/MSYS used cygwin1.dll if it were in PATH? Or was it
> something else with their supporting libraries?
>
> My other problem is that the cygwin programs, and the worst of all - a
> proprietary compiler based on cygwin, must be in PATH. AFAIR, the
> presence of cygwin in PATH broken shell scripting.
How about a wrapper that fixes the PATH before exec'ing git? i.e.
removes cygwin and the compiler.
Rogan
^ permalink raw reply
* Re: [PATCH] Define a version of lstat(2) with posix semantics
From: Alex Riesen @ 2009-03-20 13:39 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Git Mailing List, Johannes Sixt, Jeff King, layer, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0903201015270.10279@pacific.mpi-cbg.de>
2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> On Fri, 20 Mar 2009, Alex Riesen wrote:
>
>> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>> > Now, we _do_ have msysGit, you _do_ have shown the capability to fix
>> > issues when they arise, so I do _not_ see any obstacle why you should
>> > not go msysGit, rather than staying with the pain of trying to stay
>> > POSIX-compatible, but not quite all the time.
>>
>> I understand. It is not pure POSIX compatibility I seek. I just can't
>> use MinGW port, because I absolutely must use the cygwin environment
>> (for "hysterical" reasons) and they don't play well together (tried,
>> yes. Conflicting libraries, but you already know that).
>
> Maybe we can work on those conflicting libraries? After all, we do have a
> "rebase.exe" tool now (for all those as puzzled by the naming as I was:
> the rebase.exe tool can shift the memory range used by a .dll so that it
> does not overlap with that one of another .dll).
As long as they can be made to coexist I'm fine. Wasn't the problem
that MinGW/MSYS used cygwin1.dll if it were in PATH? Or was it
something else with their supporting libraries?
My other problem is that the cygwin programs, and the worst of all - a
proprietary compiler based on cygwin, must be in PATH. AFAIR, the
presence of cygwin in PATH broken shell scripting.
^ permalink raw reply
* Re: [PATCH 2/2] Allow http authentication via prompt for http push.
From: Michael J Gruber @ 2009-03-20 13:25 UTC (permalink / raw)
To: Amos King; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <d8c371a80903200538t71adbca5hc11aae2ea1e36c9@mail.gmail.com>
Amos King venit, vidit, dixit 20.03.2009 13:38:
> Where are the typos and I will fix them?
I'll respond to this only, everything else has been said already.
> There is now a faux remote created in order to
> be passed to http_init.
...
> + * This is a faked remote so that http_init can
> + * get the correct data for builidng out athorization.
Obviously:
"builidng" -> "building"
"athorization" -> "authorization"
Up for discussion:
"out" -> "our"/"up"/""
"build out" isn't that common and doesn't seem to apply here: In order
to build something out that something must exist already. You can build
up something from the ground.
"faux" -> "fake"
"faked" -> "fake"
Both changes go for a more common, simplified wording. It's only a
comment, though. No one would have cared about those.
Michael
^ permalink raw reply
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch
From: Matthieu Moy @ 2009-03-20 13:05 UTC (permalink / raw)
To: Andreas Gruenbacher
Cc: Santi Béjar, Johannes Schindelin, Wincent Colaiuta,
Shawn O. Pearce, Junio C Hamano, Petr Baudis, git
In-Reply-To: <200903201345.23864.agruen@suse.de>
Andreas Gruenbacher <agruen@suse.de> writes:
> For me this defeats the purpose; I can just as well type origin/branch (or
> whatever it is) instead of branch^{origin}. I'm really looking for something
> very short like % or %branch.
I was thinking of ../branch (so, replace % with ../ in your patch,
roughly). The cool thing is that my fingers are used to ../ already.
The bad things are 1) not sure the "analogy" with .. in filesystem is
good, and 2) this interacts badly with ref..branch. ref..%branch was
cool, ref..../branch is less cool.
Or is //branch an idea?
My 2 cents,
--
Matthieu
^ permalink raw reply
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch
From: Mikael Magnusson @ 2009-03-20 12:53 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Santi Béjar, Wincent Colaiuta, Shawn O. Pearce,
Junio C Hamano, Petr Baudis, Andreas Gruenbacher, git
In-Reply-To: <alpine.DEB.1.00.0903201345190.6865@intel-tinevez-2-302>
2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Fri, 20 Mar 2009, Santi Béjar wrote:
>
>> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>>
>> > On Fri, 20 Mar 2009, Wincent Colaiuta wrote:
>> >
>> >> El 20/3/2009, a las 10:29, Johannes Schindelin escribió:
>> >>
>> >> >Often, it is quite interesting to inspect the branch tracked by a
>> >> >given branch. This patch introduces a nice notation to get at the
>> >> >tracked branch: 'BEL<branch>' can be used to access that tracked
>> >> >branch.
>> >> >
>> >> >A special shortcut 'BEL' refers to the branch tracked by the current
>> >> >branch.
>> >> >
>> >> >Suggested by Pasky and Shawn.
>> >>
>> >> What does BEL actually stand for? I read Shawn's suggestion, but it's
>> >> not immediately clear to me what "BEL" means.
>> >
>> > It is the ASCII "bell" character, 007 (I always wanted to write that
>> > magic identifier into a patch).
>> >
>> > FWIW you could type it in a regular ANSI terminal using Control-v
>> > Control-g.
>>
>> Can we use branch^{origin} instead? It is longer to type, but uses the
>> same syntax as the ^{tree}, ^{commit}, ^{tag} and you don't have to know
>> how to produce the bell character.
>
> I think I addressed that issue already. (Summary: I do not like it)
>
> Let me spell it out if it was not obvious yet: the BEL patch was meant as
> a more or less funny reminder that the issue is not solved and that I need
> help.
Would :%:foo work? I thought about the reserved prefix :/! , but :/!!
isn't reserved so I don't think that would work. And it's pretty
annoying to type too.
--
Mikael Magnusson
^ permalink raw reply
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch
From: Andreas Gruenbacher @ 2009-03-20 12:45 UTC (permalink / raw)
To: Santi Béjar
Cc: Johannes Schindelin, Wincent Colaiuta, Shawn O. Pearce,
Junio C Hamano, Petr Baudis, git
In-Reply-To: <adf1fd3d0903200533s2be08ee7t58a22180b1c886c0@mail.gmail.com>
On Friday, 20 March 2009 13:33:18 Santi Béjar wrote:
> Can we use branch^{origin} instead? It is longer to type, but uses the
> same syntax as the ^{tree}, ^{commit}, ^{tag} and you don't have to
> know how to produce the bell character.
For me this defeats the purpose; I can just as well type origin/branch (or
whatever it is) instead of branch^{origin}. I'm really looking for something
very short like % or %branch.
A notation for referring to the tracked branch in arbitrary contexts still
sounds like a good idea, and for that purpose, your proposal sounds useful.
Thanks,
Andreas
^ permalink raw reply
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-20 12:46 UTC (permalink / raw)
To: Santi Béjar
Cc: Wincent Colaiuta, Shawn O. Pearce, Junio C Hamano, Petr Baudis,
Andreas Gruenbacher, git
In-Reply-To: <adf1fd3d0903200533s2be08ee7t58a22180b1c886c0@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1370 bytes --]
Hi,
On Fri, 20 Mar 2009, Santi Béjar wrote:
> 2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > On Fri, 20 Mar 2009, Wincent Colaiuta wrote:
> >
> >> El 20/3/2009, a las 10:29, Johannes Schindelin escribió:
> >>
> >> >Often, it is quite interesting to inspect the branch tracked by a
> >> >given branch. This patch introduces a nice notation to get at the
> >> >tracked branch: 'BEL<branch>' can be used to access that tracked
> >> >branch.
> >> >
> >> >A special shortcut 'BEL' refers to the branch tracked by the current
> >> >branch.
> >> >
> >> >Suggested by Pasky and Shawn.
> >>
> >> What does BEL actually stand for? I read Shawn's suggestion, but it's
> >> not immediately clear to me what "BEL" means.
> >
> > It is the ASCII "bell" character, 007 (I always wanted to write that
> > magic identifier into a patch).
> >
> > FWIW you could type it in a regular ANSI terminal using Control-v
> > Control-g.
>
> Can we use branch^{origin} instead? It is longer to type, but uses the
> same syntax as the ^{tree}, ^{commit}, ^{tag} and you don't have to know
> how to produce the bell character.
I think I addressed that issue already. (Summary: I do not like it)
Let me spell it out if it was not obvious yet: the BEL patch was meant as
a more or less funny reminder that the issue is not solved and that I need
help.
Ciao,
Dscho
^ permalink raw reply
* Re: git-push on packed refs via HTTP
From: Johannes Schindelin @ 2009-03-20 12:45 UTC (permalink / raw)
To: Steve; +Cc: git
In-Reply-To: <loom.20090320T123018-838@post.gmane.org>
Hi,
On Fri, 20 Mar 2009, Steve wrote:
> > could you try running git update-server-info?
>
> Forgot to mention that: I have tried git update-server-info, yet no
> luck.
Actually, you have to undo the ref-packing performed by gc. You can do it
this way (quick and dirty):
$ git show-ref |
while read sha1 name
do
mkdir -p .git/$(dirname $name) &&
echo $sha1 > .git/$name
done
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH 2/2] Allow http authentication via prompt for http push.
From: Amos King @ 2009-03-20 12:38 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <49C35891.7010004@drmicha.warpmail.net>
Where are the typos and I will fix them?
As far as my response, I will only apologize for my choice of words
and not my message. Being rude does not encourage developers to
continue to try to improve git. Almost every time I see Dscho respond
he says something about the little precious time he has, but doesn't
seem to respect the fact that other people are taking their precious
free time to prepare and submit the patches. Continue with rude
comments and you will lose great developer after great developer.
Again I am sorry for the words I chose, and it was uncalled for.
Before anyone responded to my email I sent this to Dscho:
> Sorry for the way I responded. It was not very appropriate of me. I
> do think that if you would take a little tact in your approach that
> you would keep developers trying to improve the code they are putting
> into git, and trying to contribute more often.
Amos
On Fri, Mar 20, 2009 at 3:49 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Amos King venit, vidit, dixit 19.03.2009 20:02:
>> The issue with calling it remote is that it conflicts with the remote
>> struct that is need for http_init, and is used in the rest of the
>> code. So do you want me to make this small impact change or a larger
>> and more broad sweeping change by changing the name of the other
>> remote. I don't believe fake is a better name. I would hope that at
>> some point the 'repo' struct would go away and we can make http_push
>> work like all the other remote commands.
>>
>> I also believe that 'out' is the correct word. It was not a typo, and
>> I appreciate your suggestion of assuming that I can't spell just
>> because I used a word that you didn't understand. I'm not building
>> OUR authorization. I am building OUT authorization. Have you heard
>> of building something out? Or even fleshing something out?
>>
>> I appreciated your first responses to my other patch. Even if your
>> tone was that of a person with low self-esteem who needs to pick
>> unimportant details apart in order to stroke their own ego. Instead
>> of responding in the same tone I thought I would respond nicely and
>> get your feedback. Responses like your first one don't cause people
>> to want to continue to contribute to the community.
>>
>> I have a great idea. Why don't you try using the 'nice' tense in your
>> next email instead of the high and mighty 'ass-hole' tense. Then I
>> will gladly not use past tense in my commit messages, and others might
>> respond more positively to your criticisms.
>>
>> Fiek Dich,
>> Amos
>
> We don't want these obscenities on this list, whether in plain English
> or wrong German!
>
> In fact, Dscho's criticism was not only constructive but nice, and not
> only by his standards.
>
> You managed to have at least 2 (3 by our count) typos in one line, and
> Dscho pointed that out correctly and nicely.
>
> Your second response (which I saw just before hitting send) doesn't show
> much new insight regarding the latter two points. I'll consider the
> first one dealt with by it.
>
> Michael
>
>> On Thu, Mar 19, 2009 at 11:59 AM, Johannes Schindelin
>> <Johannes.Schindelin@gmx.de> wrote:
>>> Hi,
>>>
>>> On Thu, 19 Mar 2009, Amos King wrote:
>>>
>>>> There is now a faux remote created in order to
>>>> be passed to http_init.
>>>>
>>>> Signed-off-by: Amos King <amos.l.king@gmail.com>
>>>> ---
>>>> http-push.c | 11 ++++++++++-
>>>> 1 files changed, 10 insertions(+), 1 deletions(-)
>>>>
>>>> diff --git a/http-push.c b/http-push.c
>>>> index 9ac2664..468d5af 100644
>>>> --- a/http-push.c
>>>> +++ b/http-push.c
>>>> @@ -2195,7 +2195,16 @@ int main(int argc, char **argv)
>>>>
>>>> memset(remote_dir_exists, -1, 256);
>>>>
>>>> - http_init(NULL);
>>>> + /*
>>>> + * This is a faked remote so that http_init can
>>>> + * get the correct data for builidng out athorization.
>>>> + */
>>>
>>> You might want to pass this through aspell ;-) Altough it will not
>>> suggest 'out ->our', I guess...
>>>
>>>> + struct remote *remote;
>>>> + remote = xcalloc(sizeof(*remote), 1);
>>>> + ALLOC_GROW(remote->url, remote->url_nr + 1, remote->url_alloc);
>>>> + remote->url[remote->url_nr++] = repo->url;
>>>> +
>>>> + http_init(remote);
>>>
>>> Would 'fake' not be a more appropriate name than 'remote'?
>>>
>>> That would also make the patch 1/2 rather unnecessary (I also have to
>>> admit that I do not find 'repo' a better name, as we have a repository
>>> both locally and remotely, and this _is_ the remote repository, not the
>>> local one).
>>>
>>> Ciao,
>>> Dscho
>>>
>>>
>>
>>
>>
>
>
--
Amos King
http://dirtyInformation.com
http://github.com/Adkron
--
Looking for something to do? Visit http://ImThere.com
^ permalink raw reply
* Re: [PATCH v3] Introduce BEL<branch> as shortcut to the tracked branch
From: Santi Béjar @ 2009-03-20 12:33 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Wincent Colaiuta, Shawn O. Pearce, Junio C Hamano, Petr Baudis,
Andreas Gruenbacher, git
In-Reply-To: <alpine.DEB.1.00.0903201053280.10279@pacific.mpi-cbg.de>
2009/3/20 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Fri, 20 Mar 2009, Wincent Colaiuta wrote:
>
>> El 20/3/2009, a las 10:29, Johannes Schindelin escribió:
>>
>> >
>> >Often, it is quite interesting to inspect the branch tracked by a given
>> >branch. This patch introduces a nice notation to get at the tracked
>> >branch: 'BEL<branch>' can be used to access that tracked branch.
>> >
>> >A special shortcut 'BEL' refers to the branch tracked by the current branch.
>> >
>> >Suggested by Pasky and Shawn.
>>
>> What does BEL actually stand for? I read Shawn's suggestion, but it's not
>> immediately clear to me what "BEL" means.
>
> It is the ASCII "bell" character, 007 (I always wanted to write that
> magic identifier into a patch).
>
> FWIW you could type it in a regular ANSI terminal using Control-v
> Control-g.
Can we use branch^{origin} instead? It is longer to type, but uses the
same syntax as the ^{tree}, ^{commit}, ^{tag} and you don't have to
know how to produce the bell character.
2 cents,
Santi
^ permalink raw reply
* Re: git-push on packed refs via HTTP
From: Steve @ 2009-03-20 12:31 UTC (permalink / raw)
To: git
In-Reply-To: <be6fef0d0903200500u4d26d00fm653bc1e708a0c26b@mail.gmail.com>
> could you try running git update-server-info?
Forgot to mention that: I have tried git update-server-info, yet no luck.
^ permalink raw reply
* Re: git-push on packed refs via HTTP
From: Tay Ray Chuan @ 2009-03-20 12:00 UTC (permalink / raw)
To: Steve; +Cc: git
In-Reply-To: <loom.20090320T094550-421@post.gmane.org>
Hi,
On Fri, Mar 20, 2009 at 5:50 PM, Steve <shrotty@gmx.ch> wrote:
> Using HTTP as transport, I've noticed that after using git-gc on a git server, I
> can't push to that repo anymore: "No refs in common and none specified." Client
> and server are both 1.6.2. Is ths a bug or do I have to do something after
> executing git-gc on the server?
could you try running git update-server-info?
--
Cheers,
Ray Chuan
^ permalink raw reply
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-20 11:57 UTC (permalink / raw)
To: Petr Baudis
Cc: Junio C Hamano, Jeff King, Shawn O. Pearce, Andreas Gruenbacher,
git
In-Reply-To: <20090320115043.GB8940@machine.or.cz>
Hi,
On Fri, 20 Mar 2009, Petr Baudis wrote:
> On Fri, Mar 20, 2009 at 12:46:19PM +0100, Johannes Schindelin wrote:
>
> > On Fri, 20 Mar 2009, Petr Baudis wrote:
> >
> > > On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:
> > > > On Thu, 19 Mar 2009, Junio C Hamano wrote:
> > > >
> > > > > I think you are right. It is just "git branch" and perhaps "git
> > > > > update-ref" are too loose in enforcing what can be created.
> > > >
> > > > "git branch" I agree with, but not "git update-ref". As plumbing, the
> > > > latter should be much more allowing, feeding rope aplenty (but also
> > > > allowing cool tricks we do not think about yet).
> > >
> > > We shouldn't allow creating insane ref names even with update-ref. That
> > > way porcelains cannot rely on update-ref to sanity check the user's
> > > crap. At most, maybe you might want to bypass this check with some force
> > > switch, though I really can't quite imagine why.
> >
> > You really cannot imagine? You, the author of filter-branch? People _do_
> > have fscked-up repositories, but they get really angry when they cannot
> > use rebase or filter-branch on them.
>
> They can rename the ref as the first step of a cleanup, can't they?
Well, of course, we can make life hard on everybody. That is quite
possible.
But then, we can be nice, and at the same time fix the problem _properly_.
IMHO a _warning_ should be the best thing.
But all this does not solve _my_ problem: I'd like something as easy to
write as %next, but as unlikely to be used in existing refs as @{..}.
Ciao,
Dscho
^ permalink raw reply
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Petr Baudis @ 2009-03-20 11:50 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Jeff King, Shawn O. Pearce, Andreas Gruenbacher,
git
In-Reply-To: <alpine.DEB.1.00.0903201245140.6865@intel-tinevez-2-302>
On Fri, Mar 20, 2009 at 12:46:19PM +0100, Johannes Schindelin wrote:
> Hi,
>
> On Fri, 20 Mar 2009, Petr Baudis wrote:
>
> > On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:
> > > On Thu, 19 Mar 2009, Junio C Hamano wrote:
> > >
> > > > I think you are right. It is just "git branch" and perhaps "git
> > > > update-ref" are too loose in enforcing what can be created.
> > >
> > > "git branch" I agree with, but not "git update-ref". As plumbing, the
> > > latter should be much more allowing, feeding rope aplenty (but also
> > > allowing cool tricks we do not think about yet).
> >
> > We shouldn't allow creating insane ref names even with update-ref. That
> > way porcelains cannot rely on update-ref to sanity check the user's
> > crap. At most, maybe you might want to bypass this check with some force
> > switch, though I really can't quite imagine why.
>
> You really cannot imagine? You, the author of filter-branch? People _do_
> have fscked-up repositories, but they get really angry when they cannot
> use rebase or filter-branch on them.
They can rename the ref as the first step of a cleanup, can't they?
--
Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr
^ permalink raw reply
* Re: [PATCH] Document and test the new % shotcut for the tracked branch
From: Johannes Schindelin @ 2009-03-20 11:48 UTC (permalink / raw)
To: Petr Baudis
Cc: Michael J Gruber, git, Shawn O. Pearce, Andreas Gruenbacher,
Junio C Hamano
In-Reply-To: <20090320111656.GA8940@machine.or.cz>
Hi,
On Fri, 20 Mar 2009, Petr Baudis wrote:
> On Fri, Mar 20, 2009 at 11:31:31AM +0100, Johannes Schindelin wrote:
> > I had it ready yesterday! But the real problem is not addressed by
> > your patch, either: '%<branch>' is a legal branch name.
> >
> > I briefly considered <branch>^{tracked}, but
> >
> > - the ^{} codepath does not try to substitute branch _names_, so we'd
> > have to duplicate that ^{} detection, and,
> >
> > - it is really cumbersome to write.
>
> We already have @{N} to do one branch-based substitution, so what about
> following this convention? Can't we have @{t}?
Have you ever tried a German keyboard layout? You would not say that @{}
is easy to write if you did.
Besides, @{<string>} is already taken for the date-based reflog.
Ciao,
Dscho
^ permalink raw reply
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Johannes Schindelin @ 2009-03-20 11:46 UTC (permalink / raw)
To: Petr Baudis
Cc: Junio C Hamano, Jeff King, Shawn O. Pearce, Andreas Gruenbacher,
git
In-Reply-To: <20090320111238.GZ8940@machine.or.cz>
Hi,
On Fri, 20 Mar 2009, Petr Baudis wrote:
> On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:
> > On Thu, 19 Mar 2009, Junio C Hamano wrote:
> >
> > > I think you are right. It is just "git branch" and perhaps "git
> > > update-ref" are too loose in enforcing what can be created.
> >
> > "git branch" I agree with, but not "git update-ref". As plumbing, the
> > latter should be much more allowing, feeding rope aplenty (but also
> > allowing cool tricks we do not think about yet).
>
> We shouldn't allow creating insane ref names even with update-ref. That
> way porcelains cannot rely on update-ref to sanity check the user's
> crap. At most, maybe you might want to bypass this check with some force
> switch, though I really can't quite imagine why.
You really cannot imagine? You, the author of filter-branch? People _do_
have fscked-up repositories, but they get really angry when they cannot
use rebase or filter-branch on them.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Document and test the new % shotcut for the tracked branch
From: Petr Baudis @ 2009-03-20 11:16 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Michael J Gruber, git, Shawn O. Pearce, Andreas Gruenbacher,
Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0903201128380.10279@pacific.mpi-cbg.de>
Hi!
On Fri, Mar 20, 2009 at 11:31:31AM +0100, Johannes Schindelin wrote:
> I had it ready yesterday! But the real problem is not addressed by your
> patch, either: '%<branch>' is a legal branch name.
>
> I briefly considered <branch>^{tracked}, but
>
> - the ^{} codepath does not try to substitute branch _names_, so we'd have
> to duplicate that ^{} detection, and,
>
> - it is really cumbersome to write.
We already have @{N} to do one branch-based substitution, so what about
following this convention? Can't we have @{t}?
Petr "Pasky" Baudis
^ permalink raw reply
* Re: ref name troubles, was Re: [PATCH v2] Introduce %<branch> as shortcut to the tracked branch
From: Petr Baudis @ 2009-03-20 11:12 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Junio C Hamano, Jeff King, Shawn O. Pearce, Andreas Gruenbacher,
git
In-Reply-To: <alpine.DEB.1.00.0903201029290.10279@pacific.mpi-cbg.de>
Hi!
On Fri, Mar 20, 2009 at 10:30:29AM +0100, Johannes Schindelin wrote:
> On Thu, 19 Mar 2009, Junio C Hamano wrote:
>
> > I think you are right. It is just "git branch" and perhaps "git
> > update-ref" are too loose in enforcing what can be created.
>
> "git branch" I agree with, but not "git update-ref". As plumbing, the
> latter should be much more allowing, feeding rope aplenty (but also
> allowing cool tricks we do not think about yet).
We shouldn't allow creating insane ref names even with update-ref. That
way porcelains cannot rely on update-ref to sanity check the user's
crap. At most, maybe you might want to bypass this check with some force
switch, though I really can't quite imagine why.
--
Petr "Pasky" Baudis
The average, healthy, well-adjusted adult gets up at seven-thirty
in the morning feeling just terrible. -- Jean Kerr
^ permalink raw reply
* Re: git-push on packed refs via HTTP
From: Steve @ 2009-03-20 10:50 UTC (permalink / raw)
To: git
In-Reply-To: <49C3721E.7000005@op5.se>
> I had this happen once after having upgraded git on the server in question and
> then running "git gc" against a repo. I didn't remove the old (not packed-refs
> knowing) git though, and when I later tried to push to it, it couldn't find
> any refs since the old receive-pack was being used, and it didn't know about
> packed refs.
Which file/contents do I have to look for or remove in order to kick the old not
packed refs?
^ permalink raw reply
* Re: [PATCH] Document and test the new % shotcut for the tracked branch
From: Michael J Gruber @ 2009-03-20 10:38 UTC (permalink / raw)
To: Johannes Schindelin
Cc: git, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher,
Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0903201128380.10279@pacific.mpi-cbg.de>
Johannes Schindelin venit, vidit, dixit 20.03.2009 11:31:
> Hi,
>
> On Fri, 20 Mar 2009, Michael J Gruber wrote:
>
>> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
>> ---
>
> That is brutal. First shot, then cut.
I'm sorry! But you're a tough guy, you'll recover...
>
>> Johannes Schindelin venit, vidit, dixit 20.03.2009 10:29:
>>>
>>> Often, it is quite interesting to inspect the branch tracked by a
>>> given branch. This patch introduces a nice notation to get at the
>>> tracked branch: 'BEL<branch>' can be used to access that tracked
>>> branch.
>>>
>>> A special shortcut 'BEL' refers to the branch tracked by the current
>>> branch.
>>>
>>> Suggested by Pasky and Shawn.
>>>
>>> This patch extends the function introduced to handle the nth-last
>>> branch (via the {-<n>} notation); therefore that function name was
>>> renamed to something more general.
>>>
>>> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>>
>> I guess you beat me to it then, which is fine.
>
> I had it ready yesterday! But the real problem is not addressed by your
> patch, either: '%<branch>' is a legal branch name.
No, of course, I just added doc+test to your patch v2, since you seemed
to encourage people to do so.
I would have sent it out yesterday if my tests hadn't shown a problem.
(Or did you misunderstand my doc notation? <branch> = ${branch} =
"branch" placeholder for a generic branch name)
> I briefly considered <branch>^{tracked}, but
>
> - the ^{} codepath does not try to substitute branch _names_, so we'd have
> to duplicate that ^{} detection, and,
>
> - it is really cumbersome to write.
>
>> But haven't you seen my note about the failing test either? The code
>> below tests with branches which track local branches. merge and remote
>> is set for the branch in question ("tracking"), it's just that remote is
>> ".". It seems that the remote.c code does not set up merge info for
>> these branches.
>
> I have seen it, it's just not my itch, and I am busy enough as it is.
If I'm not totally off-track (which I may well be) then that problem
should show up with other uses of the merge/track setting as well. I
guess it's just that everyone tracks remote branches, not local ones.
I'll see if I have time...
>> <Goes to figure out how to enter BEL...>
>
> Ctrl-v Ctrl-g
>
> Ciao,
> Dscho
Bing bing bing...
Michael
^ permalink raw reply
* Re: git-push on packed refs via HTTP
From: Andreas Ericsson @ 2009-03-20 10:38 UTC (permalink / raw)
To: Steve; +Cc: git
In-Reply-To: <loom.20090320T094550-421@post.gmane.org>
Steve wrote:
> Hi
>
> Using HTTP as transport, I've noticed that after using git-gc on a git server, I
> can't push to that repo anymore: "No refs in common and none specified." Client
> and server are both 1.6.2. Is ths a bug or do I have to do something after
> executing git-gc on the server?
>
I had this happen once after having upgraded git on the server in question and
then running "git gc" against a repo. I didn't remove the old (not packed-refs
knowing) git though, and when I later tried to push to it, it couldn't find
any refs since the old receive-pack was being used, and it didn't know about
packed refs.
Worth checking, possibly.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: git-p4 workflow suggestions?
From: Sam Hocevar @ 2009-03-20 10:31 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: git
In-Reply-To: <20090317151815.GA2451@padd.com>
On Tue, Mar 17, 2009, Pete Wyckoff wrote:
> Can you take a look at the attached. Its goal is purely to allow
> you to clone a complex spec like yours above. You may have to merge
> this in with your perrformance changes.
>
> Edit your ~/.gitconfig to add a section:
>
> [git-p4]
> useClientSpec = true
>
> Then copy a good P4ENV from a p4 client that has a client spec
> checked out as you like. git-p4 clone will do "p4 client -o",
> reading that spec, and use the results to import, hopefully as
> you have things laid out in the spec.
>
> If this seems to work for you, we can figure out how to clean up
> the patch so it can be used generally by people with and without
> client specs.
I am afraid I don't know what a "P4ENV" is. However, our P4
repository is set up in such a way that "p4 client -o" shows the
expected mappings, so I just commented out the P4ENV check and I finally
managed to clone my gigantic repository.
One concern: git-p4 clone creates .git in the current directory and
it caused me to do at least one unfortunate "rm -rf .git". I would
expect clone to create a subdirectory.
Apart from that, "clone" seems to work rather well. I haven't tried
to submit a commit yet, though.
--
Sam.
^ permalink raw reply
* Re: [PATCH] Document and test the new % shotcut for the tracked branch
From: Johannes Schindelin @ 2009-03-20 10:31 UTC (permalink / raw)
To: Michael J Gruber
Cc: git, Shawn O. Pearce, Petr Baudis, Andreas Gruenbacher,
Junio C Hamano
In-Reply-To: <1237543471-27248-1-git-send-email-git@drmicha.warpmail.net>
Hi,
On Fri, 20 Mar 2009, Michael J Gruber wrote:
> Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
> ---
That is brutal. First shot, then cut.
> Johannes Schindelin venit, vidit, dixit 20.03.2009 10:29:
> >
> > Often, it is quite interesting to inspect the branch tracked by a
> > given branch. This patch introduces a nice notation to get at the
> > tracked branch: 'BEL<branch>' can be used to access that tracked
> > branch.
> >
> > A special shortcut 'BEL' refers to the branch tracked by the current
> > branch.
> >
> > Suggested by Pasky and Shawn.
> >
> > This patch extends the function introduced to handle the nth-last
> > branch (via the {-<n>} notation); therefore that function name was
> > renamed to something more general.
> >
> > Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
>
> I guess you beat me to it then, which is fine.
I had it ready yesterday! But the real problem is not addressed by your
patch, either: '%<branch>' is a legal branch name.
I briefly considered <branch>^{tracked}, but
- the ^{} codepath does not try to substitute branch _names_, so we'd have
to duplicate that ^{} detection, and,
- it is really cumbersome to write.
> But haven't you seen my note about the failing test either? The code
> below tests with branches which track local branches. merge and remote
> is set for the branch in question ("tracking"), it's just that remote is
> ".". It seems that the remote.c code does not set up merge info for
> these branches.
I have seen it, it's just not my itch, and I am busy enough as it is.
> <Goes to figure out how to enter BEL...>
Ctrl-v Ctrl-g
Ciao,
Dscho
^ 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