From: Vipul Kumar <kumar@onenetbeyond.org>
To: "Ævar Arnfjörð Bjarmason" <avarab@gmail.com>
Cc: git@vger.kernel.org
Subject: Re: List all commits of a specified file in oldest to newest order
Date: Tue, 9 Nov 2021 03:35:51 +0000 [thread overview]
Message-ID: <182017f6-5dcd-70f0-e0bc-98721c433bf3@onenetbeyond.org> (raw)
In-Reply-To: <211105.86a6ijhujg.gmgdl@evledraar.gmail.com>
On 11/5/21 8:13 AM, Ævar Arnfjörð Bjarmason wrote:
>
> The key thing being the "traversal", i.e. as we walk history we'll
> encounter a tree entry where b.txt was deleted, and see that it was
> moved from a.txt.
Thanks, I didn't know "reverse" would change the traversal order. When I
looked for "--reverse" option in git-log(1), this what I found:
--reverse
Output the commits chosen to be shown (see Commit Limiting
section above) in reverse order. Cannot be combined with --walk-reflogs.
From this, I inferred that "--follow" would choose the commits and
"--reverse" reverses those commits order. Can we improve the wording
here? Especially, about "reverse" changes the traversing order.
> However, if we walk history from the beginning we have no idea of the
> relationship of a->b.txt, since we didn't encounter that commit yet,
> that's only something we see while walking the history.
Not showing commits before rename is expected, but I didn't understand
why combination "--follow" and "--reverse" option showing me only one
commit? And it always points to the rename of the file. Shouldn't it
also list other commits which changes that file? For example, just after
"rename of a.txt to b.txt", do some changes in b.txt file and then run
"git log --follow --reverse -- b.txt" command.
$ for i in {1..2}; do echo "$i" >> b.txt; git add b.txt; git commit -m
"Update$i b.txt"; done
$ git log --follow --reverse -- b.txt
commit 55e3e6857755fe815449e787a90fe82feb174817
Author: Redacted <Redacted>
Date: Fri Nov 5 06:56:58 2021 +0530
Rename a.txt to b.txt
Here I expect output to be:
$ git log --follow --reverse -- b.txt
commit 55e3e6857755fe815449e787a90fe82feb174817
Author: Reacted <Redacted>
Date: Fri Nov 5 06:56:58 2021 +0530
Rename a.txt to b.txt
commit 57aac6d1af2d869557991e714932847f37035d19
Author: Redacted <Redacted>
Date: Sun Nov 7 20:30:32 2021 +0530
Update1 b.txt
commit ea76a8e8af903dc1522626aa058b8058afbe11f4
Author: Redacted <Redacted>
Date: Sun Nov 7 20:30:32 2021 +0530
Update2 b.txt
I know, here using "--follow" along with "--reverse" doesn't make any
sense. Instead we should use "git log --reverse -- b.txt". But I'm just
curious, is this also an expected caveats of using "--follow" along with
"--reverse"?
> This caveat doesn't only apply to reverse, try to apply a move of b.txt
> on top of your history:
>
> b.txt -> c.txt
>
> And now do:
>
> git log [--follow] -- b.txt
>
> What should we output there? If we're arguing that we should first
> traverse the history to "look forward" that'll also apply to a
> non-reverse walk, since we're asking to follow b.txt.
>
> But we haven't encountered the b->c.txt relationship yet (well, we run
> into the rename commit, but once you add a c->d.txt on top...). So maybe
> instead of --buffer-then-reverse we'd need a hypothetical --two-pass,
> which would also impact options other than --reverse whose behavior
> relies on traversal order.
"--two-pass" option sounds like a good idea, but not sure how useful it
would be for others. In my case, I could read the log's command output
in bottom to top fashion, and now I also know two other approaches to
get what I wanted. And I usually don't track deleted file.
-v
next prev parent reply other threads:[~2021-11-09 3:43 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-11-05 4:10 List all commits of a specified file in oldest to newest order Vipul Kumar
2021-11-05 8:13 ` Ævar Arnfjörð Bjarmason
2021-11-09 3:35 ` Vipul Kumar [this message]
2021-11-09 9:42 ` Ævar Arnfjörð Bjarmason
2021-12-14 3:58 ` Vipul Kumar
2021-11-05 8:17 ` Jeff King
2021-11-05 18:49 ` Junio C Hamano
2021-11-05 23:26 ` Jeff King
2021-11-09 5:24 ` Vipul Kumar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=182017f6-5dcd-70f0-e0bc-98721c433bf3@onenetbeyond.org \
--to=kumar@onenetbeyond.org \
--cc=avarab@gmail.com \
--cc=git@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).