git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [BUG] git-log: tracking deleted file in a repository with multiple "initial commit" histories

From
Brian Norris <computersforpeace@gmail.com>
Date
Feb 18, 2016, 22:27 UTC
Message-ID
<20160218222713.GA50021@google.com>
In-Reply-To
<20160216222942.GA9014@sigill.intra.peff.net>
On Tue, Feb 16, 2016 at 05:29:42PM -0500, Jeff King wrote:
Show 14 quoted lines
> On Tue, Feb 16, 2016 at 01:24:29PM -0800, Brian Norris wrote:
> 
> > On Tue, Feb 16, 2016 at 03:45:57PM -0500, Jeff King wrote:
> > > See the section on History Simplification in git-log. But basically,
> > > when you specify a pathspec, git does not traverse side branches that
> > > had no effect on the given pathspec.
> > 
> > Thanks for the pointer. Is this done primarily for performance reasons,
> > or for UI simplicity (e.g., to avoid some kinds of double-counting)?
> > Seems like it generates unintuitive behaviors, but if it's helping block
> > other unintuitive behaviors, then maybe it can't be resolved easily.
> 
> Both, I think. Try looking at "--full-history" and you will see that it
> has a lot of cruft that is probably not that interesting. But

I wasn't seeing the "cruft" at first, but now I see. It appears, BTW, that 'git log --full-history -- <path>' gives vastly different commits than 'git log --full-history --graph -- <path>'. (The latter has a lot more "cruft" about unrelated merges.) That seems like a weird inconsistency...

> simplifying further (e.g., with "--simplify-merges") doesn't tell much
> of the whole story (or maybe it does; we do see the final deletion
> there, which is the end state).

git log --full-history --simplify-merges -- init/iptables.conf and git log --full-history --simplify-merges --graph --oneline -- init/iptables.conf

give good results for me, showing every commit that actually modifies the file, AFAICT.

Show 5 quoted lines
> > FWIW, I quite often use git-log to look at the history of a deleted
> > file. Seems like a pretty big hole if the default behavior is going to
> > prune away the entire history of the file.
> 
> It doesn't normally.
That doesn't really change my statement.
> What happened is that you had two parallel
> histories, and the final state of the file could be explained by
> following the simpler of the two histories (the one where it never
> existed in the first place).

I (sort of) understand what happened. But I disagree that it's a good default. It's obviously not what the user is asking for.

Show 9 quoted lines
> > > If you want to see the full history, you can with "--full-history"
> > > (there are some other simplification possibilities, but I don't think
> > > any of them are interesting for your particular case).
> > 
> > --full-history gives me what I want (I'll admit, I didn't read through
> > all the other "History Simplification" documentation). Can I make this
> > the default somehow?
> 
> No, but you can make an alias that includes it.
Sure.
Thanks for the help!
Brian
Previous: Jeff King
Message 5 of 5 in “[BUG] git-log: tracking deleted file in a repository with multiple "initial commit" histories”
  1. Brian NorrisFeb 16, 2016
  2. Jeff KingFeb 16, 2016
  3. Brian NorrisFeb 16, 2016
  4. Jeff KingFeb 16, 2016
  5. Brian NorrisFeb 18, 2016

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.