* Re: [PATCH 5/5] fetch: Clean output
From: Santi @ 2006-09-30 9:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpsdehzcs.fsf@assigned-by-dhcp.cox.net>
2006/9/30, Junio C Hamano <junkio@cox.net>:
> Santi Béjar <sbejar@gmail.com> writes:
>
> > Do not show duplicated remote branch information and reformat the output as:
> >
> > $ git fetch -v # the committish lines for the -v.
> > * refs/heads/origin: fast forward to remote branch 'master' of ../git/
> > 1ad7a06..bc1a580
> > committish: bc1a580
>
> I am not quite sure about this --- it is not obvious what these
> two numbers represent anymore. Also I think the last line
> outlived its usefulness (99% of the time refs are committish, so
> noting exception is good but otherwise it is not interesting).
I agree in the case of updating a ref, but I would keep it otherwise
(and even in this case only when -v is given).
>
> I know you opted for minimum patch, but it might be a good time
> to polish the wording a bit while we are touching the general
> vicinity of the code.
>
> How about saying something like:
>
> * refs/heads/origin: fast forward to remote branch 'master' of ../git/
> old..new = 1ad7a06..bc1a580
I like it.
>
> > * refs/heads/pu: does not fast forward to remote branch 'pu' of ../git/;
> > 7c733a8...5faa935
> > not updating.
> > forcing update.
> > committish: 5faa935
>
> This is even more confusing. Perhaps we would want to have two
> cases, depending on --force (and +).
Sorry, it was from two copy'n'paste. I did it in a new repository
(without the +), then it stoped at this point (I suppose to force the
user to solve the problem). Then I put the + and did the copy'n'paste
again without deleting this extra line.
>
> * refs/heads/pu: does not fast forward to remote branch 'pu' of ../git/;
> but forcing update anyway. old...new = 7c733a8...5faa935
With the old...new in a new line?
So at the end, something like this output?
$ git fetch -v # the committish lines for the -v.
* refs/heads/origin: fast forward to remote branch 'master' of ../git/
old..new: 1ad7a06..bc1a580
* refs/heads/pu: does not fast forward to remote branch 'pu' of ../git/
old...new: 7c733a8...5faa935
forcing update.
* refs/heads/next: same as remote branch 'origin/next' of ../git/
committish: ce47b9f
...
* refs/tags/v1.4.2-rc4: storing tag 'v1.4.2-rc4' of ../git/
committish: 8c7a107
$ git fetch -v origin refs/heads/master
* committish: 695dffe
branch 'master' of ../git/
Santi
^ permalink raw reply
* Re: What's in git.git
From: Junio C Hamano @ 2006-09-30 7:31 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060929083208.GL13132@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
>> - - You can use git after building but without installing if you
>>...
>> - export GIT_EXEC_PATH PATH GITPERLLIB
>> -
>> - Git is reasonably self-sufficient, but does depend on a few external
>> programs and libraries:
>
> The passage should be kept and even GITPERLLIB - just drop the second
> path after the colon.
Thanks.
^ permalink raw reply
* Re: git and time
From: Junio C Hamano @ 2006-09-30 7:28 UTC (permalink / raw)
To: Shawn Pearce; +Cc: git
In-Reply-To: <20060930045037.GB18479@spearce.org>
Shawn Pearce <spearce@spearce.org> writes:
> Agreed. I've been missing such a command and have wanted to add
> one but it wasn't important enough to me to actually code it. :)
Everything you said in your message sounds sane and makes sense
to me. Now we have to find a sucker^Wvolunteer to implement it
;-).
^ permalink raw reply
* [ANNOUNCE] GIT 1.4.2.2
From: Junio C Hamano @ 2006-09-30 6:53 UTC (permalink / raw)
To: git; +Cc: linux-kernel
The latest maintenance release GIT 1.4.2.2 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.4.2.2.tar.{gz,bz2} (tarball)
git-htmldocs-1.4.2.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.4.2.2.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.4.2.2-1.$arch.rpm (RPM)
This is strictly a bugfix release. While we will soon be in
stabilization slow-down for 1.4.3, one of the bugs this release
contains fixes for actually has bitten people who use the kernel
commits mailing list, so this is to push the fixes out early.
----------------------------------------------------------------
Changes since v1.4.2.1 are as follows:
Junio C Hamano:
Fix git-am safety checks
git-diff -B output fix.
Liu Yubao:
Fix duplicate xmalloc in builtin-add
^ permalink raw reply
* [ANNOUNCE qgit-1.5.2] bug fix release
From: Marco Costalba @ 2006-09-30 6:30 UTC (permalink / raw)
To: Git Mailing List, linux-kernel
This is mostly a bug fix release.
Fixes are all over the place but most important are the fixes to code
range filtering.
Code range filtering is when you select some text in file viewer and
want to view the list of revisions that modified that code range.
Download tarball from http://www.sourceforge.net/projects/qgit
or directly from git public repository
git://git.kernel.org/pub/scm/qgit/qgit.git
Please refer to http://digilander.libero.it/mcostalba/ for additional
information.
Marco
ChangeLog from 1.5.1
- fix a memory leak in case annotation is closed while processing
- fix a rare segfault due to a race in annotation code
- fix commit when the change in working dir is a file deletion
- fix file list is not cleared when changing to revision with no files
- load file history without --topo-order option
- fix bold file content after removing range filter
- fix range filter miscalculation
- fixed two bugs in range filter code
- fix file view font to match main view one
- fix date/time column title issues
- fix a very rare hang on exit
- refactor exceptions handling code
^ permalink raw reply
* Re: git and time
From: Shawn Pearce @ 2006-09-30 4:50 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Theodore Tso, Linus Torvalds, Andreas Ericsson,
git, Jeff King, Jakub Narebski
In-Reply-To: <7vd59ejokp.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> The more I think about this, if we were to add yet another
> command, I think it should be a command that lets us inspect
> ref-log. We do not have an UI other than @{time} syntax to
> interact with it right now.
Agreed. I've been missing such a command and have wanted to add
one but it wasn't important enough to me to actually code it. :)
> What are the things we would want? Here is a strawman.
>
> - List when and how a branch was changed.
>
> git ref-log --list --type=merge next (when did I merge into my 'next'?)
> git ref-log --list --type=merge (ditto but any branches)
> git ref-log --list next (any changes not just 'merge')
>
> I expect the output would give timestamp and reason comment;
> in addition the branch name when no branch is specified.
> Type does not have to be a concrete thing -- it could just be
> a substring match in the reason comment string.
What about --grep=pat instead of --type?
You are talking about essentially the same behavior as
`git log --grep=pat` except applying it to the message
in the reflog rather than to message in the commits.
Also I think that this should be the default behavior
and thus --list shouldn't be an option. This matches
git-log's default behavior to just show whatever is
in the named branches.
> Also we would limit output with -n <limit>.
I'd limit with "--max-count=<n>" like we do with git-log.
> The output
> should be sorted by the timestamp of ref-log entry -- we are
> talking about a particular repository's ref-log, so its
> timestamp has more sane meaning than in distributed case.
Agreed, sorting newest -> oldest so newest displays first, much as
git-log does. This way its order of operation, much as git-log is
order of operation.
If multiple branches are specified we really should interleave the
various reflogs according to timestamps, to show the "global picture"
of what happened in this repository.
> - Find which branches currently contains a commit, and find the
> earliest time that the commit became part of each of them.
>
> git ref-log $commit next master (when did it enter 'next' and
> when did it graduate to 'master'?)
> git ref-log $commit (ditto but any branches)
Since I'm suggesting above that this behavior not be the default
what about:
git ref-log --arrive=$commit next master
git ref-log --arrive=$commit
?
> I expect the output to be the timestamp and reason comment;
> in addition the branch name when no branch is specified.
Agreed.
> Also for a shared repository, the person who made the change
> would be a reasonable thing to report.
I think that should be shown no matter what; even if
core.sharedRepository is false.
> So for consistency, in all cases we could make the output
> format like this:
>
> branch SP time-and-zone SP name SP email SP reason-comment LF
That's too long of a line with most reason-comments in the ref-log.
Especially ones that come from git-commit, and especially if they
were human written commit messages.
I'd like to see the output be more like git-log. Allow a --pretty
option with a few useful formats:
--pretty=full:
branch branchname LF
from old
to new
Modifier: name SP email
Date: time-and-zone
reason-comment
--pretty=oneline:
branchname SP time-and-zone SP name SP email SP reason-comment LF
--pretty=raw is obviously the exact line in the reflog but with
the branch name preceeding it if more than one branch was specified
or none were specified.
And --pretty=full should be the default, much as --pretty=medium
is with git-log.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 5/5] fetch: Clean output
From: Junio C Hamano @ 2006-09-30 2:17 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <8764f61r74.fsf@gmail.com>
Santi Béjar <sbejar@gmail.com> writes:
> Do not show duplicated remote branch information and reformat the output as:
>
> $ git fetch -v # the committish lines for the -v.
> * refs/heads/origin: fast forward to remote branch 'master' of ../git/
> 1ad7a06..bc1a580
> committish: bc1a580
I am not quite sure about this --- it is not obvious what these
two numbers represent anymore. Also I think the last line
outlived its usefulness (99% of the time refs are committish, so
noting exception is good but otherwise it is not interesting).
I know you opted for minimum patch, but it might be a good time
to polish the wording a bit while we are touching the general
vicinity of the code.
How about saying something like:
* refs/heads/origin: fast forward to remote branch 'master' of ../git/
old..new = 1ad7a06..bc1a580
> * refs/heads/pu: does not fast forward to remote branch 'pu' of ../git/;
> 7c733a8...5faa935
> not updating.
> forcing update.
> committish: 5faa935
This is even more confusing. Perhaps we would want to have two
cases, depending on --force (and +).
* refs/heads/pu: does not fast forward to remote branch 'pu' of ../git/;
but forcing update anyway. old...new = 7c733a8...5faa935
* refs/heads/pu: does not fast forward to remote branch 'pu' of ../git/;
not updating. old...new = 7c733a8...5faa935
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: hash_base and hash are now context sensitive
From: Luben Tuikov @ 2006-09-29 23:30 UTC (permalink / raw)
To: Jakub Narebski, Junio Hamano; +Cc: git
In-Reply-To: <200609292235.27478.jnareb@gmail.com>
--- Jakub Narebski <jnareb@gmail.com> wrote:
> As a interim solution it is a good idea, moreover with using $hash_base
> defaulting to HEAD instead of using HEAD literaly.
>
> The correct solution would be to make "html" page (i.e. "blob" not
> "blob_plain" view) also for binary files. <img> element for image/*
> mimetype, perhaps <embed> or <object>, or just plain link for other
> binary (not text/* or some application/*) types
We already do have a hash_base context. It is what allows us to
"select" a revision from shortlog and ask "tree", "history", etc
from there on, having set "h" and/or "hb".
What this patch does is simply set "h" and/or "hb" to
the string "HEAD" instead of the string "<SHA1 of HEAD>" when
h/hb is not defined.
Luben
>
> I was AFK for few days.
> --
> Jakub Narebski
> Poland
>
^ permalink raw reply
* Re: [PATCH] branch: write branch properties
From: Santi @ 2006-09-29 22:47 UTC (permalink / raw)
To: git
In-Reply-To: <87d59kok0l.fsf@gmail.com>
> [PATCH] branch: write branch properties
>
> If you want to work in the 'next' branch of git.git:
>
> $ git clone --use-separate-remote git://git.kernel.org/pub/scm/git/git.git
> $ cd git
> $ git branch next origin refs/heads/next
> ... work/edit/commit ...
> $ git pull
>
> and it merges from branch 'refs/heads/next' of origin.
>
Any comments on this?
Possible comments :D
- No comments
- Not interested
- Not interesting
- I like the idea but not the patch because...
- I like the patch but not the idea (?)
- Broken syntax. Could be done in this other way...
- Stop all this crazy things, just config all this manually!
- Start more crazy things, like...
- ...
Santi
^ permalink raw reply
* Re: [PATCH] gitweb: start to generate PATH_INFO URLs
From: Junio C Hamano @ 2006-09-29 22:30 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060929221641.GC2871@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
> Instead of providing the project as a ?p= parameter it is simply appended
> to the base URI.
> All other parameters are appended to that, except for ?a=summary which
> is the default and can be omitted.
Supporting PATH_INFO in the sense that we do sensible things
when we get called with one is one thing, but generating such a
URL that uses PATH_INFO is a different thing. I suspect not
everybody's webserver is configured to call us with PATH_INFO,
so this should be conditional.
^ permalink raw reply
* Re: git and time
From: Junio C Hamano @ 2006-09-29 22:27 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Theodore Tso, Linus Torvalds, Andreas Ericsson, Shawn Pearce, git,
Jeff King, Jakub Narebski
In-Reply-To: <Pine.LNX.4.64.0609281029300.9349@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Wed, 27 Sep 2006, Junio C Hamano wrote:
>
>> Nicolas Pitre <nico@cam.org> writes:
>>
>> > SYNOPSIS
>> >
>> > git-local-arrival <committish>
>> >
>> > DESCRIPTION
>> >
>> > The command displays the time when given commit appeared in the
>> > local repository.
>>
>> This should be certainly doable, but local-arrival may not be
>> interesting if the repository has more than one branches. Maybe
>>
>> git-local-arrival <committish> [<branch>]
>>
>> which defaults to the current branch?
>
> Indeed. I didn't mention it initially because it is really easy to do
> once you have it working for the current branch. The technical
> challenge is about making it efficient to find out which reflog entry
> with a path to given commit is the oldest.
The more I think about this, if we were to add yet another
command, I think it should be a command that lets us inspect
ref-log. We do not have an UI other than @{time} syntax to
interact with it right now.
What are the things we would want? Here is a strawman.
- List when and how a branch was changed.
git ref-log --list --type=merge next (when did I merge into my 'next'?)
git ref-log --list --type=merge (ditto but any branches)
git ref-log --list next (any changes not just 'merge')
I expect the output would give timestamp and reason comment;
in addition the branch name when no branch is specified.
Type does not have to be a concrete thing -- it could just be
a substring match in the reason comment string.
Also we would limit output with -n <limit>. The output
should be sorted by the timestamp of ref-log entry -- we are
talking about a particular repository's ref-log, so its
timestamp has more sane meaning than in distributed case.
- Find which branches currently contains a commit, and find the
earliest time that the commit became part of each of them.
git ref-log $commit next master (when did it enter 'next' and
when did it graduate to 'master'?)
git ref-log $commit (ditto but any branches)
I expect the output to be the timestamp and reason comment;
in addition the branch name when no branch is specified.
Also for a shared repository, the person who made the change
would be a reasonable thing to report.
So for consistency, in all cases we could make the output
format like this:
branch SP time-and-zone SP name SP email SP reason-comment LF
where time-and-zone is human-readable timestamp as we see in
git-log output.
^ permalink raw reply
* [PATCH] gitweb: start to generate PATH_INFO URLs
From: Martin Waitz @ 2006-09-29 22:16 UTC (permalink / raw)
To: git
Instead of providing the project as a ?p= parameter it is simply appended
to the base URI.
All other parameters are appended to that, except for ?a=summary which
is the default and can be omitted.
Signed-off-by: Martin Waitz <tali@admingilde.org>
---
gitweb/gitweb.perl | 15 ++++++++++++++-
1 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 597d29f..e507ce9 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -355,6 +355,7 @@ ## action links
sub href(%) {
my %params = @_;
+ my $href;
my @mapping = (
project => "p",
@@ -373,6 +374,16 @@ sub href(%) {
$params{'project'} = $project unless exists $params{'project'};
+ # first encode base url and project
+ $href = "$my_uri/$params{'project'}";
+ delete $params{'project'};
+
+ # Summary just uses the project path URL
+ if ($params{'action'} eq 'summary') {
+ return $href;
+ }
+
+ # now encode the parameters explicitly
my @result = ();
for (my $i = 0; $i < @mapping; $i += 2) {
my ($name, $symbol) = ($mapping[$i], $mapping[$i+1]);
@@ -380,7 +391,9 @@ sub href(%) {
push @result, $symbol . "=" . esc_param($params{$name});
}
}
- return "$my_uri?" . join(';', @result);
+ $href .= "?" . join(';', @result);
+
+ return $href;
}
--
1.4.2.gb8b6b
--
Martin Waitz
^ permalink raw reply related
* Re: [PATCH 0/5] fetch & co: misc output cleanup
From: Junio C Hamano @ 2006-09-29 21:27 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: git, Santi Béjar
In-Reply-To: <451D6BDB.50900@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> writes:
> Santi Béjar wrote:
>> this patchset includes:
>>
>> fetch: Reset remote refs list each time fetch_main is called
>> fetch & co: Use "hash1..hash2" instead of "from hash1 to hash2"
>> fetch & co: Use short sha1 in the output
>> fetch: Add output for the not fast forward case
>> fetch: Clean output
>
> Please do not make short ID output the default. That is, unless you
> can somehow guarantee that the short ID reported today will _always_
> be unambiguous even with future additions to the repository.
I would understand your worries of spitting out only abbreviated
object names if they appear in a document to be preserved for a
long term. But we are talking about output to stderr to help
people see what happened in the operation they initiated a few
moments ago, and to help them use the output for cut&paste while
it is still in the scrollbuffer of the terminal.
Shortening them would help A..B avoid crossing the line
boundaries, which terminal emulators have trouble with cutting
sometimes. That benefit may outweigh the longer term ambiguity
concerns.
The only real-life situation I can imagine the program output is
preserved in any longer term than immediate consumption for
cut&paste is to paste it into a piece of e-mail (which is
archived), to show exactly what the program said to the user.
But then it carries the timestamp and you should be able to
figure out what the abbreviation uniquely stood for back then if
you really cared. If you are producing a document for longer
term storage, the program that produces such a document should
be doing its own rev-parse anyway (or maybe pass whatever it is
piping through git-name-rev --stdin).
I think it is Ok to always use the abbreviated form in the
places Santi's patch touched, as long as people understand these
messages are not for long term storage. We might want to use a
bit longer abbreviation than the default (7 hexdigits).
^ permalink raw reply
* Re: git and time
From: Jakub Narebski @ 2006-09-29 20:58 UTC (permalink / raw)
To: Junio C Hamano, git
In-Reply-To: <7vodt2nmft.fsf@assigned-by-dhcp.cox.net>
Junio C. Hamano wrote:
> I somehow thought that it was possible to get "the latest tag
> that precedes this commit" (aka "git describe") for each commit
> by visiting its commitdiff_plain page, but I do not see it now.
> Can somebody tell me if I am hallucinating?
No, as of now "commitdiff_plain" or "commit_plain" view shows either
git-name-rev information, or just tag if the tag points exactly at
given [child] commit, not git-describe information. Although it would
be fairly easy to add this information, though...
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH 0/5] fetch & co: misc output cleanup
From: Santi @ 2006-09-29 20:48 UTC (permalink / raw)
To: git
In-Reply-To: <451D6BDB.50900@gmail.com>
2006/9/29, A Large Angry SCM <gitzilla@gmail.com>:
> Santi Béjar wrote:
> > this patchset includes:
> >
> > fetch: Reset remote refs list each time fetch_main is called
> > fetch & co: Use "hash1..hash2" instead of "from hash1 to hash2"
> > fetch & co: Use short sha1 in the output
> > fetch: Add output for the not fast forward case
> > fetch: Clean output
>
> Please do not make short ID output the default. That is, unless you can
> somehow guarantee that the short ID reported today will _always_ be
> unambiguous even with future additions to the repository.
>
There is not such guarantee. But the fetch output is to be use
immediately in git-log, etc. If you want these "guarantees" you must
know that you have to keep the long version.
By the way, is there a way to show all the commits,tags,... that
abbreviate to a short hash? This way instead of just saying "bad
revision" we could show the list of possible revisions.
Also, git-log & co also output abbreviated hashes by default. So why
not for git-fetch?
Santi
^ permalink raw reply
* Re: git and time
From: Jakub Narebski @ 2006-09-29 20:42 UTC (permalink / raw)
To: Matthew L Foster; +Cc: git
In-Reply-To: <20060927222854.82278.qmail@web51014.mail.yahoo.com>
Matthew L. Foster wrote:
> If the local merge time information is already available in the
> ref-log then gitweb.cgi might only need to be made aware of it.
It is planned to add reflog support (view) to gitweb.
But of course the repository that is under gitweb has to have reflog
_enabled_ to be able to view it.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] gitweb: tree view: hash_base and hash are now context sensitive
From: Jakub Narebski @ 2006-09-29 20:35 UTC (permalink / raw)
To: Junio Hamano, Luben Tuikov; +Cc: git
In-Reply-To: <20060929161619.24848.qmail@web31806.mail.mud.yahoo.com>
Luben Tuikov wrote:
> --- Junio C Hamano <junkio@cox.net> wrote:
> > > What are the objections to this patch?
> >
> > No objections from me --- rather lack of objections from Jakub ;-)
>
> We haven't heard anything from him, and on our last correspondence
> in this thread it seemed we're in agreement.
As a interim solution it is a good idea, moreover with using $hash_base
defaulting to HEAD instead of using HEAD literaly.
The correct solution would be to make "html" page (i.e. "blob" not
"blob_plain" view) also for binary files. <img> element for image/*
mimetype, perhaps <embed> or <object>, or just plain link for other
binary (not text/* or some application/*) types
I was AFK for few days.
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] Use "hash1..hash2" instead of "from hash1 to hash2"
From: Carl Worth @ 2006-09-29 19:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Santi Béjar, git
In-Reply-To: <7v7iznquc4.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 840 bytes --]
On Thu, 28 Sep 2006 19:28:59 -0700, Junio C Hamano wrote:
>
> You may be doing this to help Cut & Paste. Using A..B without
> spaces in between makes it easy to grab both at the same time as
> a range to give them to "git log". At the same time it makes it
> harder to pick only A or B, so this is two-edged.
>
I had requested this change once to help cut and paste.
The current behavior I get for selecting hash1..hash2 with (for
example) gnome-terminal is somewhat unfortunate, (double-clicking on
any character selects the pair plus the separator). Obviously, '.'
must be considered a word character, not a separator. I wonder if such
selection is easily capable of being told to consider ".." a word
separator? If so, it seems the output would be quite convenient
whether one or two of the hashes were desired for selection.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Fix approxidate() to understand more extended numbers
From: Linus Torvalds @ 2006-09-29 19:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vslibno88.fsf@assigned-by-dhcp.cox.net>
On Fri, 29 Sep 2006, Junio C Hamano wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
> >
> > If you write
> >
> > 12:30 am
> >
> > you really _should_ subtract 12, leaving you with 0:30. We don't. So we
> > end up with a 24-hour time of 12:30, which is obviously _pm_, and wrong.
> >
> > And "12 am" or "12 pm" doesn't work at all.
>
> Ah, that's what you meant. My brain a bit too tired from the
> day job tonight X-<.
Here's a patch that should work. It just simplifies the whole thing to say
"hour = (hour % 12) + X"
where X is 12 for PM and 0 for AM.
It also fixes the "exact date" parsing, which didn't parse AM at all, and
as such would do the same "12:30 AM" means "12:30 24-hour-format" bug. Of
course, I hope that no exact dates use AM/PM anyway, but since we support
the PM format, let's just get it right.
Not hugely tested, but I did test some of it, and it all _looks_ sane.
Linus
---
diff --git a/date.c b/date.c
index db4c185..1825922 100644
--- a/date.c
+++ b/date.c
@@ -256,8 +256,12 @@ static int match_alpha(const char *date,
}
if (match_string(date, "PM") == 2) {
- if (tm->tm_hour > 0 && tm->tm_hour < 12)
- tm->tm_hour += 12;
+ tm->tm_hour = (tm->tm_hour % 12) + 12;
+ return 2;
+ }
+
+ if (match_string(date, "AM") == 2) {
+ tm->tm_hour = (tm->tm_hour % 12) + 0;
return 2;
}
@@ -600,28 +604,30 @@ static void date_tea(struct tm *tm, int
static void date_pm(struct tm *tm, int *num)
{
- int hour = *num;
+ int hour, n = *num;
*num = 0;
- if (hour > 0 && hour < 12) {
- tm->tm_hour = hour;
+ hour = tm->tm_hour;
+ if (n) {
+ hour = n;
tm->tm_min = 0;
tm->tm_sec = 0;
}
- if (tm->tm_hour > 0 && tm->tm_hour < 12)
- tm->tm_hour += 12;
+ tm->tm_hour = (hour % 12) + 12;
}
static void date_am(struct tm *tm, int *num)
{
- int hour = *num;
+ int hour, n = *num;
*num = 0;
- if (hour > 0 && hour < 12) {
- tm->tm_hour = hour;
+ hour = tm->tm_hour;
+ if (n) {
+ hour = n;
tm->tm_min = 0;
tm->tm_sec = 0;
}
+ tm->tm_hour = (hour % 12);
}
static const struct special {
^ permalink raw reply related
* Re: [PATCH 0/5] fetch & co: misc output cleanup
From: A Large Angry SCM @ 2006-09-29 18:54 UTC (permalink / raw)
To: Santi Béjar; +Cc: git
In-Reply-To: <87r6xu1rci.fsf@gmail.com>
Santi Béjar wrote:
> this patchset includes:
>
> fetch: Reset remote refs list each time fetch_main is called
> fetch & co: Use "hash1..hash2" instead of "from hash1 to hash2"
> fetch & co: Use short sha1 in the output
> fetch: Add output for the not fast forward case
> fetch: Clean output
Please do not make short ID output the default. That is, unless you can
somehow guarantee that the short ID reported today will _always_ be
unambiguous even with future additions to the repository.
^ permalink raw reply
* kernel.org problems?
From: Johannes Schindelin @ 2006-09-29 18:37 UTC (permalink / raw)
To: git
Hi,
when I try fetching from kernel.org, I get
fatal: read error (Connection reset by peer)
Fetch failure: git://git.kernel.org/pub/scm/git/git.git
all the time. Fetching by HTTP instead of git protocol works fine, though.
What is happening?
Ciao,
Dscho
^ permalink raw reply
* [PATCH 5/5] fetch: Clean output
From: Santi Béjar @ 2006-09-29 18:08 UTC (permalink / raw)
To: git
In-Reply-To: <87r6xu1rci.fsf@gmail.com>
Do not show duplicated remote branch information and reformat the output as:
$ git fetch -v # the committish lines for the -v.
* refs/heads/origin: fast forward to remote branch 'master' of ../git/
1ad7a06..bc1a580
committish: bc1a580
* refs/heads/pu: does not fast forward to remote branch 'pu' of ../git/;
7c733a8...5faa935
not updating.
forcing update.
committish: 5faa935
* refs/heads/next: same as remote branch 'origin/next' of ../git/
committish: ce47b9f
...
* refs/tags/v1.4.2-rc4: storing tag 'v1.4.2-rc4' of ../git/
committish: 8c7a107
$ git fetch -v origin refs/heads/master
* committish: 695dffe
branch 'master' of ../git/
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
git-fetch.sh | 15 +++++++++++----
1 files changed, 11 insertions(+), 4 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index ee4f5bd..cc71612 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -129,19 +129,26 @@ append_fetch_head () {
then
headc_=$(git-rev-parse --verify "$head_^0") || exit
echo "$headc_ $not_for_merge_ $note_" >>"$GIT_DIR/FETCH_HEAD"
- [ "$verbose" ] && echo >&2 "* committish: $(git-rev-parse --short $head_)"
- [ "$verbose" ] && echo >&2 " $note_"
+ committish=committish
else
echo "$head_ not-for-merge $note_" >>"$GIT_DIR/FETCH_HEAD"
- [ "$verbose" ] && echo >&2 "* non-commit: $(git-rev-parse --short $head_)"
- [ "$verbose" ] && echo >&2 " $note_"
+ committish=non-commit
fi
+ star_prefix="*"
if test "$local_name_" != ""
then
# We are storing the head locally. Make sure that it is
# a fast forward (aka "reverse push").
fast_forward_local "$local_name_" "$head_" "$note_"
+ exit=$?
+ star_prefix=" "
fi
+ if test "$verbose"
+ then
+ echo >&2 "$star_prefix $committish: $(git-rev-parse --short $head_)"
+ [ -z "$local_name_" ] && echo >&2 " $note_"
+ fi
+ return ${exit:-0}
}
fast_forward_local () {
--
1.4.2.1.g38049
^ permalink raw reply related
* [PATCH 4/5] fetch: Add output for the not fast forward case
From: Santi Béjar @ 2006-09-29 18:07 UTC (permalink / raw)
To: git
In-Reply-To: <87r6xu1rci.fsf@gmail.com>
Use the ... notation to be able to use this directly in "git log" to see
how the two non-fast-forward heads have diverged.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
git-fetch.sh | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index 32553f8..ee4f5bd 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -190,6 +190,7 @@ fast_forward_local () {
;;
esac || {
echo >&2 "* $1: does not fast forward to $3;"
+ echo >&2 " $(git-rev-parse --short $local)...$(git-rev-parse --short $2)"
case ",$force,$single_force," in
*,t,*)
echo >&2 " forcing update."
--
1.4.2.1.g38049
^ permalink raw reply related
* [PATCH 3/5] fetch & co: Use short sha1 in the output
From: Santi Béjar @ 2006-09-29 18:06 UTC (permalink / raw)
To: git
In-Reply-To: <87r6xu1rci.fsf@gmail.com>
... for brevity.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
git-fetch.sh | 6 +++---
git-merge.sh | 2 +-
git-resolve.sh | 2 +-
3 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index 08d86cd..32553f8 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -129,11 +129,11 @@ append_fetch_head () {
then
headc_=$(git-rev-parse --verify "$head_^0") || exit
echo "$headc_ $not_for_merge_ $note_" >>"$GIT_DIR/FETCH_HEAD"
- [ "$verbose" ] && echo >&2 "* committish: $head_"
+ [ "$verbose" ] && echo >&2 "* committish: $(git-rev-parse --short $head_)"
[ "$verbose" ] && echo >&2 " $note_"
else
echo "$head_ not-for-merge $note_" >>"$GIT_DIR/FETCH_HEAD"
- [ "$verbose" ] && echo >&2 "* non-commit: $head_"
+ [ "$verbose" ] && echo >&2 "* non-commit: $(git-rev-parse --short $head_)"
[ "$verbose" ] && echo >&2 " $note_"
fi
if test "$local_name_" != ""
@@ -182,7 +182,7 @@ fast_forward_local () {
;;
*,$local)
echo >&2 "* $1: fast forward to $3"
- echo >&2 " $local..$2"
+ echo >&2 " $(git-rev-parse --short $local)..$(git-rev-parse --short $2)"
git-update-ref -m "$rloga: fast-forward" "$1" "$2" "$local"
;;
*)
diff --git a/git-merge.sh b/git-merge.sh
index fd587c5..49c46d5 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -197,7 +197,7 @@ f,*)
;;
?,1,"$head",*)
# Again the most common case of merging one remote.
- echo "Updating $head..$1"
+ echo "Updating $(git-rev-parse --short $head)..$(git-rev-parse --short $1)"
git-update-index --refresh 2>/dev/null
new_head=$(git-rev-parse --verify "$1^0") &&
git-read-tree -u -v -m $head "$new_head" &&
diff --git a/git-resolve.sh b/git-resolve.sh
index 6e4fb02..36b90e3 100755
--- a/git-resolve.sh
+++ b/git-resolve.sh
@@ -46,7 +46,7 @@ case "$common" in
exit 0
;;
"$head")
- echo "Updating $head..$merge"
+ echo "Updating $(git-rev-parse --short $head)..$(git-rev-parse --short $merge)"
git-read-tree -u -m $head $merge || exit 1
git-update-ref -m "resolve $merge_name: Fast forward" \
HEAD "$merge" "$head"
--
1.4.2.1.g38049
^ permalink raw reply related
* [PATCH 2/5] fetch & co: Use "hash1..hash2" instead of "from hash1 to hash2"
From: Santi Béjar @ 2006-09-29 18:06 UTC (permalink / raw)
To: git
In-Reply-To: <87r6xu1rci.fsf@gmail.com>
I find it shorter, easier to copy&paste and cleaner.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
git-fetch.sh | 2 +-
git-merge.sh | 2 +-
git-resolve.sh | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-fetch.sh b/git-fetch.sh
index f1522bd..08d86cd 100755
--- a/git-fetch.sh
+++ b/git-fetch.sh
@@ -182,7 +182,7 @@ fast_forward_local () {
;;
*,$local)
echo >&2 "* $1: fast forward to $3"
- echo >&2 " from $local to $2"
+ echo >&2 " $local..$2"
git-update-ref -m "$rloga: fast-forward" "$1" "$2" "$local"
;;
*)
diff --git a/git-merge.sh b/git-merge.sh
index 5b34b4d..fd587c5 100755
--- a/git-merge.sh
+++ b/git-merge.sh
@@ -197,7 +197,7 @@ f,*)
;;
?,1,"$head",*)
# Again the most common case of merging one remote.
- echo "Updating from $head to $1"
+ echo "Updating $head..$1"
git-update-index --refresh 2>/dev/null
new_head=$(git-rev-parse --verify "$1^0") &&
git-read-tree -u -v -m $head "$new_head" &&
diff --git a/git-resolve.sh b/git-resolve.sh
index 729ec65..6e4fb02 100755
--- a/git-resolve.sh
+++ b/git-resolve.sh
@@ -46,7 +46,7 @@ case "$common" in
exit 0
;;
"$head")
- echo "Updating from $head to $merge"
+ echo "Updating $head..$merge"
git-read-tree -u -m $head $merge || exit 1
git-update-ref -m "resolve $merge_name: Fast forward" \
HEAD "$merge" "$head"
--
1.4.2.1.g38049
^ 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