finding deleted file names

finding deleted file names

[Geoff Russell]

git diff --diff-filter=D --name-only HEAD@{'7 days ago'}

finds files deleted during the last 7 days, but if my repository is
only 6 days old I get a
fatal error.

fatal: bad object HEAD@{7 days ago}

Is there something that says "since repository creation", ie., go back as far
as possible, but no further? Is there a symbolic name for the initial commit?

Cheers,
Geoff Russell

Re: finding deleted file names

[Mikael Magnusson]

2008/7/3 Geoff Russell <geoffrey.russell@gmail.com>:
> git diff --diff-filter=D --name-only HEAD@{'7 days ago'}
>
> finds files deleted during the last 7 days, but if my repository is
> only 6 days old I get a
> fatal error.
>
> fatal: bad object HEAD@{7 days ago}
>
> Is there something that says "since repository creation", ie., go back as far
> as possible, but no further? Is there a symbolic name for the initial commit?

There's no symbolic name for it, since there might not be only one initial
commit. git.git for example has at least three root commits. You will
probably get what you want with $(git rev-list HEAD|tail -1). If your
history is very large, $(git rev-list --reverse HEAD|head -1) is slightly
faster, but usually not enough to offset typing --reverse :).

-- 
Mikael Magnusson

Re: finding deleted file names

[Geoff Russell]

On Thu, Jul 3, 2008 at 10:42 AM, Mikael Magnusson <mikachu@gmail.com> wrote:
> 2008/7/3 Geoff Russell <geoffrey.russell@gmail.com>:
>> git diff --diff-filter=D --name-only HEAD@{'7 days ago'}
>>
>> finds files deleted during the last 7 days, but if my repository is
>> only 6 days old I get a
>> fatal error.
>>
>> fatal: bad object HEAD@{7 days ago}
>>
>> Is there something that says "since repository creation", ie., go back as far
>> as possible, but no further? Is there a symbolic name for the initial commit?
>
> There's no symbolic name for it, since there might not be only one initial
> commit. git.git for example has at least three root commits. You will
> probably get what you want with $(git rev-list HEAD|tail -1). If your
> history is very large, $(git rev-list --reverse HEAD|head -1) is slightly
> faster, but usually not enough to offset typing --reverse :).

Thanks for this, but I'm a little confused.

If I do a "git init", there must be a first commit after this? Isn't
this the first commit, how
can there be more than one first commit?

Cheers,
Geoff

>
> --
> Mikael Magnusson
>



-- 
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069

Re: finding deleted file names

[Mikael Magnusson]

2008/7/3 Geoff Russell <geoffrey.russell@gmail.com>:
> On Thu, Jul 3, 2008 at 10:42 AM, Mikael Magnusson <mikachu@gmail.com> wrote:
>> 2008/7/3 Geoff Russell <geoffrey.russell@gmail.com>:
>>> git diff --diff-filter=D --name-only HEAD@{'7 days ago'}
>>>
>>> finds files deleted during the last 7 days, but if my repository is
>>> only 6 days old I get a
>>> fatal error.
>>>
>>> fatal: bad object HEAD@{7 days ago}
>>>
>>> Is there something that says "since repository creation", ie., go back as far
>>> as possible, but no further? Is there a symbolic name for the initial commit?
>>
>> There's no symbolic name for it, since there might not be only one initial
>> commit. git.git for example has at least three root commits. You will
>> probably get what you want with $(git rev-list HEAD|tail -1). If your
>> history is very large, $(git rev-list --reverse HEAD|head -1) is slightly
>> faster, but usually not enough to offset typing --reverse :).
>
> Thanks for this, but I'm a little confused.
>
> If I do a "git init", there must be a first commit after this? Isn't
> this the first commit, how
> can there be more than one first commit?

In git.git, the gitk subdirectory has a separate root because it was merged
with the subtree merge strategy, so if you go down the second parent of that
merge commit, you'll end up not at the start of the git history. You can
see this if you just fetch any other repo into your current one and merge it.
Just add everything with conflict markers in if it conflicts and commit,
then look at gitk :). (and obviously then revert the merge or whatever).

Btw, after you git init, there are 0 commits, the first commit is created
when you run git commit the first time.

-- 
Mikael Magnusson

Re: finding deleted file names

[Jeff King]

On Thu, Jul 03, 2008 at 12:15:37PM +0930, Geoff Russell wrote:

> >> Is there something that says "since repository creation", ie., go back as far
> >> as possible, but no further? Is there a symbolic name for the initial commit?
> >
> > There's no symbolic name for it, since there might not be only one initial
> > commit. git.git for example has at least three root commits. You will
> > probably get what you want with $(git rev-list HEAD|tail -1). If your
> > history is very large, $(git rev-list --reverse HEAD|head -1) is slightly
> > faster, but usually not enough to offset typing --reverse :).
> 
> Thanks for this, but I'm a little confused.
> 
> If I do a "git init", there must be a first commit after this? Isn't
> this the first commit, how
> can there be more than one first commit?

The confusing part is that you two are talking about two slightly
different things. If you define "initial commit" as "the commit which
has no parents" then there can be many (you get a new one anytime you
merge in a project with unrelated history).

However, what Geoff originally mentioned was HEAD{'7 days ago'}, which
actually looks in the reflog. So if you define "initial commit" as "the
first commit value that this ref ever had" then there is only one
(though of course, your reflog will eventually expire, so it won't be
"the oldest value this ref ever had" but rather "the oldest one the
reflog ever remembers it having").

-Peff

Re: finding deleted file names

[Geoff Russell]

On 7/3/08, Jeff King <peff@peff.net> wrote:
> On Thu, Jul 03, 2008 at 12:15:37PM +0930, Geoff Russell wrote:
>
>  > >> Is there something that says "since repository creation", ie., go back as far
>  > >> as possible, but no further? Is there a symbolic name for the initial commit?
>  > >
>  > > There's no symbolic name for it, since there might not be only one initial
>  > > commit. git.git for example has at least three root commits. You will
>  > > probably get what you want with $(git rev-list HEAD|tail -1). If your
>  > > history is very large, $(git rev-list --reverse HEAD|head -1) is slightly
>  > > faster, but usually not enough to offset typing --reverse :).
>  >
>  > Thanks for this, but I'm a little confused.
>  >
>  > If I do a "git init", there must be a first commit after this? Isn't
>  > this the first commit, how
>  > can there be more than one first commit?
>
>
> The confusing part is that you two are talking about two slightly
>  different things. If you define "initial commit" as "the commit which
>  has no parents" then there can be many (you get a new one anytime you
>  merge in a project with unrelated history).
>
>  However, what Geoff originally mentioned was HEAD{'7 days ago'}, which
>  actually looks in the reflog. So if you define "initial commit" as "the
>  first commit value that this ref ever had" then there is only one
>  (though of course, your reflog will eventually expire, so it won't be
>  "the oldest value this ref ever had" but rather "the oldest one the
>  reflog ever remembers it having").

You guys are (quite properly) worried about all the edge cases and I
have probably
confused things by using the reflog when they may be a better way of
doing things.

Perhaps if I describe the problem, there may be a better solution than using the
reflog.  I've made a bunch of changes to a repository, a few weeks
later I figure I've
deleted a file I need but am not really sure of its name. So I want to list the
files that I've deleted during the past few weeks. So the aim is to
find the files that
aren't in the current working directory but that are in some commit done since
day X.

Cheers,
Geoff


>
>  -Peff
>


-- 
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069

Re: finding deleted file names

[Junio C Hamano]

"Geoff Russell" <geoffrey.russell@gmail.com> writes:

> ... I've made a bunch of changes to a repository, a few weeks later I
> figure I've deleted a file I need but am not really sure of its name. So
> I want to list the files that I've deleted during the past few weeks.

$ git log --pretty=oneline --diff-filter=D --name-only -M --since=90.days

Re: finding deleted file names

[Geoff Russell]

On 7/4/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Geoff Russell" <geoffrey.russell@gmail.com> writes:
>
>  > ... I've made a bunch of changes to a repository, a few weeks later I
>
> > figure I've deleted a file I need but am not really sure of its name. So
>  > I want to list the files that I've deleted during the past few weeks.
>
>
> $ git log --pretty=oneline --diff-filter=D --name-only -M --since=90.days

This is good, but on my version 1.5.5.1, is giving the commit-ids +
comments as well
as the names.

e.g.,
      58d331dc02da635a60be5911dd98510f350718ad deleted:    999
modified:     frepas.tex
      LEAFLETS/999
      1b7e44fb572297bd5a6f240864dcec292fa158b0 after caption added
      LEAFLETS/xxx.tex

Cheers,
Geoff



>
>


-- 
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069

Re: finding deleted file names

[Junio C Hamano]

"Geoff Russell" <geoffrey.russell@gmail.com> writes:

> On 7/4/08, Junio C Hamano <gitster@pobox.com> wrote:
>> "Geoff Russell" <geoffrey.russell@gmail.com> writes:
>>
>>  > ... I've made a bunch of changes to a repository, a few weeks later I
>>
>> > figure I've deleted a file I need but am not really sure of its name. So
>>  > I want to list the files that I've deleted during the past few weeks.
>>
>>
>> $ git log --pretty=oneline --diff-filter=D --name-only -M --since=90.days
>
> This is good, but on my version 1.5.5.1, is giving the commit-ids +
> comments as well
> as the names.

Oh, I very much intended to give them, as --since=90.days is very broad
that you would want to know which exact commit to learn when the found
change was made anyway.

Re: finding deleted file names

[Geoff Russell]

On Sun, Jul 6, 2008 at 2:47 PM, Junio C Hamano <gitster@pobox.com> wrote:
> "Geoff Russell" <geoffrey.russell@gmail.com> writes:
>
>> On 7/4/08, Junio C Hamano <gitster@pobox.com> wrote:
>>> "Geoff Russell" <geoffrey.russell@gmail.com> writes:
>>>
>>>  > ... I've made a bunch of changes to a repository, a few weeks later I
>>>
>>> > figure I've deleted a file I need but am not really sure of its name. So
>>>  > I want to list the files that I've deleted during the past few weeks.
>>>
>>>
>>> $ git log --pretty=oneline --diff-filter=D --name-only -M --since=90.days
>>
>> This is good, but on my version 1.5.5.1, is giving the commit-ids +
>> comments as well
>> as the names.
>
> Oh, I very much intended to give them, as --since=90.days is very broad
> that you would want to know which exact commit to learn when the found
> change was made anyway.
>

That's fine, the --name-only confused me, but I understand what is
happening now.

Geoff.


-- 
6 Fifth Ave,
St Morris, S.A. 5068
Australia
Ph: 041 8805 184 / 08 8332 5069

Re: finding deleted file names

[Jakub Narebski]

"Geoff Russell" <geoffrey.russell@gmail.com> writes:

> git diff --diff-filter=D --name-only HEAD@{'7 days ago'}

What did you want to find here?

> finds files deleted during the last 7 days, but if my repository is
> only 6 days old I get a fatal error.
> 
> fatal: bad object HEAD@{7 days ago}

First, which version of git do you use? Because with git version 1.5.6.1
I get:

  1000:[master!git]$ git diff --diff-filter=D --name-only HEAD@{'10 years ago'}
  warning: Log for 'HEAD' only goes back to Fri, 4 Apr 2008 15:28:53 +0200.
  Documentation/core-tutorial.txt
  [...]

Second, [<ref>]@{<date>} refers to _local_ history of where _branch tip_
pointed in your repository, and is purely local information retrieved from
reflogs (which gets pruned / expired).  To refer to (find) commits by
commit creation date, use --since=<date>/--after=<date> or --until=<date>/
/--before=<date>.  There was even lately added information to git
documentation about difference bwetween [<ref>]@{<date>} and --before=<date>
and when to use one or the other.

> Is there something that says "since repository creation", ie., go back as far
> as possible, but no further? Is there a symbolic name for the initial commit?

Because git allows joining two repositories into one (either union of
their top directories, or one put into subdirectory in other using so
called 'subtree' merge strategy) there can be more than one "root"
(parentless) commit.  In git repository there are 7 root commits, not
counting "disjoint" branches like 'html', 'man' and 'todo' which share
no history and doesn't join with mainline history.

They are: git-p4 (Perforce importer), git-gui, gitweb, gitk, git mail
tools, git,... and something strange (4e00220243).

 $ git rev-list --parents --branches --not html man todo | grep -v -e ' '

-- 
Jakub Narebski
Poland
ShadeHawk on #git

Re: finding deleted file names

[Jeff King]

On Thu, Jul 03, 2008 at 09:31:55AM +0930, Geoff Russell wrote:

> git diff --diff-filter=D --name-only HEAD@{'7 days ago'}
> 
> finds files deleted during the last 7 days, but if my repository is
> only 6 days old I get a
> fatal error.
> 
> fatal: bad object HEAD@{7 days ago}

This should issue a warning, but use the oldest reflog entry. However,
there is a slight problem with that. See below for details.

Shawn, does this seem sane to you?

-- >8 --
avoid null SHA1 in oldest reflog

When the user specifies a ref by a reflog entry older than
one we have (e.g., "HEAD@{20 years ago"}), we issue a
warning and give them the "from" value of the oldest reflog
entry. That is, we say "we don't know what happened before
this entry, but before this we know we had some particular
SHA1".

However, the oldest reflog entry is often a creation event
such as clone or branch creation. In this case, the entry
claims that the ref went from "00000..." (the null sha1) to
the new value, and the reflog lookup returns the null sha1.

While this is technically correct (the entry tells us that
the ref didn't exist at the specified time) it is not
terribly useful to the end user. What they probably want
instead is "the oldest useful sha1 that this ref ever had".
This patch changes the behavior such that if the oldest
reflog entry would return the null sha1, it instead returns
the first actual value the ref ever had.

We never discovered this problem in the test scripts because
we created "fake" reflogs that had only a specified segment
of history. This patch updates the tests with a creation
event at the beginning of history.

Signed-off-by: Jeff King <peff@peff.net>
---
 refs.c                |    4 ++++
 t/t1400-update-ref.sh |    9 ++++++++-
 2 files changed, 12 insertions(+), 1 deletions(-)

diff --git a/refs.c b/refs.c
index 9e8e858..6c6e9e5 100644
--- a/refs.c
+++ b/refs.c
@@ -1412,6 +1412,10 @@ int read_ref_at(const char *ref, unsigned long at_time, int cnt, unsigned char *
 	tz = strtoul(tz_c, NULL, 10);
 	if (get_sha1_hex(logdata, sha1))
 		die("Log %s is corrupt.", logfile);
+	if (is_null_sha1(sha1)) {
+		if (get_sha1_hex(logdata + 41, sha1))
+			die("Log %s is corrupt.", logfile);
+	}
 	if (msg)
 		*msg = ref_msg(logdata, logend);
 	munmap(log_mapped, mapsz);
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index f387d46..ca99d37 100755
--- a/t/t1400-update-ref.sh
+++ b/t/t1400-update-ref.sh
@@ -155,7 +155,8 @@ rm -f .git/$m .git/logs/$m expect
 
 git update-ref $m $D
 cat >.git/logs/$m <<EOF
-$C $A $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150320 -0500
+0000000000000000000000000000000000000000 $C $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150320 -0500
+$C $A $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150350 -0500
 $A $B $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150380 -0500
 $F $Z $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150680 -0500
 $Z $E $GIT_COMMITTER_NAME <$GIT_COMMITTER_EMAIL> 1117150980 -0500
@@ -186,6 +187,12 @@ test_expect_success \
 	'Query "master@{May 26 2005 23:32:00}" (exactly history start)' \
 	'rm -f o e
 	 git rev-parse --verify "master@{May 26 2005 23:32:00}" >o 2>e &&
+	 test '"$C"' = $(cat o) &&
+	 test "" = "$(cat e)"'
+test_expect_success \
+	'Query "master@{May 26 2005 23:32:30}" (first non-creation change)' \
+	'rm -f o e
+	 git rev-parse --verify "master@{May 26 2005 23:32:30}" >o 2>e &&
 	 test '"$A"' = $(cat o) &&
 	 test "" = "$(cat e)"'
 test_expect_success \
-- 
1.5.6.1.282.g8aee2.dirty

Re: finding deleted file names

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> On Thu, Jul 03, 2008 at 09:31:55AM +0930, Geoff Russell wrote:
>
>> git diff --diff-filter=D --name-only HEAD@{'7 days ago'}
>> 
>> finds files deleted during the last 7 days, but if my repository is
>> only 6 days old I get a
>> fatal error.
>> 
>> fatal: bad object HEAD@{7 days ago}
>
> This should issue a warning, but use the oldest reflog entry. However,
> there is a slight problem with that. See below for details.

I think your patch is a sane thing to do.

Once reflog entries begin expiring, we won't have the null_sha1 on the
previous side of them, and after that we will keep returning the
oldest-known one, so nobody should be expecting to find out when a ref was
first created in this repository by checking with what timestamp that
syntax breaks in the existing interface.

Sorry for not being Shawn ;-)

Re: finding deleted file names

[Jeff King]

On Thu, Jul 03, 2008 at 12:41:43PM -0700, Junio C Hamano wrote:

> Once reflog entries begin expiring, we won't have the null_sha1 on the
> previous side of them, and after that we will keep returning the
> oldest-known one, so nobody should be expecting to find out when a ref was
> first created in this repository by checking with what timestamp that
> syntax breaks in the existing interface.

Right, that was my thought: though perhaps not technically as precise,
it is much more DWIM.

My other concern, which I failed to voice in the original mail was:
should we do this magic for other reflog entries besides the first one?
It is possible to end up with a null sha1 in any other entry? Branch
creation shouldn't do it, because we will have deleted any previous
reflog when killing off the branch before, so we always end up putting
in the "oldest" reflog entry. Cloning shouldn't do it for obvious
reasons.

> Sorry for not being Shawn ;-)

Heh.

-Peff

Re: finding deleted file names

[Shawn O. Pearce]

Jeff King <peff@peff.net> wrote:
> On Thu, Jul 03, 2008 at 09:31:55AM +0930, Geoff Russell wrote:
> 
> > git diff --diff-filter=D --name-only HEAD@{'7 days ago'}
> > 
> > finds files deleted during the last 7 days, but if my repository is
> > only 6 days old I get a
> > fatal error.
> > 
> > fatal: bad object HEAD@{7 days ago}
> 
> This should issue a warning, but use the oldest reflog entry. However,
> there is a slight problem with that. See below for details.
> 
> Shawn, does this seem sane to you?

Yea, this is the only reasonable thing to do here.  Ack.

-- 
Shawn.

Re: finding deleted file names

[Johannes Schindelin]

Hi,

On Thu, 3 Jul 2008, Geoff Russell wrote:

> git diff --diff-filter=D --name-only HEAD@{'7 days ago'}
> 
> finds files deleted during the last 7 days, but if my repository is
> only 6 days old I get a
> fatal error.
> 
> fatal: bad object HEAD@{7 days ago}

Sorry, but you haven't grasped the concept of reflogs.  The "@{...}" is 
purely for the _local_ state.

So clearly, if you did not have the repo 7 days ago, "HEAD@{7.days.ago}" 
does not exist.

In a distributed SCM, asking about a branch's state "7 days ago" is 
ill-defined at best.

Hth,
Dscho