GIT 0.99.9

GIT 0.99.9

[Junio C Hamano]

GIT 0.99.9 is found at usual places.

As I said in the 0.99.8 announcement, git already does
everything I want it to do, and from here on I'd like to see us
concentrate on fixes (both correctness and performance) until we
hit 1.0 which should happen shortly.

Many thanks to everybody who contributed the comments, extra set
of eyeballs, and code.


Done in 0.99.9
==============

Ports
~~~~~

* Cygwin port [HPA].

* OpenBSD build [Merlyn and others].


Fixes
~~~~~

* clone request over git native protocol from a repository with
  too many refs did not work; this has been fixed.

* git-daemon got safer for kernel.org use [HPA].

* Extended SHA1 parser was not enforcing uniqueness for
  abbreviated SHA1; this has been fixed.

* http transport does not barf on funny characters in URL.

* The ref naming restrictions have been formalized and the
  coreish refuses to create funny refs; we still need to audit
  importers.  See git-check-ref-format(1).


New Features and Commands
~~~~~~~~~~~~~~~~~~~~~~~~~

* .git/config file as a per-repository configuration mechanism,
  and some commands understand it [Linus].  See
  git(7).

* The core.filemode configuration item can be used to make us a
  bit more FAT friendly.  See git(7).

* The extended SHA1 notation acquired Peel-the-onion operator
  ^{type} and ^{}.  See git-rev-parse(1).

* SVN importer [Matthias].  See git-svnimport(1).

* .git/objects/[0-9a-f]{2} directories are created on demand,
  and removed when becomes empty after prune-packed [Linus].

* Filenames output from various commands without -z option are
  quoted when they embed funny characters (TAB and LF) using
  C-style quoting within double-quotes, to match the proposed
  GNU diff/patch notation [me, but many people contributed in
  the discussion].

* git-mv is expected to be a better replacement for git-rename.
  While the latter has two parameter restriction, it acts more
  like the regular 'mv' that can move multiple things to one
  destinatino directory [Josef Weidendorfer].

* git-checkout can take filenames to revert the changes to
  them.  See git-checkout(1)

* The new program git-am is a replacement for git-applymbox that
  has saner command line options and a bit easier to use when a
  patch does not apply cleanly.

* git-ls-remote can show unwrapped onions using ^{} notation, to
  help Cogito to track tags.

* git-merge-recursive backend can merge unrelated projects.

* git-clone over native transport leaves the result packed.

* git-http-fetch issues multiple requests in parallel when
  underlying cURL library supports it [Nick and Daniel].

* git-fetch-pack and git-upload-pack try harder to figure out
  better common commits [Johannes].

* git-read-tree -u removes a directory when it makes it empty.

* git-diff-* records abbreviated SHA1 names of original and
  resulting blob; this sometimes helps to apply otherwise an
  unapplicable patch by falling back to 3-way merge.

* git-format-patch now takes series of from..to rev ranges and
  with '-m --stdout', writes them out to the standard output.
  This can be piped to 'git-am' to implement cheaper
  cherry-picking.

* git-tag takes '-u' to specify the tag signer identity [Linus].

* git-rev-list can take optional pathspecs to skip commits that
  do not touch them (--dense) [Linus].

* Comes with new and improved gitk [Paulus and Linus].

Re: GIT 0.99.9

[A Large Angry SCM]

Junio C Hamano wrote:
> GIT 0.99.9 is found at usual places.
> 
> As I said in the 0.99.8 announcement, git already does
> everything I want it to do, and from here on I'd like to see us
> concentrate on fixes (both correctness and performance) until we
> hit 1.0 which should happen shortly.
> 
> Many thanks to everybody who contributed the comments, extra set
> of eyeballs, and code.
> 
> 
> Done in 0.99.9
> ==============
[Lots of text deleted]

It's nice to see the TODO list get shorter for a change! Especially 
since the removed TODO items are not on the HAVEDONE list.

So, with 0.99.9 being the (non) "scary" release of Git, are you 
targeting the Git 1.0 to be the (non) "turkey" release or the "fruit 
cake" release? ;-)

Re: GIT 0.99.9

[Junio C Hamano]

A Large Angry SCM <gitzilla@gmail.com> writes:

> It's nice to see the TODO list get shorter for a change! Especially 
> since the removed TODO items are not on the HAVEDONE list.

Huh?  What are you talking about?

Most of the items that were on the TODO list and marked [DONE]
are on the HAVEDONE list, although I rephrased many of them to
be more appropriate for the release notes.  The only thing that
I did not list on HAVEDONE list was 'whatchanged -m'
documentation.  There are many documentation contributions from
the list I do not mention in HAVEDONE.

I dropped from the TODO list was the "Perhaps show ^{commit},
^{tree} instead of ^{} from ls-remote", whose benefit was
dubious.

Re: GIT 0.99.9

[A Large Angry SCM]

Junio C Hamano wrote:
> A Large Angry SCM <gitzilla@gmail.com> writes:
> 
>>It's nice to see the TODO list get shorter for a change! Especially 
>>since the removed TODO items are not on the HAVEDONE list.
                                    ^^^
Oops! The ``not'' wasn't supposed to be there!!!!

> 
> Huh?  What are you talking about?

My typing was in error. The ``not'' should not have been there.

> Most of the items that were on the TODO list and marked [DONE]
> are on the HAVEDONE list, although I rephrased many of them to
> be more appropriate for the release notes.  The only thing that
> I did not list on HAVEDONE list was 'whatchanged -m'
> documentation.  There are many documentation contributions from
> the list I do not mention in HAVEDONE.
> 
> I dropped from the TODO list was the "Perhaps show ^{commit},
> ^{tree} instead of ^{} from ls-remote", whose benefit was
> dubious.
> 
> 

Junio, I think you're doing an great job with Git. Particularly, since 
I'm thinking that it may be mature enough to replace another SCM with a 
very large code base that I deal with.

Re: GIT 0.99.9

[Johannes Schindelin]

Hi,

On Sat, 29 Oct 2005, A Large Angry SCM wrote:

> Junio, I think you're doing an great job with Git.

Concur!

> Particularly, since I'm thinking that it may be mature enough to replace 
> another SCM with a very large code base that I deal with.

Add to that the fact that most, if not all, changes are made backwards 
compatible, i.e. git has stable for a *long* time now.

Ciao,
Dscho

Re: GIT 0.99.9

[Linus Torvalds]

On Sat, 29 Oct 2005, Junio C Hamano wrote:
>
> GIT 0.99.9 is found at usual places.

Congrats. I personally think this is very much worthy of a 1.0 after just 
giving it some time to shake out any possible last-minute bugs.

		Linus

rev-list --sparse?

[Junio C Hamano]

I was reviewing the rev-list documentation and it struck me that
dense/sparse command line flag do not make much sense.

Since dense is by default in effect, --dense is a no-op.  One
possible use of it would be to hardcode --dense on a rev-list
command line in a script, like:

	git-rev-list $some_opts --dense $some_paths

to defeat user-supplied --sparse that can be in $some_opts, but
for this to work the script needs to have parsed out user input
into some_opts and some_paths in the first place anyway, so it
can just detect and remove --sparse just as easily.

The --sparse flag does not seem to have much use either; not
giving pathspec has the same effect.

Re: rev-list --sparse?

[Linus Torvalds]

On Sun, 30 Oct 2005, Junio C Hamano wrote:
> 
> The --sparse flag does not seem to have much use either; not
> giving pathspec has the same effect.

No.

--sparse _does_ have effect, but it's subtler.

Try "--sparse" together with a pathspec. It will only do the merge 
follow optimization.

Now, how useful is that? It's potentially useful as a way to "linearize 
the history". For example, let's say that you wanted to simplify the 
commit history for a project, and you only cared about the history of 
certain files - but you do want all the other files to _exist_ in that 
history.

So then you could do "git-rev-list --sparse HEAD -- filelist" and you'd 
get the minimal history that is still relevant in those files. Any merges 
that touch anything else than those files will becomes just regular diffs: 
they'll have been linearized away.

Useful? Quite possibly not. But I felt that simplifying merges was 
conceptually a very different operation from then compressing a linear 
history.

		Linus

Re: rev-list --sparse?

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> Try "--sparse" together with a pathspec. It will only do the merge 
> follow optimization.

Ah, I saw (paths && dense) everywhere but there indeed is one
that only checks paths to call merge simplification -- I missed
that part.

Re: GIT 0.99.9

[Wolfgang Denk]

In message <7vd5lnztav.fsf@assigned-by-dhcp.cox.net> you wrote:
> GIT 0.99.9 is found at usual places.

"make rpm" does not work for me:

...
make -C templates install
make[2]: Entering directory `/usr/local/BUILD/git-core-0.99.9/templates'
: no custom templates yet
find blt
blt
blt/branches
blt/hooks
blt/hooks/post-commit
blt/hooks/applypatch-msg
blt/hooks/commit-msg
blt/hooks/post-update
blt/hooks/update
blt/hooks/pre-applypatch
blt/hooks/pre-commit
blt/info
blt/info/exclude
blt/description
blt/remotes
install -d -m755 '/var/tmp/git-core-0.99.9-1-root-wd/usr/share/git-core/templates/'
(cd blt && tar cf - .) | \
(cd '/var/tmp/git-core-0.99.9-1-root-wd/usr/share/git-core/templates/' && tar xf -)
tar: This does not look like a tar archive
tar: Skipping to next header
tar: Error exit delayed from previous errors
make[2]: *** [install] Error 2
make[2]: Leaving directory `/usr/local/BUILD/git-core-0.99.9/templates'
make[1]: *** [install] Error 2
make[1]: Leaving directory `/usr/local/BUILD/git-core-0.99.9'
error: Bad exit status from /var/tmp/rpm-tmp.96513 (%install)


RPM build errors:
    Bad exit status from /var/tmp/rpm-tmp.96513 (%install)
make: *** [rpm] Error 1


Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
"The computer programmer is a creator of universes for which he alone
is responsible. Universes of virtually unlimited  complexity  can  be
created  in  the  form  of  computer  programs." - Joseph Weizenbaum,
_Computer Power and Human Reason_

Re: GIT 0.99.9

[Junio C Hamano]

Wolfgang Denk <wd@denx.de> writes:

> In message <7vd5lnztav.fsf@assigned-by-dhcp.cox.net> you wrote:
>> GIT 0.99.9 is found at usual places.
>
> "make rpm" does not work for me:

I hate it when somebody tells me "it works for me", but I cannot
help you here, sorry.  I'm no rpm expert and the "make rpm" rule
seems to work for me.

Re: GIT 0.99.9

[Wolfgang Denk]

In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:
> 
> I hate it when somebody tells me "it works for me", but I cannot
> help you here, sorry.  I'm no rpm expert and the "make rpm" rule
> seems to work for me.

Which environment (Linux distribution) did you test this on? I  tried
Fedora  Core  2  and  4,  both  with  the same result. I get the same
problem when building from the git source  tree  or  when  using  the
source RPM.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
A person with one watch knows what time it  is;  a  person  with  two
watches is never sure.                                       Proverb

Re: GIT 0.99.9

[Junio C Hamano]

Wolfgang Denk <wd@denx.de> writes:

> In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:
>> 
>> I hate it when somebody tells me "it works for me", but I cannot
>> help you here, sorry.  I'm no rpm expert and the "make rpm" rule
>> seems to work for me.
>
> Which environment (Linux distribution) did you test this on? I  tried
> Fedora  Core  2  and  4,  both  with  the same result. I get the same
> problem when building from the git source  tree  or  when  using  the
> source RPM.

Whatever is running on kernel.org.  I think I was once told they
run RH-EL but I do not have that e-mail now.

Re: GIT 0.99.9

[Horst von Brand]

Wolfgang Denk <wd@denx.de> wrote:
> In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:
> > I hate it when somebody tells me "it works for me", but I cannot
> > help you here, sorry.  I'm no rpm expert and the "make rpm" rule
> > seems to work for me.

> Which environment (Linux distribution) did you test this on? I  tried
> Fedora  Core  2  and  4,  both  with  the same result. I get the same
> problem when building from the git source  tree  or  when  using  the
> source RPM.

In Fedora rawhide it works (I've got asciidoc installed, and git locally in
my account).
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Re: GIT 0.99.9

[Wolfgang Denk]

In message <7vvezesyhi.fsf@assigned-by-dhcp.cox.net> you wrote:
>
> > "make rpm" does not work for me:
> 
> I hate it when somebody tells me "it works for me", but I cannot
> help you here, sorry.  I'm no rpm expert and the "make rpm" rule
> seems to work for me.

OK, I found the problem. The key part is this:

[current directory: .../usr/share/git-core/templates/]
    (cd blt && tar cf - .) | \
    (cd '/var/tmp/git-core-0.99.9-1-root-wd/usr/share/git-core/templates/' && tar xf -)
    tar: This does not look like a tar archive
    tar: Skipping to next header
    tar: Error exit delayed from previous errors

I have CDPATH set in my  shell  environment,  and  bash  outputs  the
pathname  of  the  new  working  directory on stdout; this gets piped
together with the tarball to the "tar  xf  -",  and  the  second  tar
complains that the directory name comes unexpected. Test:

-> cd /usr/local/BUILD/git-core-0.99.9/templates
-> cd blt
/usr/local/BUILD/git-core-0.99.9/templates/blt
-> 

As a workaround I can simply unset CDPATH, and the build works  fine.
A more robust build script woul make sure that CDPATH is not set.

Best regards,

Wolfgang Denk

-- 
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
Testing can show the presense of bugs, but not their absence.
                                                   -- Edsger Dijkstra

Re: GIT 0.99.9

[Ryan Anderson]

[-- Attachment #1: Type: text/plain, Size: 241 bytes --]

Wolfgang Denk wrote:
> As a workaround I can simply unset CDPATH, and the build works  fine.
> A more robust build script woul make sure that CDPATH is not set.

Try setting CDPATH, but not exporting it in your shell startup
configuration.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 256 bytes --]

Re: GIT 0.99.9

[Junio C Hamano]

Wolfgang Denk <wd@denx.de> writes:

> I have CDPATH set in my  shell  environment,...

I understand some people like CDPATH in their interactive
shells, but I do not see a good reason to export that to random
shell scripts you run from your interactive shell session.

We already have a workaround for this exact silliness in
git-sh-setup. Probably we also need to do this to our build
procedure, I guess.  Sigh...

Re: GIT 0.99.9

[H. Peter Anvin]

Junio C Hamano wrote:
> 
> I understand some people like CDPATH in their interactive
> shells, but I do not see a good reason to export that to random
> shell scripts you run from your interactive shell session.
> 

No kidding.  Having 'cd' output stuff to stdout is asking for a million 
shell scripts to be broken.

	-hpa

Re: GIT 0.99.9

[Linus Torvalds]

Btw, 
 one thing I'd like to see (maybe it already exists and I just have 
overlooked it) is some kind of simple readme or something about the 
different ways to limit the output of the various git commands.

I've several times been surprised to see people not realize that
"git-whatchanged" takes a file list to limit the files it is interested 
in. I also suspect people don't realize that you can limit it by time and 
version and file list, all at the same time.

IOW, 

	git-whatchanged -p --pretty=short --since="2 weeks ago" v0.99.8..v0.99.9 Makefile

is a valid query: it basically asks for any change to the Makefile in 
between versions v0.99.8..v0.99.9, _and_ within the last two weeks, and 
asks to show it as a patch, with the shortened commit message.

Is it useful? The above exact line almost certainly isn't, but variations 
on the above definitely are. And I suspect a lot of people never even 
realized you could do something like that.

(The danger with date-based things is that something may be 4 months old, 
but it only got _merged_ yesterday, so it may be new to _you_. And the 
--since="2 weeks ago" will not show it, which can be surprising to people 
who expect things that are new to _them_ to be shown).

The above limiters now work with "git log" and "gitk" too (they've worked 
for a long time with "git-whatchanged", but only with the new git-rev-list 
functionality does the name-limiting work for the other commands).

It would be good to make this more well-known, because a lot of people 
probably end up using git not as developers, but just to follow what is 
going on. And then the different limiters are some of the most important 
parts (the date-one is likely the least important one, but limiting by 
version and name is _very_ important).

		Linus

Re: GIT 0.99.9

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> I've several times been surprised to see people not realize that
> "git-whatchanged" takes a file list to limit the files it is interested 
> in. I also suspect people don't realize that you can limit it by time and 
> version and file list, all at the same time.

> It would be good to make this more well-known, because a lot of people 
> probably end up using git not as developers, but just to follow what is 
> going on. And then the different limiters are some of the most important 
> parts (the date-one is likely the least important one, but limiting by 
> version and name is _very_ important).

I've somewhat updated git-rev-list documentation and tried to
categorize the options into commit selectors and presentation
modifiers.  The documentation for commands you mentioned in your
message all talk about them describing only frequently used
options, and refer the user to rev-list documentation.  I am not
sure this would be enough.

One good thing to have would be to add a section to Tutorial.
Currently we cover building a small project from scratch and
have the readers graduate when they learn basic commit swapping,
but we do not talk much about archaeology tools.

Re: GIT 0.99.9

[Linus Torvalds]

On Sun, 30 Oct 2005, Junio C Hamano wrote:
> 
> I've somewhat updated git-rev-list documentation and tried to
> categorize the options into commit selectors and presentation
> modifiers.  The documentation for commands you mentioned in your
> message all talk about them describing only frequently used
> options, and refer the user to rev-list documentation.  I am not
> sure this would be enough.

I don't think people really follow the links or think very abstractly at 
all in the first place.

So I was thinking more of some explicit examples. I actually think every 
command should have an example in the man-page, and hey, here's a patch to 
start things off.

Of course, I'm not exactly "Mr Documentation", and I don't know that this 
is the prettiest way to do this, but I checked that the resulting html and 
man-page seems at least reasonable.

And hey, if the examples look like each other, that's just because I'm 
also not "Mr Imagination".

Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---

I think most people understand a lot better from practice than from 
theory, and that an example of real usage is much more likely to make 
people udnerstand a command than just listing what it can do.

diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 13a3998..9cac088 100644
--- a/Documentation/git-log.txt
+++ b/Documentation/git-log.txt
@@ -30,6 +30,24 @@ OPTIONS
 	Show only commits between the named two commits.
 
 
+Examples
+--------
+git log --no-merges::
+
+	Show the whole commit history, but skip any merges
+
+git log v2.6.12.. include/scsi drivers/scsi::
+
+	Show all commits since version 'v2.6.12' that changed any file
+	in the include/scsi or drivers/scsi subdirectories
+
+git log --since="2 weeks ago" -- gitk::
+
+	Show the changes during the last two weeks to the file 'gitk'.
+	The "--" is necessary to avoid confusion with the *branch* named
+	'gitk'
+
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org>
diff --git a/Documentation/git-whatchanged.txt b/Documentation/git-whatchanged.txt
index e6f57d9..6c150b0 100644
--- a/Documentation/git-whatchanged.txt
+++ b/Documentation/git-whatchanged.txt
@@ -51,6 +51,20 @@ OPTIONS
 	However, it is not very useful in general, although it
 	*is* useful on a file-by-file basis.
 
+Examples
+--------
+git-whatchanged -p v2.6.12.. include/scsi drivers/scsi::
+
+	Show as patches the commits since version 'v2.6.12' that changed
+	any file in the include/scsi or drivers/scsi subdirectories
+
+git-whatchanged --since="2 weeks ago" -- gitk::
+
+	Show the changes during the last two weeks to the file 'gitk'.
+	The "--" is necessary to avoid confusion with the *branch* named
+	'gitk'
+
+
 Author
 ------
 Written by Linus Torvalds <torvalds@osdl.org> and
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index e5ef6d6..eb126d7 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -24,6 +24,19 @@ OPTIONS
 	Some argument not yet documented.
 
 
+Examples
+--------
+gitk v2.6.12.. include/scsi drivers/scsi::
+
+	Show as the changes since version 'v2.6.12' that changed any
+	file in the include/scsi or drivers/scsi subdirectories
+
+gitk --since="2 weeks ago" -- gitk::
+
+	Show the changes during the last two weeks to the file 'gitk'.
+	The "--" is necessary to avoid confusion with the *branch* named
+	'gitk'
+
 Author
 ------
 Written by Paul Mackerras <paulus@samba.org>

Archaeology [Was: Re: GIT 0.99.9]

[Horst von Brand]

Junio C Hamano <junkio@cox.net> wrote:

[...]

> One good thing to have would be to add a section to Tutorial.
> Currently we cover building a small project from scratch and
> have the readers graduate when they learn basic commit swapping,
> but we do not talk much about archaeology tools.

One of the problems with that is to have a sufficiently rich repository at
hand. People who futz around with git could be directed to get the latest
git from git for a guided tour.

Or create a script like the one in the cogito tutorial to build up someting
interesting and then direct people to look it over.
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                     Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria              +56 32 654239
Casilla 110-V, Valparaiso, Chile                Fax:  +56 32 797513

Date-based limits (Was Re: GIT 0.99.9)

[Daniel Barkalow]

On Sun, 30 Oct 2005, Linus Torvalds wrote:

> (The danger with date-based things is that something may be 4 months old, 
> but it only got _merged_ yesterday, so it may be new to _you_. And the 
> --since="2 weeks ago" will not show it, which can be surprising to people 
> who expect things that are new to _them_ to be shown).

At some point, we might want to have a series of refs tracking changes to 
the user's heads over time. Then the right set of arguments could actually 
handle "what would I have seen on Thursday, when I hadn't pulled since 
Tuesday, and upstream got some changes on Wednesday that I got on Friday, 
and it's Saturday now." (That is, Wednesday's commits hadn't hit the local 
repository yet; the commit that we got to is dated Friday for local 
purposes, and the latest as of Thursday is dated Tuesday, which is the 
last time the ref file was modified.)

And we probably don't want to fetch or clone this stuff; I doubt most 
people want to know the history from somebody else's point of view. At 
least, I can't think of a use for it that wouldn't be better served by 
asking whoever for the hash out of their history.

	-Daniel
*This .sig left intentionally blank*

Re: Date-based limits

[Junio C Hamano]

Daniel Barkalow <barkalow@iabervon.org> writes:

> At some point, we might want to have a series of refs tracking changes to 
> the user's heads over time.

Hmph.  If you really want something like that, I think you could
add a hook support for git-fetch to implement this as
automatically created lightweight tags, stashed in
$GIT_DIR/fetch-history/, deriving their names from the time of
the fetch; clone would grab everything below refs/ but this is
deliberately placed outside that hierarchy and won't get copied.
By definition, these point at commits reachable from some of
your heads (unless the remote repository maintainer is stupid
enough to rewind public trees ;-), so fsck-object would not see
them but it should not be a problem.

Re: Date-based limits

[Daniel Barkalow]

On Mon, 31 Oct 2005, Junio C Hamano wrote:

> Daniel Barkalow <barkalow@iabervon.org> writes:
> 
> > At some point, we might want to have a series of refs tracking changes to 
> > the user's heads over time.
> 
> Hmph.  If you really want something like that, I think you could
> add a hook support for git-fetch to implement this as
> automatically created lightweight tags...

Probably; I think this should also trigger on commits and such, and it 
would need a way for rev-list (or rev-parse?) to find the last one before 
a user-specified date, so that you don't have to figure out when the last 
change was that contributed to you seeing a particular tree on a given 
date.

	-Daniel
*This .sig left intentionally blank*

[PATCH] rev-list: make --max- and --min-age a bit more usable.

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> I've several times been surprised to see people not realize that
> "git-whatchanged" takes a file list to limit the files it is interested 
> in. I also suspect people don't realize that you can limit it by time and 
> version and file list, all at the same time.

The current "time based limiting" is not very user friendly, so
people not knowing the limit-by-time is not a surprise.

> 	git-whatchanged -p --pretty=short --since="2 weeks ago" v0.99.8..v0.99.9 Makefile
>
> is a valid query

Well, it is not a valid query ;-) Nobody implemented --since
yet, but you could spell it --max-age.  It would not grok "2
weeks ago" though.

With the attached patch, you could at least do:

	git log --max-age='2005-10-25' v0.99.8..v0.99.9 Makefile

There are still a couple of things that bothers me.

(1) The underlying workhorse, rev-list, takes max-age and
    min-age.  While these names are logically correct, it feels
    a bit hard and counterintuitive when deciding which one to
    use in order to ask "what are the ones that happened after
    Wednesday last week?".  The query talks about the commits
    being young, so --max-age=2005-10-26 is the right query
    (i.e. "I want to discard things that are older than that
    time"), but as soon as I type "max", my mind starts
    comparing date strings, and surely 2005-10-21 is smaller
    than 2005-10-26 and I am saying 2005-10-26 is the max, which
    confuses me to think that 2005-10-21 would be included in
    the result (it would not be -- we are talking about age, so
    2005-10-21 one is older, which means its age is greater than
    specified). It takes some mental effort to do this, at least
    for me.

    I *hate* to suggest this change at this late stage of the
    game, but maybe they should be renamed or at least acquire 
    less confusing synonyms, perhaps?

	--max-age	= --min-timestamp, --since
        --min-age	= --max-timestamp, --until

(2) If I run the above --max-age query, the last commit
    displayed is this one:

        commit f3123c4ab3d3698262e59561ac084de45b10365a
        Author: Junio C Hamano <junkio@cox.net>
        Date:   Sat Oct 22 01:28:13 2005 -0700

    This is because the age limit uses commit date (which is a
    sensible thing to do) while the display shows author date.
    To an uninitiated, this takes some explanation and
    justification (i.e. counterintuitive again).

    Incidenally, I have not found a way to prettyprint the
    commit date; --pretty=raw gives that information, but in
    really raw format.  --pretty=full does not even give any
    timestamp.

    Again I *hate* to suggest this, but maybe --pretty=full
    should show both author and commit timestamp as well, like
    this?

        commit f3123c4ab3d3698262e59561ac084de45b10365a
        Author: Junio C Hamano <junkio@cox.net>
        A-Date: Sat Oct 22 01:28:13 2005 -0700
        Commit: Junio C Hamano <junkio@cox.net>
        C-Date: Wed Oct 26 12:37:49 2005 -0700


-- >8 -- cut here -- >8 --

Earlier we just did atoi to accept these parameters, which meant
that the user needed to specify the raw UNIX time format to use
them.

This still does not make it accept '2 weeks ago', but at least
it now can take --max-age='2005-10-15', which is a start.

Signed-off-by: Junio C Hamano <junkio@cox.net>

---

 rev-list.c |   19 +++++++++++++++++--
 1 files changed, 17 insertions(+), 2 deletions(-)

applies-to: 0c9683fe37dbc43713faaa15fcce14bfe5621bba
9dc13af3f916803d270d3387032eb0e91b940417
diff --git a/rev-list.c b/rev-list.c
index 6e6ffde..7a73703 100644
--- a/rev-list.c
+++ b/rev-list.c
@@ -712,6 +712,21 @@ static void handle_all(struct commit_lis
 	global_lst = NULL;
 }
 
+static unsigned long getdate(const char *arg, const char *label)
+{
+	char text[80];
+	unsigned long date;
+
+	if (parse_date(arg, text, sizeof(text)) < 0) {
+		/* Maybe handle "4 days ago" and the like here... */
+		die("bad time specification for %s: %s", label, arg);
+	}
+	date = strtoul(text, NULL, 10);
+	if (date == ULONG_MAX)
+		die("unparsable time specification for %s: %s", label, arg);
+	return date;
+}
+
 int main(int argc, const char **argv)
 {
 	const char *prefix = setup_git_directory();
@@ -730,12 +745,12 @@ int main(int argc, const char **argv)
 			continue;
 		}
 		if (!strncmp(arg, "--max-age=", 10)) {
-			max_age = atoi(arg + 10);
+			max_age = getdate(arg + 10, "max-age");
 			limited = 1;
 			continue;
 		}
 		if (!strncmp(arg, "--min-age=", 10)) {
-			min_age = atoi(arg + 10);
+			min_age = getdate(arg + 10, "min-age");
 			limited = 1;
 			continue;
 		}
---
0.99.9.GIT

Re: [PATCH] rev-list: make --max- and --min-age a bit more usable.

[Linus Torvalds]

On Wed, 2 Nov 2005, Junio C Hamano wrote:
> 
> > 	git-whatchanged -p --pretty=short --since="2 weeks ago" v0.99.8..v0.99.9 Makefile
> >
> > is a valid query
> 
> Well, it is not a valid query ;-) Nobody implemented --since
> yet, but you could spell it --max-age.  It would not grok "2
> weeks ago" though.

Have you tried it? 

"--since" _works_.

All the magic is in "git-rev-parse". Try it.

> With the attached patch, you could at least do:
> 
> 	git log --max-age='2005-10-25' v0.99.8..v0.99.9 Makefile

No. Really. _try_ it. You can do

	git log --since="September 25"

And ItJustWorks(tm).

No patches needed. Anywhere. It's worked for quite a long time too. Since 
commit c1babb1d65e034a058c14379eabec8eb374757ca, to be exact.

    [PATCH] Teach "git-rev-parse" about date-based cut-offs

Just use it.

		Linus

Re: [PATCH] rev-list: make --max- and --min-age a bit more usable.

[Junio C Hamano]

Linus Torvalds <torvalds@osdl.org> writes:

> All the magic is in "git-rev-parse". Try it.

Ahhhh.  I missed that.  Thanks.

-- >8 -- cut here -- >8 --
Document --since and --until options to rev-parse.

The usability magic were hidden in the source code without being
documented, and even the maintainer did not know about them ;-).

Signed-off-by: Junio C Hamano <junkio@cox.net>
---

diff --git a/Documentation/git-rev-parse.txt b/Documentation/git-rev-parse.txt
index 099db29..8b8068c 100644
--- a/Documentation/git-rev-parse.txt
+++ b/Documentation/git-rev-parse.txt
@@ -72,6 +72,14 @@ OPTIONS
 	path of the current directory relative to the top-level
 	directory.
 
+--since=datestring, --after=datestring::
+	Parses the date string, and outputs corresponding
+	--max-age= parameter for git-rev-list command.
+
+--until=datestring, --before=datestring::
+	Parses the date string, and outputs corresponding
+	--min-age= parameter for git-rev-list command.
+
 <args>...::
 	Flags and parameters to be parsed.