* Re: [PATCH v2] Add --track option to git clone
From: David Soria Parra @ 2009-12-02 19:27 UTC (permalink / raw)
To: git
In-Reply-To: <20091202190807.GB30778@coredump.intra.peff.net>
On 2009-12-02, Jeff King <peff@peff.net> wrote:
> 1. Add "--track foo" as a convenience wrapper for "-f foo -b foo".
>
> 2. If no "-b" is given, the first "-f" is assumed as "-b". So "git
> clone -f foo" becomes equivalent to David's --track.
>
> And of course the name "-f" (for --fetch, if you were wondering) is open
> to suggestion.
>
> What do you think?
>
This approach is much better than my initial proposal. Sadly I won't have time
to implement this, which is why I wrote the simplest working solution for me.
Fetch seems to reasonable. I can rewrite the patch to be able to use refspecs, but
it would require additional refactoring to be able to specify multiple --fetch parameters.
David
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC 06/11] run-command: add kill_async() and is_async_alive()
From: Johannes Sixt @ 2009-12-02 19:27 UTC (permalink / raw)
To: kusmabite; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <40aa078e0912020757i3b63ef6eh71c3d4d99047f1f2@mail.gmail.com>
On Mittwoch, 2. Dezember 2009, Erik Faye-Lund wrote:
> On Fri, Nov 27, 2009 at 8:59 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> > "relatively small chance of stuff blowing up"? The docs of
> > TerminateThread: "... the kernel32 state for the thread's process could
> > be inconsistent." That's scary if we are talking about a process that
> > should run for days or weeks without interruption.
>
> I think there's a misunderstanding here. I thought your suggestion was
> to simply call die(), which would take down the main process. After
> reading this explanation, I think you're talking about giving an error
> and rejecting the connection instead. Which makes more sense than to
> risk crashing the main-process, indeed.
Just rejecting a connection is certainly the simplest do to keep the daemon
process alive. But the server can be DoS-ed from a single source IP.
Currently git-daemon can only be DDoS-ed because there is a maximum number of
connections, which are not closed if all of them originate from different
IPs.
> > Case 2 could be achieved by using setsockopt() with SO_RCVTIMEO and
> > SO_SNDTIMEO and a tiny timeout. But notice that we would set a timeout in
> > one thread while another thread is waiting in ReadFile() or WriteFile().
> > Would that work?
>
> I think it should work fine, but I won't give you a guarantee ;)
> Perhaps we should have a configurable global max timeout, and just set
> that on all sockets? Or does this open for DDOS attacks?
I'm sure that there is a global timeout already, but it is in the order of
minutes, which is too long. Here I mean it to be set to zero or one
milli-second so that the connection closes right away - as if the process on
the server side had been killed.
Hm - perhaps it is possible to really *close* the socket while some other
thread waits in ReadFile() or WriteFile()?
-- Hannes
^ permalink raw reply
* Re: [PATCH] builtin-commit: add --date option
From: Jeff King @ 2009-12-02 19:26 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <1259627252-21615-1-git-send-email-vmiklos@frugalware.org>
On Tue, Dec 01, 2009 at 01:27:32AM +0100, Miklos Vajna wrote:
> This is useful in case git commit --amend is used but the user wants to
> set the date of the new commit to a specified one, since GIT_AUTHOR_DATE
> is ignored in such a situation.
Do you really want to set the date to something arbitrary, or do you
just want to set it to "now"? If the latter case, do you really just
want the recently discussed --reset-author?
Also, is there a good reason why GIT_AUTHOR_DATE is not respected in
this case? If not, should we simply be fixing that bug instead?
-Peff
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Ilari Liusvaara @ 2009-12-02 19:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, Johannes Schindelin, git
In-Reply-To: <7vk4x5fcbf.fsf@alter.siamese.dyndns.org>
On Wed, Dec 02, 2009 at 10:41:40AM -0800, Junio C Hamano wrote:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>
> >> Of course, I never understood why the backend should know the
> >> implementation detail that it is based on cURL, so it would be even more
> >> modular (at least by my definition) if there was no hard-coded mapping.
> >
> > Agreed.
>
> I don't get this point at all.
>
> Backend is _very_ aware of how it is implemented itself. Naming one
> implementation git-remote-http is to declare that "I am the one and only
> implementation of http handler" and forces another implementation of http
> handler, perhaps based on different toolkit than libcurl, to forever be a
> second class citizen that need to use name other than 'http'.
At least it can be called as 'foo::http://' (That may be tolerable for
alternate implementations but not for primary ones).
> The "mapping" you two are calling "hard-coded" may be "hard-coded" but is
> a better kind of hard-coding than hard-coding "http" to "this particular
> implementation" implicitly like you two seem to be advocating. Think of
> it as having one extra layer of indirection.
Its already indirected: By filesystem.
> When the second implementation of http handler proves to be better than
> the current one, we can flip the mapping, and anybody who were using
> "http://" to access some repository will automatically updated to use the
> new backend instead of the old one. With your scheme, you probably could
> change the name of the old "http" backend to "http-deprecated" and the new
> one from "second-class-citizen-http" to "http" to achieve a similar
> effect, but I do not think it is as nice as having one extra level of
> indirection.
The new HTTP support must either be internal or not. And:
- If it is internal, renaming can be done anyway.
- If it is not, change can not be made.
And at package manager level, this is what 'conflicts: ' is about (and
alternates of apt).
> > However, I am not convinced that we should do any magic to map
> > "foo://" to git-remote-foo. On the other hand, I do think it makes
> > sense to have something modular that allows "git-remote-http" to be
> > implemented as a separate package that can be installed.
>
> As I said, I do think modular is good, but I think what Dscho is
> advocating does not have much to achieve that goal.
Why should adding new git native protocol (that doesn't have so special
capabilities new core support is fundamentially required) require recompiling
git core? Why it should require more than dropping executable handler to
suitable place?[*]
Why should such protocols need to be specified 'foo::foo://'?
Granted, even with current dispatch meachanisms, its possible to hack
together something that accepts 'foo:://', 'foo::/' or 'foo::' but that
breaks user expectations rather badly (the U in URL stands for 'uniform')...
And currently the URL space to be reassigned just produces fatal error
messages anyway.
[*] Merge strategies have similar issues. IMO, on encountering unknown
merge strategy, git merging code should check if there's handler for it,
if yes, obtain flags from it and then use it.
-Ilari
^ permalink raw reply
* Re: [PATCH] builtin-commit: add --date option
From: Jeff King @ 2009-12-02 19:24 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vpr6xgtxn.fsf@alter.siamese.dyndns.org>
On Wed, Dec 02, 2009 at 09:35:48AM -0800, Junio C Hamano wrote:
> > Is there any documentation describing what does parse_date() accept?
> [...]
> The above are all supported (you can label 2 as ISO even though the
> official ISO8601 wants "T" instead of " " between date and time).
>
> For more amusing ones, see
>
> http://article.gmane.org/gmane.comp.version-control.git/12241
>
> and follow the discussion there ;-)
Aren't the amusing ones the result of approxidate, and not parse_date?
At least that is my recollection from working on the date code when I
ate 30 hot dogs last August.
-Peff
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC 09/11] daemon: use run-command api for async serving
From: Johannes Sixt @ 2009-12-02 19:12 UTC (permalink / raw)
To: kusmabite; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <40aa078e0912020745o4b72342fm722a944621cfda5@mail.gmail.com>
On Mittwoch, 2. Dezember 2009, Erik Faye-Lund wrote:
> On Fri, Nov 27, 2009 at 9:59 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> > Would it make sense to
> > have a function finish_async_nowait() instead of is_async_alive() that
> > (1) stresses the start/finish symmetry and (2) can return more than just
> > Boolean?
>...
>
> I'm not entirely sure how to make the interface, though. Any good
> suggestions?
I suggest to model finish_async_nowait() after waitpid() so that
while ((pid = waitpid(-1, &status, WNOHANG)) > 0) ...
becomes
while ((pid = finish_async_nowait(&some_async, &status)) > 0) ...
but where the resulting status is already "decoded", i.e. zero is success and
non-zero is failure (including death through signal); WIFEXITED and
WEXITSTATUS should not be applicable to status anymore.
-- Hannes
^ permalink raw reply
* Re: [PATCH v2] Add --track option to git clone
From: Jeff King @ 2009-12-02 19:08 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: David Soria Parra, git
In-Reply-To: <20091202192028.6117@nanako3.lavabit.com>
On Wed, Dec 02, 2009 at 07:20:28PM +0900, Nanako Shiraishi wrote:
> Quoting David Soria Parra <sn_@gmx.net> writes:
>
> > I'm aware that it's not possible to give more than one --track
> > option. Implementing the possibility to specify multiple --track option
> > would certainly a good improvment later, but would also require a lot
> > more work as far as I understand the clone code.
>
> I'm sorry if I'm asking the obvious, but how can multiple --track
> options be a useful future enhancement? If I understand your use
> case correctly, it's useful when you want to work on only one
> branch that isn't the default, and that is why you don't want to
> get data necessary for other branches. What does it mean to give
> two --track options? You will get one master branch that tracks
> both versions, and "git pull" will merge both branches you track?
I would find something like this useful for cloning git.git, where I
explicitly fetch maint, master, next, and pu, but none of html, man, or
todo. This makes "gitk --all" much nicer to view.
However, I don't think --track is the right term. There are really two
things happening here:
1. Setting the fetch refspec(s).
2. Choosing an initial branch to checkout.
We can already do (2) with "-b". But there is no way to do (1)
currently. If we are going to implement (1), I don't see a reason to be
restrictive about it. We should really accept arbitrary refspecs, and
then provide a syntax on top of that for doing both (1) and (2)
together. I am thinking something like:
# most general case
git clone -f 'refs/heads/subset/*:refs/remotes/origin/*' remote.git
# expands to refs/heads/subset/*:refs/remotes/origin/*
git clone -f 'refs/heads/subset/*' remote.git
# expands to refs/heads/subset/*, which then expands as above
git clone -f 'subset/*' remote.git
# multiple -f should add multiple refspec lines
git clone -f maint -f master -f next -f pu git.git
# choose your favorite branch
git clone -f maint -f master -f next -f pu -b next git.git
And for convenience of the user, you would want a way to avoid repeating
the name of the "I want to check this out" branch. So either:
1. Add "--track foo" as a convenience wrapper for "-f foo -b foo".
2. If no "-b" is given, the first "-f" is assumed as "-b". So "git
clone -f foo" becomes equivalent to David's --track.
And of course the name "-f" (for --fetch, if you were wondering) is open
to suggestion.
What do you think?
-Peff
^ permalink raw reply
* Re: [PATCH] transport-helper: remove duplicate free()
From: Junio C Hamano @ 2009-12-02 19:06 UTC (permalink / raw)
To: Daniel Barkalow; +Cc: Tay Ray Chuan, git, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <alpine.LNX.2.00.0912021120440.14365@iabervon.org>
Daniel Barkalow <barkalow@iabervon.org> writes:
> On Wed, 2 Dec 2009, Tay Ray Chuan wrote:
>
>> Remove the free() invocation on transport->data in release_helper(), as
>> disconnect_helper() has already done so.
>
> You need to remove the one in disconnect_helper, because the entire point
> of disconnect_helper as opposed to release_helper is to *not* free that
> memory. If you remove this one, you'll access freed memory in any case
> where the helper has to be quit and restarted.
Thanks. I did two things:
- Since the bottom commit cannot be rewritten (as it is based on the
version that is before the change in the caller to free it), I queued a
one liner to remove the free from the callee in 'next'.
- The problem will surface when the series is later merged to 'master'.
I told my rerere database about the necessity of this "evil merge", so
that we will automatically have the equivalent of the one-liner when it
happens.
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Junio C Hamano @ 2009-12-02 18:58 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sverre Rabbelier, Johannes Schindelin, Ilari Liusvaara, git
In-Reply-To: <7v3a3tfbsx.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>
>> I don't see how what you are talking about is any different. With the
>> mapping the executable of the alternative implementation still needs
>> to have a different name, no?
>
> Sure, but please search for "second class citizen" in my message.
Also "extra level of indication".
I do not think "remote-curl" was the best name, and hindsight tells me
that "remote-walker" might have been a better name (it tells us how it
does it more clearly).
And I do not at all mind making the current hard-coded mapping from
http:// to remote-walker to an external table look-up, perhaps something
that can be controlled by .git/config, with a built-in default that is
hard-coded like the way we have now.
After all my main objection is against closing the door to others by one
particular implementation squating on "remote-http" name and refusing the
use of that nice, authoritative-sounding name by others.
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Sverre Rabbelier @ 2009-12-02 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Ilari Liusvaara, git
In-Reply-To: <7v3a3tfbsx.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Dec 2, 2009 at 19:52, Junio C Hamano <gitster@pobox.com> wrote:
> Sure, but please search for "second class citizen" in my message.
I read that, but I don't understand how exactly the mapping will make
it a non-second class citizen. How will your mapping include the
alternative implementation? The word mapping suggests a 1:1 relation
between protocol and implementation, so I don't see how the
alternative implementation would become first-class :(.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Junio C Hamano @ 2009-12-02 18:52 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Junio C Hamano, Johannes Schindelin, Ilari Liusvaara, git
In-Reply-To: <fabb9a1e0912021050r4fd96ed4rf863917a965a42fb@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> I don't see how what you are talking about is any different. With the
> mapping the executable of the alternative implementation still needs
> to have a different name, no?
Sure, but please search for "second class citizen" in my message.
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Sverre Rabbelier @ 2009-12-02 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Ilari Liusvaara, git
In-Reply-To: <7vk4x5fcbf.fsf@alter.siamese.dyndns.org>
Heya,
On Wed, Dec 2, 2009 at 19:41, Junio C Hamano <gitster@pobox.com> wrote:
> When the second implementation of http handler proves to be better than
> the current one, we can flip the mapping, and anybody who were using
> "http://" to access some repository will automatically updated to use the
> new backend instead of the old one. With your scheme, you probably could
> change the name of the old "http" backend to "http-deprecated" and the new
> one from "second-class-citizen-http" to "http" to achieve a similar
> effect, but I do not think it is as nice as having one extra level of
> indirection.
I don't see how what you are talking about is any different. With the
mapping the executable of the alternative implementation still needs
to have a different name, no?
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Ilari Liusvaara @ 2009-12-02 18:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Sverre Rabbelier, git
In-Reply-To: <7vskbtfdvo.fsf@alter.siamese.dyndns.org>
On Wed, Dec 02, 2009 at 10:07:55AM -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> The "modular" setup is a good thing to do, but I do not know how it
> relates to the change Ilari did.
Removing core dependency on NO_CURL is required for that. 6/8 is one
way to do that given support for dispatching <scheme>:// to remote
helpers (1/8).
> Isn't it simply a matter of excluding
> git-remote-curl from the current set of binaries to be shipped with
> git-core.rpm and making a separate git-remote-http.rpm to contain it, or
> does it involve a lot more than that from the packager's side?
See above. There's also issues with git remote helper execution, namely
inability to properly handle failure before cap exchange.
With properly fixed main git binary, it is just matter of splitting
remote-xxx executable(s) relating to HTTP to seperate package.
-Ilari
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Junio C Hamano @ 2009-12-02 18:41 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Johannes Schindelin, Ilari Liusvaara, Junio C Hamano, git
In-Reply-To: <fabb9a1e0912021006x2905578bo16dbcaedc0d97bc6@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
>> Of course, I never understood why the backend should know the
>> implementation detail that it is based on cURL, so it would be even more
>> modular (at least by my definition) if there was no hard-coded mapping.
>
> Agreed.
I don't get this point at all.
Backend is _very_ aware of how it is implemented itself. Naming one
implementation git-remote-http is to declare that "I am the one and only
implementation of http handler" and forces another implementation of http
handler, perhaps based on different toolkit than libcurl, to forever be a
second class citizen that need to use name other than 'http'.
The "mapping" you two are calling "hard-coded" may be "hard-coded" but is
a better kind of hard-coding than hard-coding "http" to "this particular
implementation" implicitly like you two seem to be advocating. Think of
it as having one extra layer of indirection.
When the second implementation of http handler proves to be better than
the current one, we can flip the mapping, and anybody who were using
"http://" to access some repository will automatically updated to use the
new backend instead of the old one. With your scheme, you probably could
change the name of the old "http" backend to "http-deprecated" and the new
one from "second-class-citizen-http" to "http" to achieve a similar
effect, but I do not think it is as nice as having one extra level of
indirection.
> However, I am not convinced that we should do any magic to map
> "foo://" to git-remote-foo. On the other hand, I do think it makes
> sense to have something modular that allows "git-remote-http" to be
> implemented as a separate package that can be installed.
As I said, I do think modular is good, but I think what Dscho is
advocating does not have much to achieve that goal.
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Junio C Hamano @ 2009-12-02 18:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Ilari Liusvaara, Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0912021832480.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This is definitely a good direction, and it would be even better if the
> absence of the remote helper was also handled gracefully. Just think
> about a (as of now fictious) git-remote-http.rpm relying on git-core.rpm
> and libcurl.rpm. If you do not want to access http:// URLs, you can
> install just git-core. Once you encounter an http:// URL you need to
> access, you install git-remote-http. Keeping git-core. (I like to call
> this setup "modular".)
The "modular" setup is a good thing to do, but I do not know how it
relates to the change Ilari did. Isn't it simply a matter of excluding
git-remote-curl from the current set of binaries to be shipped with
git-core.rpm and making a separate git-remote-http.rpm to contain it, or
does it involve a lot more than that from the packager's side?
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Sverre Rabbelier @ 2009-12-02 18:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Ilari Liusvaara, Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0912021832480.4985@pacific.mpi-cbg.de>
Heya,
On Wed, Dec 2, 2009 at 18:39, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> This is definitely a good direction, and it would be even better if the
> absence of the remote helper was also handled gracefully.
Yes, that is definitely an improvement we can and should make
regardless of how we handle http(s) and ftp(s), since currently "git
clone nonsense::http://...." will error out with the message that
"git-remote-nonsense" cannot be found.
> Of course, I never understood why the backend should know the
> implementation detail that it is based on cURL, so it would be even more
> modular (at least by my definition) if there was no hard-coded mapping.
Agreed.
> Sverre -- Cc'ed -- seemed to like URLs of the form "svn::http://..." and
> "cvs::pserver..." to trigger looking for a remote helper explicitely. I
> find the compiled-in mapping rather limiting.
Yes, I do think the double-colon syntax is very nice. That is, someone
who sees "git clone svn::http://" is likely to understand that it is a
svn repo over http that git treats specially.
However, I am not convinced that we should do any magic to map
"foo://" to git-remote-foo. On the other hand, I do think it makes
sense to have something modular that allows "git-remote-http" to be
implemented as a separate package that can be installed.
Perhaps instead of the current special case where "git-remote-curl" is
invoked, it would make more sense to instead special case on "http://"
(etc) and invoke "git-remote-http" in that case. So "git clone svn://"
would not work, but "git clone svn::svn://" would (as is the case
now), as well as "git clone http://" being handled by
"git-remote-http".
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: equal-tree-merges as way to make rebases fast-forward-able
From: Junio C Hamano @ 2009-12-02 18:03 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Bernhard R. Link, git
In-Reply-To: <20091202192026.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
>> In any case, at least this patch will make it start behaving a bit
>> more sanely.
>
> Thank you; it fixes the bug for me. Do I have to say
>
> Tested-by: Nanako Shiraishi <nanako3@lavabit.com>
>
> to ask you to include it in the new release?
>
>> -- >8 --
>> Subject: Do not misidentify "git merge foo HEAD" as an old-style invocation
Thanks for reminding me. I almost forgot that I did that patch.
^ permalink raw reply
* Re: [PATCH] builtin-commit: add --date option
From: Junio C Hamano @ 2009-12-02 17:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vpr6xgtxn.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Miklos Vajna <vmiklos@frugalware.org> writes:
> ...
>> Is there any documentation describing what does parse_date() accept?
>>
>> Based on t0006-date.sh and the comments in the source, I see 3 supported
>> formats:
>>
>> 1) <unix timestamp> <timezone>
>>
>> 2) A format like 2008-12-02 18:04:00
>>
>> 3) RFC 2822 (Thu, 21 Dec 2000 16:01:07 +0200)
>
> The above are all supported (you can label 2 as ISO even though the
> official ISO8601 wants "T" instead of " " between date and time).
>
> For more amusing ones, see
>
> http://article.gmane.org/gmane.comp.version-control.git/12241
>
> and follow the discussion there ;-)
I should have mentioned ones with more importance in real-life before
referring you to the amusing ones: US and European dates.
date.c::match_multi_number() groks these:
mm/dd/yy[yy] (US)
dd.mm.yy[yy] (European)
^ permalink raw reply
* Re: warning in git version 1.6.6.rc0.114.gc8648
From: Junio C Hamano @ 2009-12-02 17:50 UTC (permalink / raw)
To: Alejandro Riveira; +Cc: git
In-Reply-To: <hf67m0$r10$1@ger.gmane.org>
Alejandro Riveira <ariveira@gmail.com> writes:
> Whenever i do a "git pull" to check updates to the kernel
> or git repo i recieve
>
> warning: 'git merge <msg> HEAD <commit>' is deprecated. Please update
> your script to use 'git merge -m <msg> <commit>' instead.
> In future versions of git, this syntax will be removed.
> Already up-to-date.
>
> git pull should be updated to not use a deprecated form of git merge.
Yes we are aware of the issue and have a patch to do so which requires
another change which we also already have patch for. It will be fixed
before 1.6.6-rc1
Thanks for reporting.
^ permalink raw reply
* Re: [PATCH] git-pull.sh: Fix call to git-merge for new command format
From: Junio C Hamano @ 2009-12-02 17:49 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Horst H. von Brand, git
In-Reply-To: <4B16A410.5090802@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
>> Yes. Anything that sets GIT_EXEC_PATH correctly can use git-foo form.
>
> I know they can. That was in the part you snipped ;)
You asked about the presense of "a policy", and you got an answer.
> The questions is: Should they? Should we avoid mixing both forms in one
> script?
Should we avoid it? Yes but not very enthusiastically. We should make
sure that new invocations anybody adds use dashless form, but I would
recommend against a "let's remove use of dashed form" patch _unless_ you
find a time when the project is really quiet and there is nothing else
going on.
The whole point of GIT_EXEC_PATH trick is to allow continued use of the
dashed form, so that we do not have to suffer from code churn and patches
to implement real changes do not have to crash with such clean-ups.
As we'll be changing "git pull", we should use dashless form in the
vicinity of the real change (which is only one line) while at it, like
this.
-- >8 --
From: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Date: Tue, 1 Dec 2009 19:44:11 -0300
Subject: [PATCH] git-pull.sh: Fix call to git-merge for new command format
Now "git merge <msg> HEAD" is officially deprecated, we should
clean our own use as well.
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
git-pull.sh | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index bfeb4a0..fcf6c81 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -216,7 +216,7 @@ fi
merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
test true = "$rebase" &&
- exec git-rebase $diffstat $strategy_args --onto $merge_head \
+ exec git rebase $diffstat $strategy_args --onto $merge_head \
${oldremoteref:-$merge_head}
-exec git-merge $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \
- "$merge_name" HEAD $merge_head $verbosity
+exec git merge $verbosity $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \
+ -m "$merge_name" $merge_head
^ permalink raw reply related
* Re: [PATCH] builtin-commit: add --date option
From: Junio C Hamano @ 2009-12-02 17:35 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20091202171117.GY31763@genesis.frugalware.org>
Miklos Vajna <vmiklos@frugalware.org> writes:
> On Tue, Dec 01, 2009 at 01:27:32AM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> +--date=<date>::
>> + Override the date used in the commit. The format is the Git
>> + native one and is `<time> SP <offutc>`.
>
> I just noticed that fmt_ident() calls parse_date(), so other formats are
> supported as well.
>
> Is there any documentation describing what does parse_date() accept?
>
> Based on t0006-date.sh and the comments in the source, I see 3 supported
> formats:
>
> 1) <unix timestamp> <timezone>
>
> 2) A format like 2008-12-02 18:04:00
>
> 3) RFC 2822 (Thu, 21 Dec 2000 16:01:07 +0200)
The above are all supported (you can label 2 as ISO even though the
official ISO8601 wants "T" instead of " " between date and time).
For more amusing ones, see
http://article.gmane.org/gmane.comp.version-control.git/12241
and follow the discussion there ;-)
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Johannes Schindelin @ 2009-12-02 17:39 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Sverre Rabbelier, Junio C Hamano, git
In-Reply-To: <20091202160446.GA32667@Knoppix>
Hi,
On Wed, 2 Dec 2009, Ilari Liusvaara wrote:
> And if mappings http -> curl, https -> curl, ftp -> curl are to remain
> explicit in main git binary, I would put them into table and build stub
> remote-curl if NO_CURL is defined instead of special casing the error in
> main git binary (but I consider that worse than just removing the
> association from main git binary).
This is definitely a good direction, and it would be even better if the
absence of the remote helper was also handled gracefully. Just think
about a (as of now fictious) git-remote-http.rpm relying on git-core.rpm
and libcurl.rpm. If you do not want to access http:// URLs, you can
install just git-core. Once you encounter an http:// URL you need to
access, you install git-remote-http. Keeping git-core. (I like to call
this setup "modular".)
Of course, I never understood why the backend should know the
implementation detail that it is based on cURL, so it would be even more
modular (at least by my definition) if there was no hard-coded mapping
(Sverre -- Cc'ed -- seemed to like URLs of the form "svn::http://..." and
"cvs::pserver..." to trigger looking for a remote helper explicitely). I
find the compiled-in mapping rather limiting.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-pull.sh: Fix call to git-merge for new command format
From: Michael J Gruber @ 2009-12-02 17:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Horst H. von Brand, git
In-Reply-To: <7vws15jpe7.fsf@alter.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 02.12.2009 17:45:
> Michael J Gruber <git@drmicha.warpmail.net> writes:
>
>> This made me wonder a bit: Do we have a policy regarding the use of
>> "git-command" vs. "git command" in git shell scripts such as this one?
>
> Yes. Anything that sets GIT_EXEC_PATH correctly can use git-foo form.
I know they can. That was in the part you snipped ;)
The questions is: Should they? Should we avoid mixing both forms in one
script?
Michael
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Junio C Hamano @ 2009-12-02 17:26 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20091202160446.GA32667@Knoppix>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
> On Tue, Dec 01, 2009 at 10:35:58PM -0800, Junio C Hamano wrote:
>> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>>
>> I didn't mean the line count by "large". I was referring to the size of
>> change at the conceptual level. As Daniel already explained, it has been
>> one of the design assumption so far that there are built-in mappings from
>> some common <scheme>:// to backend "helpers".
>
> No implicit mappings from <scheme>:// to helpers existed before this series
> (except for forcing in URL, which are different). Thus, any mapping had to
> be explicit and built-in.
> ...
> So instead of mapping explicitly, those are effectively mapped by filesystem
> (that's after the fixes for next round that make helpers hardlinked instead
> of copied).
Sure, it may be a good change; didn't I say that in the part you omitted
from your quote? But it is conceptually a big change nevertheless, and it
is to be debated --- that makes the parts leading to 6/8 rather a large
change, which was my primary point in the message you are responding to,
so I think we are in agreement that it would have been nicer if the other
bits that are independently useful (like the debug one) were earlier in
the series.
The other minor point in my message was that this is to be debated (which
I think you are doing now), but I am not the best person to debate the
design of this part with. Daniel and Shawn are the guys who have
primarily worked on the helper interface and relationship between the
helpers and the transport layer, and will have much better insights.
By the way, are you the helpful git expert we often see on #git IRC
channel who goes by the same name? Welcome to the list; I don't remember
seeing you here, and let me thank you for having helped many new to
intermediate git users over there for a long time.
^ permalink raw reply
* warning in git version 1.6.6.rc0.114.gc8648
From: Alejandro Riveira @ 2009-12-02 17:21 UTC (permalink / raw)
To: git
Whenever i do a "git pull" to check updates to the kernel
or git repo i recieve
warning: 'git merge <msg> HEAD <commit>' is deprecated. Please update
your script to use 'git merge -m <msg> <commit>' instead.
In future versions of git, this syntax will be removed.
Already up-to-date.
git pull should be updated to not use a deprecated form of git merge.
Regards
^ 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