* Re: [msysGit] Re: Using VC build git (split patch)
From: Erik Faye-Lund @ 2009-08-30 20:16 UTC (permalink / raw)
To: Thiago Farina
Cc: Frank Li, Marius Storm-Olsen, git, msysGit, Johannes Schindelin
In-Reply-To: <a4c8a6d00908301236l4394a471vb83ed2befda3a91@mail.gmail.com>
On Sun, Aug 30, 2009 at 9:36 PM, Thiago Farina<tfransosi@gmail.com> wrote:
> Error 2635 error LNK2019: unresolved external symbol _socketpair
> referenced in function _imap_open_store imap-send.obj imap-send
>
> Anyone faced this problem before?
Yes. imap-send isn't supported on windows, since it uses
posix-functions that aren't available in msvcrt. The Makefile system
excludes it for MinGW-builds. Is it added to the vcproj-files?
Any patches that adds a working socketpair()-function (or even better,
IMO: rewrite the code so socketpair isn't needed) would of course be
very welcome. I'd love to have a working imap-send on windows :)
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [PATCH] Remove unused t/t8005/iso8859-5.txt file
From: Junio C Hamano @ 2009-08-30 20:14 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git
In-Reply-To: <20090829170809.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Junio C Hamano <gitster@pobox.com>
>
>> Out of curiosity, how did you find this?
>
> Soon after you posted your original in
> http://thread.gmane.org/gmane.comp.version-control.git/121881, I applied
> it to my tree, and I have been running 'git pull --rebase' for ever. I
> noticed that rebase didn't remove the commit, even after your 54bc13c.
>
> Today I found that the rebased patch only removed that file. The real
> question is how you lost the deletion of the file when you applied. What
> happened?
My stupidity, and a little bit of danger in trusting "am -3" blindly.
The patch sent to the list was against the master, but the actual commit
created, 54bc13c, was on maint. Back then, there was a commit in master
but not in maint that stopped using cp1251.txt and started using
iso8859-5.txt instead.
Because maint did not have iso8859-5.txt (which the patch wanted to
remove), when "am -3" did its fake 3-way merge, the removal of the path
did not even conflict. It was the case of "neither side wants to have
this file". As the result, cp1251.txt was left in the tree (which is
half-Ok, even though the updated test never looked at it anymore), and
merging the result back to master did not touch iso8859-5.txt.
^ permalink raw reply
* Re: [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Junio C Hamano @ 2009-08-30 20:14 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <87ocpxb46g.fsf@jondo.cante.net>
Jari Aalto <jari.aalto@cante.net> writes:
> Signed-off-by: Jari Aalto <jari.aalto@cante.net>
> ---
> Documentation/git-add.txt | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
> index e67b7e8..71990c2 100644
> --- a/Documentation/git-add.txt
> +++ b/Documentation/git-add.txt
> @@ -67,14 +67,14 @@ OPTIONS
> --interactive::
> Add modified contents in the working tree interactively to
> the index. Optional path arguments may be supplied to limit
> - operation to a subset of the working tree. See ``Interactive
> - mode'' for details.
> + operation to a subset of the working tree. See section
> + ``INTERACTIVE MODE'' for details.
Sorry, the change in this hunk does not make *any* sense to me.
It is not justified with your commit log message, I do not see why you
have to shout in all CAPS, and there is no such section in the
documentation. But the "Interactive mode" section exists and is referred
to by the original.
> -p::
> --patch::
> - Similar to Interactive mode but the initial command loop is
> - bypassed and the 'patch' subcommand is invoked using each of
> - the specified filepatterns before exiting.
> + Run interactive patch command for each file on command line.
> + See section INTERACTIVE MODE and patch subcommand for more
> + information.
I personally think fixing misworded phrase "initial command loop" would be
sufficient. It should read "initial command menu". Perhaps like this.
Run ``add --interactive``, but bypass the initial command menu and
directly jump to `patch` subcommand. See ``Interactive mode'' for
details.
If you assume that the reader is not familiar with "add -i", then the
above is not descriptive enough, but "Run interactive patch command" is
not an improvement either. We would need a description of "what it is
used for" before "how it would look to you" (i.e.. my rewrite shown
above).
"What it is used for" would perhaps read like this.
Review the difference between the index and the work tree, and add
modified contents to the index interactively by choosing which
patch hunks to use.
^ permalink raw reply
* Re: git-diff: must --exit-code work with --ignore* options?
From: Junio C Hamano @ 2009-08-30 20:11 UTC (permalink / raw)
To: Jim Meyering; +Cc: git list
In-Reply-To: <87skf9uv3r.fsf@meyering.net>
Jim Meyering <jim@meyering.net> writes:
> Junio C Hamano wrote:
> ...
>> Subject: [PATCH] diff --quiet: special case "ignore whitespace" options
>> ...
>> Change the semantics of --ignore-whitespace* options to mean more than
>> "omit showing the difference in text". When these options are used, the
>> internal "quick" optimization is turned off, and the status reported with
>> the --exit-code option will now match if any the textual diff output is
>> actually produced.
>>
>> Also rename the internal option "QUIET" to "QUICK" to better reflect what
>> its true purpose is.
>
> Thanks again.
> If there's anything I can to do help (add a test?), let me know.
The change has been cooking in 'next' and hopefully be in 1.7.0. I think
the updated series adds its own test script, too.
Using it in every day scenario, and reporting any breakage you notice
before 1.7.0 happens, would be greatly appreciated.
Thanks.
^ permalink raw reply
* Re: [BUG] git stash refuses to save after "add -N"
From: Junio C Hamano @ 2009-08-30 20:01 UTC (permalink / raw)
To: Jeff King; +Cc: Yann Dirson, git
In-Reply-To: <20090830095509.GB30922@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sat, Aug 29, 2009 at 03:34:45PM -0700, Junio C Hamano wrote:
>
>> I am slightly in favor of leaving the things as they are, as the error
>> message is quite clear.
>
> Hmm. Thinking about it a bit more, I think "add as empty content" is
> probably the best. It scares me a little because it is losing
> information during the stash, but consider it from the user's
> perspective.
> ...
> And all of this while they are trying to quickly switch contexts to
> whatever it was that caused them to stash in the first place.
Ok, then probably the "how about" patch would be a part of the right
solution.
One thing I noticed was that while unstashing without --index, we add full
contents to the index of new files. I think it is because back then when
stash was written there was no other way, but now we have intent-to-add
and a way to stash such an entry, I think we should add only the intent to
add them in that codepath.
Of course we will not do this when unstashing with --index.
^ permalink raw reply
* Re: Merging in Subversion 1.5 (was: Re: Using git to track my PhD thesis, couple of questions)
From: Sam Vilain @ 2009-08-30 19:41 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Matthias Andree, git, Matthieu Moy
In-Reply-To: <m3ocq0km5m.fsf_-_@localhost.localdomain>
On Fri, 2009-08-28 at 08:12 -0700, Jakub Narebski wrote:
> * svn:mergeinfo contains _per-file_ merge info, so it is much, much
> more "chatty" than Git multiple parents.
It can. But more often, if you're merging complete paths, you will get
complete revision ranges.
See eg
https://trac.parrot.org/parrot/browser/trunk
Note how trac is also hiding the branches that were subsequently deleted
from the mergeinfo ticket.
> * The command to merge trunk into branch is different from command to
> merge branch into trunk.
This is a caveat of url-based branches.
> Also IIRC there is warning (well, at least there was in Subversion 1.5
> release notes) that merge tracking doesn't work entirely correctly in
> the face of criss-cross merges (multiple merge bases) and renaming
> (although I do hope that they fixed problem with silent corruption if
> there is rename during merge).
Not sure about that one. I also heard - unconfirmed - that things start
to go awry if you start branching off branches and merging around the
place. But if that happens it's likely a bug rather than a design flaw
(I think).
Sam
^ permalink raw reply
* Re: [msysGit] Re: Using VC build git (split patch)
From: Thiago Farina @ 2009-08-30 19:36 UTC (permalink / raw)
To: Frank Li; +Cc: Marius Storm-Olsen, git, msysGit, Johannes Schindelin
In-Reply-To: <1976ea660908171807x22f4b755r2e522a15ff462917@mail.gmail.com>
Hi
In line 999 of imap-send.c there is a call to the function socketpair,
but apparently it isn't defined anywhere, because the compiler is
returning this following error:
Error 2635 error LNK2019: unresolved external symbol _socketpair
referenced in function _imap_open_store imap-send.obj imap-send
Anyone faced this problem before?
Thanks!
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Howard Miller @ 2009-08-30 19:06 UTC (permalink / raw)
To: Daniele Segato; +Cc: John Tapsell, Frank Münnich, git
In-Reply-To: <1251655664.31273.4.camel@localhost>
I can only reply very generally (I don't develop git - I develop php
and use git). However, I have tried to use Eclipse on a number of
occasions and have always drifted back to Vim. With a bit of learning
can can do most of the stuff that an IDE does, usually faster and with
less fuss. However, the killer for me is that you can access your
development box in an emergency over a slow dialup line and vim will
get you out of trouble - your fancy, resource-hogging IDE will not.
2009/8/30 Daniele Segato <daniele.bilug@gmail.com>:
> Il giorno mar, 25/08/2009 alle 13.47 +0100, John Tapsell ha scritto:
>> 2009/8/25 Frank Münnich <git@frank-muennich.com>:
>> > One thing I would like to ask you: what, if any, IDEs are you working with?
>>
>> I think everyone just uses vim/emacs :-)
>
> I can't get how would one take vim or emacs instead of an IDE like
> Eclipse.
> That's probably because I'm mainingly a Java developer and i don't know
> vim/emacs very much.
>
> What are the advantages of developing git with vim/emacs over an IDE?
>
> Cheers,
> Daniele
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Nicolas Pitre @ 2009-08-30 19:01 UTC (permalink / raw)
To: Daniele Segato; +Cc: John Tapsell, Frank Münnich, git
In-Reply-To: <1251655664.31273.4.camel@localhost>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 697 bytes --]
On Sun, 30 Aug 2009, Daniele Segato wrote:
> Il giorno mar, 25/08/2009 alle 13.47 +0100, John Tapsell ha scritto:
> > 2009/8/25 Frank Münnich <git@frank-muennich.com>:
> > > One thing I would like to ask you: what, if any, IDEs are you working with?
> >
> > I think everyone just uses vim/emacs :-)
>
> I can't get how would one take vim or emacs instead of an IDE like
> Eclipse.
> That's probably because I'm mainingly a Java developer and i don't know
> vim/emacs very much.
I've spent all my career as a professional programmer using vim as my
sole source code editor for the last 15 years.
> What are the advantages of developing git with vim/emacs over an IDE?
Simplicity.
Nicolas
^ permalink raw reply
* Re: What IDEs are you using to develop git?
From: Daniele Segato @ 2009-08-30 18:07 UTC (permalink / raw)
To: John Tapsell; +Cc: Frank Münnich, git
In-Reply-To: <43d8ce650908250547t17b76c95qb9931983e0a4b232@mail.gmail.com>
Il giorno mar, 25/08/2009 alle 13.47 +0100, John Tapsell ha scritto:
> 2009/8/25 Frank Münnich <git@frank-muennich.com>:
> > One thing I would like to ask you: what, if any, IDEs are you working with?
>
> I think everyone just uses vim/emacs :-)
I can't get how would one take vim or emacs instead of an IDE like
Eclipse.
That's probably because I'm mainingly a Java developer and i don't know
vim/emacs very much.
What are the advantages of developing git with vim/emacs over an IDE?
Cheers,
Daniele
^ permalink raw reply
* Re: [PATCH] Fix overridable written with an extra 'e'
From: Uri Okrent @ 2009-08-30 17:58 UTC (permalink / raw)
To: git
In-Reply-To: <20090828034305.GQ4297@inocybe.localdomain>
Todd Zullinger <tmz <at> pobox.com> writes:
>
> Nanako Shiraishi wrote:
> > Found during the lunch break by one of my students...
>
> Is overridable a word itself? While English is my native language, I
> wouldn't call myself an expert on its proper usage. ;)
No, it's not a word =). But of the two non-words, overridable is probably
preferred.
>
> However, I can't find 'overridable' in several online dictionaries:
>
> http://dictionary.reference.com/browse/overridable
> http://www.merriam-webster.com/dictionary/overridable
> http://www.google.com/dictionary?aq=f&langpair=en|en&q=overridable&hl=en
> http://dictionary.cambridge.org/results.asp?searchword=overridable&x=0&y=0
>
> Perhaps using overridden would be more accurate?
It would be more correct, but also slightly more verbose. Still, as a grammar
nazi, my two cents says it raises git's esteem if the language in the docs is
proper English.
Uri
^ permalink raw reply
* [PATCH] Documentation/git-add.txt: Explain --patch option in layman terms
From: Jari Aalto @ 2009-08-30 17:29 UTC (permalink / raw)
To: git
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/git-add.txt | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index e67b7e8..71990c2 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -67,14 +67,14 @@ OPTIONS
--interactive::
Add modified contents in the working tree interactively to
the index. Optional path arguments may be supplied to limit
- operation to a subset of the working tree. See ``Interactive
- mode'' for details.
+ operation to a subset of the working tree. See section
+ ``INTERACTIVE MODE'' for details.
-p::
--patch::
- Similar to Interactive mode but the initial command loop is
- bypassed and the 'patch' subcommand is invoked using each of
- the specified filepatterns before exiting.
+ Run interactive patch command for each file on command line.
+ See section INTERACTIVE MODE and patch subcommand for more
+ information.
-e, \--edit::
Open the diff vs. the index in an editor and let the user
--
1.6.3.3
^ permalink raw reply related
* Re: Anyone meet DNS fail translate repo.or.cz
From: Mikael Magnusson @ 2009-08-30 16:58 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Frank Li, git
In-Reply-To: <237967ef0908300350k4e06b522x9baa7aa5528d32d@mail.gmail.com>
Seems to be back up now.
2009/8/30 Mikael Magnusson <mikachu@gmail.com>:
> 2009/8/30 Erik Faye-Lund <kusmabite@googlemail.com>:
>> On Sun, Aug 30, 2009 at 6:20 AM, Frank Li<lznuaa@gmail.com> wrote:
>>> ALL:
>>> I can't access repo.or.cz from yesterday.
>>> DNS can't translate repo.or.cz.
>>> Even
>>> http://www.dnswatch.info/dns/dnslookup?la=en&host=repo.or.cz&type=A
>>>
>>> It also can't recognize repo.or.cz.
>>>
>>> Anyone meet the same problem?
>>
>> Yeah, I've been seeing the same problem here.
>
> The IP for both repo.or.cz and git.or.cz is 62.24.64.27
> If you add this to /etc/hosts you can still access both fine.
> 62.24.64.27 repo.or.cz git.or.cz
>
> --
> Mikael Magnusson
>
--
Mikael Magnusson
^ permalink raw reply
* Re: git-diff: must --exit-code work with --ignore* options?
From: Jim Meyering @ 2009-08-30 16:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7v7i087twu.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jim Meyering <jim@meyering.net> writes:
>> Junio C Hamano wrote:
>>> Jim Meyering <jim@meyering.net> writes:
>>>>
>>>> # do this in an empty directory
>>>> $ git init -q; echo>k; git add .; git commit -q -m. .; echo \ >k
>>>> $ git diff --ignore-space-at-eol --quiet || echo bad
>>>> bad
>>>
>>> I am slightly torn about this, in that I can picture myself saying that
>>> this is unintuitive on some different days, but not today ;-)
>>
>> Thanks for the quick reply. Here's why I noticed:
>> ...
>
> It seems that today is already "some different day" ;-) We could do
> something like this patch.
>
> While in the longer term I think it may make the world a better place by
> being more consistent with what users expect, I am not sure at what
> revision boundary we should introduce such a semantic change.
>
> We could always declare this a bug and apply the "fix" at any time. It's
> all perception ;-).
>
> -- >8 --
> Subject: [PATCH] diff --quiet: special case "ignore whitespace" options
>
> The option "QUIET" primarily meant "find if we have _any_ difference as
> quick as possible and report", which means we often do not even have to
> look at blobs if we know the trees are different by looking at the higher
> level (e.g. "diff-tree A B"). As a side effect, because there is no point
> showing one change that we happened to have found first, it also enables
> NO_OUTPUT and EXIT_WITH_STATUS options, making the end result look quiet.
>
> Traditionally, the --ignore-whitespace* options have merely meant to tell
> the diff output routine that some class of differences are not worth
> showing in the textual diff output, so that the end user has easier time
> to review the remaining (presumably more meaningful) changes. These
> options never affected the outcome of the command, given as the exit
> status when the --exit-code option was in effect (either directly or
> indirectly).
>
> These two classes of options are incompatible. When you have only
> whitespace changes, you would expect:
>
> git diff -b --quiet
>
> to report that there is _no_ change. This is unfortunately not the case,
> however, if there are differences to be reported if the command was run
> without --quiet; there _is_ a change, and the command still exits with
> non-zero status.
>
> And that is wrong.
>
> Change the semantics of --ignore-whitespace* options to mean more than
> "omit showing the difference in text". When these options are used, the
> internal "quick" optimization is turned off, and the status reported with
> the --exit-code option will now match if any the textual diff output is
> actually produced.
>
> Also rename the internal option "QUIET" to "QUICK" to better reflect what
> its true purpose is.
Thanks again.
If there's anything I can to do help (add a test?), let me know.
^ permalink raw reply
* Re: [PATCH] git.el: Make it easy to add unmerged files
From: Alexandre Julliard @ 2009-08-30 15:58 UTC (permalink / raw)
To: Martin Nordholts; +Cc: git, Junio C Hamano
In-Reply-To: <4A9A92F4.2090209@chromecode.com>
Martin Nordholts <martin@chromecode.com> writes:
> (Resending as I managed to mangle the previous patch despite trying not to...)
>
> It is nice and easy to git-add ignored and unknown files in a
> git-status buffer. Make it equally easy to add unmerged files which is
> a common use case.
That's not quite what adding a file means in git.el, unmerged files are
considered added already, and marking them resolved is done through the
git-resolve-file command. Of course that was implemented before git
overloaded the meaning of git-add to mean git-update-index, so maybe we
should follow the trend and use git-add-file for all index updates. In
that case git-resolve-file should probably be removed.
--
Alexandre Julliard
julliard@winehq.org
^ permalink raw reply
* [PATCH] git.el: Make it easy to add unmerged files
From: Martin Nordholts @ 2009-08-30 14:55 UTC (permalink / raw)
To: git, Junio C Hamano, julliard
(Resending as I managed to mangle the previous patch despite trying not to...)
It is nice and easy to git-add ignored and unknown files in a
git-status buffer. Make it equally easy to add unmerged files which is
a common use case.
Signed-off-by: Martin Nordholts <martinn@src.gnome.org>
---
contrib/emacs/git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 8c70ad8..3af5d00 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1046,7 +1046,7 @@ The FILES list must be sorted."
(defun git-add-file ()
"Add marked file(s) to the index cache."
(interactive)
- (let ((files (git-get-filenames (git-marked-files-state 'unknown 'ignored))))
+ (let ((files (git-get-filenames (git-marked-files-state 'unknown 'ignored 'unmerged))))
;; FIXME: add support for directories
(unless files
(push (file-relative-name (read-file-name "File to add: " nil nil t)) files))
--
1.6.2.5
^ permalink raw reply related
* Strangeness with git log --follow
From: Brenton Fletcher @ 2009-08-30 14:31 UTC (permalink / raw)
To: git
I'm using git log --follow -p <filename> to list all the commits
affecting a certain file. My problem is that git log --follow --topo-
order returns fewer commits than git log --follow --date-order (or
default). The docs for git log and git-rev-list don't seem to indicate
whay this is happening.
The repo I'm working with is http://github.com/bloopletech/keycontrol/tree/master
and the file is original/C/kc.c on the master branch; I'm using git
v1.6.4.2
Am I misunderstanding what's going on here? --topo-order is kind of
doing that I want since it's generating a nice series of commits that
diff against each other nicely, whereas running without topo-order is
returning the commits in a sequence which means thay don't properly
diff against each other. I like the results I'm getting from --topo-
order, but I need results in date order, which is not assured AFAIK
with topo-order.
If someone could enlighten me as to what's going on, thanks!
-Brenton Fletcher
^ permalink raw reply
* [PATCH] git.el: Make it easy to add unmerged files
From: Martin Nordholts @ 2009-08-30 14:35 UTC (permalink / raw)
To: git, Junio C Hamano, julliard
It is nice and easy to git-add ignored and unknown files in a
git-status buffer. Make it equally easy to add unmerged files which is
a common use case.
Signed-off-by: Martin Nordholts <martinn@src.gnome.org>
---
contrib/emacs/git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/emacs/git.el b/contrib/emacs/git.el
index 8c70ad8..3af5d00 100644
--- a/contrib/emacs/git.el
+++ b/contrib/emacs/git.el
@@ -1046,7 +1046,7 @@ The FILES list must be sorted."
(defun git-add-file ()
"Add marked file(s) to the index cache."
(interactive)
- (let ((files (git-get-filenames (git-marked-files-state 'unknown
'ignored))))
+ (let ((files (git-get-filenames (git-marked-files-state 'unknown
'ignored 'unmerged))))
;; FIXME: add support for directories
(unless files
(push (file-relative-name (read-file-name "File to add: " nil
nil t)) files))
--
1.6.2.5
^ permalink raw reply related
* Re: [PATCH 1/2] Add date formatting and parsing functions relative to a given time
From: Alex Riesen @ 2009-08-30 11:17 UTC (permalink / raw)
To: Jeff King; +Cc: git, Nicolas Pitre, David Reiss, Junio C Hamano
In-Reply-To: <20090830100826.GA31543@coredump.intra.peff.net>
On Sun, Aug 30, 2009 at 12:08, Jeff King<peff@peff.net> wrote:
> On Sun, Aug 30, 2009 at 11:56:37AM +0200, Alex Riesen wrote:
>>
>> check_show 630000000 '20.years.ago'?
>> (Arbitrary, non-whitespace delimiters, which was an
>> advertised feature, to make shell's life easier)
>
> This part is about checking what show_date produces (the first number is
> an offset from now in seconds, and the second is what we expect), so it
> always has spaces.
>
> See the check_approxidate section further down for an example of parsing
> what you are talking about.
Ah, I see
^ permalink raw reply
* Re: Anyone meet DNS fail translate repo.or.cz
From: Mikael Magnusson @ 2009-08-30 10:50 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: Frank Li, git
In-Reply-To: <40aa078e0908300339j74e9c542x3436ec2e58e4b874@mail.gmail.com>
2009/8/30 Erik Faye-Lund <kusmabite@googlemail.com>:
> On Sun, Aug 30, 2009 at 6:20 AM, Frank Li<lznuaa@gmail.com> wrote:
>> ALL:
>> I can't access repo.or.cz from yesterday.
>> DNS can't translate repo.or.cz.
>> Even
>> http://www.dnswatch.info/dns/dnslookup?la=en&host=repo.or.cz&type=A
>>
>> It also can't recognize repo.or.cz.
>>
>> Anyone meet the same problem?
>
> Yeah, I've been seeing the same problem here.
The IP for both repo.or.cz and git.or.cz is 62.24.64.27
If you add this to /etc/hosts you can still access both fine.
62.24.64.27 repo.or.cz git.or.cz
--
Mikael Magnusson
^ permalink raw reply
* Re: Anyone meet DNS fail translate repo.or.cz
From: Erik Faye-Lund @ 2009-08-30 10:39 UTC (permalink / raw)
To: Frank Li; +Cc: git
In-Reply-To: <1976ea660908292120r7e7ec941he7573671251451f5@mail.gmail.com>
On Sun, Aug 30, 2009 at 6:20 AM, Frank Li<lznuaa@gmail.com> wrote:
> ALL:
> I can't access repo.or.cz from yesterday.
> DNS can't translate repo.or.cz.
> Even
> http://www.dnswatch.info/dns/dnslookup?la=en&host=repo.or.cz&type=A
>
> It also can't recognize repo.or.cz.
>
> Anyone meet the same problem?
Yeah, I've been seeing the same problem here.
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [PATCH 1/2] Add date formatting and parsing functions relative to a given time
From: Jeff King @ 2009-08-30 10:08 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Nicolas Pitre, David Reiss, Junio C Hamano
In-Reply-To: <81b0412b0908300256l13d308d9oc30172a20a9f6108@mail.gmail.com>
On Sun, Aug 30, 2009 at 11:56:37AM +0200, Alex Riesen wrote:
> > +check_show 5 '5 seconds ago'
> > +check_show 300 '5 minutes ago'
> > +check_show 18000 '5 hours ago'
> > +check_show 432000 '5 days ago'
> > +check_show 1728000 '3 weeks ago'
> > +check_show 13000000 '5 months ago'
> > +check_show 37500000 '1 year, 2 months ago'
> > +check_show 55188000 '1 year, 9 months ago'
> > +check_show 630000000 '20 years ago'
>
> check_show 630000000 '20.years.ago'?
> (Arbitrary, non-whitespace delimiters, which was an
> advertised feature, to make shell's life easier)
This part is about checking what show_date produces (the first number is
an offset from now in seconds, and the second is what we expect), so it
always has spaces.
See the check_approxidate section further down for an example of parsing
what you are talking about.
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] Add date formatting and parsing functions relative to a given time
From: Alex Riesen @ 2009-08-30 9:56 UTC (permalink / raw)
To: Jeff King; +Cc: git, Nicolas Pitre, David Reiss, Junio C Hamano
In-Reply-To: <20090830093642.GA30922@coredump.intra.peff.net>
On Sun, Aug 30, 2009 at 11:36, Jeff King<peff@peff.net> wrote:
> On Sun, Aug 30, 2009 at 05:15:57AM -0400, Jeff King wrote:
>
>> FYI, I am munging test-date to match the test script I am writing, so
>> don't bother with that patch.
>
> Here is what my patch is looking like. Please give any comments, and
> then I will resubmit in a form that will be simpler for Junio, which
> should be a series with:
>
> - your patch to refactor date.c
> - this patch (this version uses the original interface to
> show_relative; I will tweak to match the new patch you just sent)
Yes, I think this is the only comment I can make.
> +# arbitrary reference time: 2009-08-30 19:20:00
The world changed since 1980 :) There is already three things
happened at the day (http://en.wikipedia.org/wiki/August_2009),
and it is not evening yet (well, here in Europe)
> +check_show 5 '5 seconds ago'
> +check_show 300 '5 minutes ago'
> +check_show 18000 '5 hours ago'
> +check_show 432000 '5 days ago'
> +check_show 1728000 '3 weeks ago'
> +check_show 13000000 '5 months ago'
> +check_show 37500000 '1 year, 2 months ago'
> +check_show 55188000 '1 year, 9 months ago'
> +check_show 630000000 '20 years ago'
check_show 630000000 '20.years.ago'?
(Arbitrary, non-whitespace delimiters, which was an
advertised feature, to make shell's life easier)
^ permalink raw reply
* Re: [BUG] git stash refuses to save after "add -N"
From: Jeff King @ 2009-08-30 9:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Yann Dirson, git
In-Reply-To: <7vmy5ixn96.fsf@alter.siamese.dyndns.org>
On Sat, Aug 29, 2009 at 03:34:45PM -0700, Junio C Hamano wrote:
> I am slightly in favor of leaving the things as they are, as the error
> message is quite clear.
Hmm. Thinking about it a bit more, I think "add as empty content" is
probably the best. It scares me a little because it is losing
information during the stash, but consider it from the user's
perspective.
Their work-in-progress is being interrupted, so they need to stash. They
try "git stash" and the current version comes back with an error. Now
what? If they know what to do, they can manually "git rm --cached" each
of the offending files (and I say manually because there isn't a
parseable list of them anywhere). But they probably don't know what to
do, which means trying to find the information in the documentation.
And all of this while they are trying to quickly switch contexts to
whatever it was that caused them to stash in the first place. So I
expect the most useful thing would be a "git stash -f" that adds them as
empty. And it's reasonably safe, because we're not losing information in
the transition from index to stash tree without the user first having
been notified.
On the other hand, it may be sufficient to just do the transformation
with a "-f", which will save users even more time, and we can put a note
in the documentation about how stash interacts with -N. I don't know
whether people will actually care or not (and your patch already does
the unconditional form, so it's less work :) ).
-Peff
^ permalink raw reply
* Re: [PATCH 1/2] Add date formatting and parsing functions relative to a given time
From: Jeff King @ 2009-08-30 9:36 UTC (permalink / raw)
To: Alex Riesen; +Cc: git, Nicolas Pitre, David Reiss, Junio C Hamano
In-Reply-To: <20090830091557.GA28531@coredump.intra.peff.net>
On Sun, Aug 30, 2009 at 05:15:57AM -0400, Jeff King wrote:
> FYI, I am munging test-date to match the test script I am writing, so
> don't bother with that patch.
Here is what my patch is looking like. Please give any comments, and
then I will resubmit in a form that will be simpler for Junio, which
should be a series with:
- your patch to refactor date.c
- this patch (this version uses the original interface to
show_relative; I will tweak to match the new patch you just sent)
- another patch to go on top of lt/approxidate to test recent fixes
from Linus
---
diff --git a/t/t0006-date.sh b/t/t0006-date.sh
new file mode 100755
index 0000000..4beb44b
--- /dev/null
+++ b/t/t0006-date.sh
@@ -0,0 +1,71 @@
+#!/bin/sh
+
+test_description='test date parsing and printing'
+. ./test-lib.sh
+
+# arbitrary reference time: 2009-08-30 19:20:00
+TEST_DATE_NOW=1251660000; export TEST_DATE_NOW
+
+check_show() {
+ t=$(($TEST_DATE_NOW - $1))
+ echo "$t -> $2" >expect
+ test_expect_success "relative date ($2)" "
+ test-date show $t >actual &&
+ test_cmp expect actual
+ "
+}
+
+check_show 5 '5 seconds ago'
+check_show 300 '5 minutes ago'
+check_show 18000 '5 hours ago'
+check_show 432000 '5 days ago'
+check_show 1728000 '3 weeks ago'
+check_show 13000000 '5 months ago'
+check_show 37500000 '1 year, 2 months ago'
+check_show 55188000 '1 year, 9 months ago'
+check_show 630000000 '20 years ago'
+
+check_parse() {
+ echo "$1 -> $2" >expect
+ test_expect_success "parse date ($1)" "
+ test-date parse '$1' >actual &&
+ test_cmp expect actual
+ "
+}
+
+check_parse 2008 bad
+check_parse 2008-02 bad
+check_parse 2008-02-14 '2008-02-14 00:00:00 +0000'
+check_parse '2008-02-14 20:30:45' '2008-02-14 20:30:45 +0000'
+
+check_approxidate() {
+ echo "$1 -> $2 +0000" >expect
+ test_expect_success "parse approxidate ($1)" "
+ test-date approxidate '$1' >actual &&
+ test_cmp expect actual
+ "
+}
+
+check_approxidate now '2009-08-30 19:20:00'
+check_approxidate '5 seconds ago' '2009-08-30 19:19:55'
+check_approxidate 5.seconds.ago '2009-08-30 19:19:55'
+check_approxidate 10.minutes.ago '2009-08-30 19:10:00'
+check_approxidate yesterday '2009-08-29 19:20:00'
+check_approxidate 3.days.ago '2009-08-27 19:20:00'
+check_approxidate 3.weeks.ago '2009-08-09 19:20:00'
+check_approxidate 3.months.ago '2009-05-30 19:20:00'
+check_approxidate 2.years.3.months.ago '2007-05-30 19:20:00'
+
+check_approxidate '6am yesterday' '2009-08-29 06:00:00'
+check_approxidate '6pm yesterday' '2009-08-29 18:00:00'
+check_approxidate '3:00' '2009-08-30 03:00:00'
+check_approxidate '15:00' '2009-08-30 15:00:00'
+check_approxidate 'noon today' '2009-08-30 12:00:00'
+check_approxidate 'noon yesterday' '2009-08-29 12:00:00'
+
+check_approxidate 'last tuesday' '2009-08-25 19:20:00'
+check_approxidate 'July 5th' '2009-07-05 19:20:00'
+check_approxidate '06/05/2009' '2009-06-05 00:00:00'
+check_approxidate '06.05.2009' '2009-05-06 00:00:00'
+
+test_done
diff --git a/test-date.c b/test-date.c
index 62e8f23..8d263a3 100644
--- a/test-date.c
+++ b/test-date.c
@@ -1,20 +1,63 @@
#include "cache.h"
-int main(int argc, char **argv)
+static const char *usage_msg = "\n"
+" test-date show [time_t]...\n"
+" test-date parse [date]...\n"
+" test-date approxidate [date]...\n";
+
+static void show_dates(char **argv, struct timeval *now)
{
- int i;
+ for (; *argv; argv++) {
+ time_t t = atoi(*argv);
+ printf("%s -> %s\n", *argv, show_date_relative(t, 0, now));
+ }
+}
- for (i = 1; i < argc; i++) {
+static void parse_dates(char **argv, struct timeval *now)
+{
+ for (; *argv; argv++) {
char result[100];
time_t t;
- memcpy(result, "bad", 4);
- parse_date(argv[i], result, sizeof(result));
+ parse_date(*argv, result, sizeof(result));
t = strtoul(result, NULL, 0);
- printf("%s -> %s -> %s", argv[i], result, ctime(&t));
+ printf("%s -> %s\n", *argv,
+ t ? show_date(t, 0, DATE_ISO8601) : "bad");
+ }
+}
+
+static void parse_approxidate(char **argv, struct timeval *now)
+{
+ for (; *argv; argv++) {
+ time_t t;
+ t = approxidate_relative(*argv, now);
+ printf("%s -> %s\n", *argv, show_date(t, 0, DATE_ISO8601));
+ }
+}
- t = approxidate(argv[i]);
- printf("%s -> %s\n", argv[i], ctime(&t));
+int main(int argc, char **argv)
+{
+ struct timeval now;
+ const char *x;
+
+ x = getenv("TEST_DATE_NOW");
+ if (x) {
+ now.tv_sec = atoi(x);
+ now.tv_usec = 0;
}
+ else
+ gettimeofday(&now, NULL);
+
+ argv++;
+ if (!*argv)
+ usage(usage_msg);
+ if (!strcmp(*argv, "show"))
+ show_dates(argv+1, &now);
+ else if (!strcmp(*argv, "parse"))
+ parse_dates(argv+1, &now);
+ else if (!strcmp(*argv, "approxidate"))
+ parse_approxidate(argv+1, &now);
+ else
+ usage(usage_msg);
return 0;
}
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox