[MERGE] Fix #175520 by implementing a --deep option for log

[John Arbash Meinel]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Vincent Ladeuil wrote:
>>>>>> "Ian" == Ian Clatworthy <ian.clatworthy at internode.on.net> writes:
> 
>     Ian> Vincent Ladeuil wrote:
>     >>>>>>> "Ian" == Ian Clatworthy <ian.clatworthy at internode.on.net> writes:
> 
>     >> So, in that patch, can we agree on handling only two cases as
>     >> done here ?:
>     >> - file -> file id against the working tree by default
>     >> - file -> any file id if --old is used
>     >> 
>     >> Otherwise we need yet another mean to access even older file ids.
> 
>     Ian> I can agree to that. Part of my point though was that
>     Ian> your patch isn't finding old file-ids and using them:
>     Ian> it's matching on names (which is great) but then doesn't
>     Ian> use the file-ids found.
> 
>     Ian> Practically, it probably doesn't matter in 99% of cases
>     Ian> *but* bzr is unique partly because we (claim to) handle
>     Ian> renames correctly, so that implies we ought to use the
>     Ian> file-id once we know it IMO.
> 
> File ids used in the working tree can be found via dirstate. No
> longer used file ids have to be searched in the
> inventories. Since we have to search all inventories, there is no
> place to reuse the file id once it's discovered.

Except you might want to consider the case:

bzr init
bzr add A # file_id1
bzr commit -m "added A"
bzr add B # file_id2
bzr commit -m "added B"

bzr mv B C
bzr mv A B
bzr commit -m "rename B=>C, A=>B"

bzr commit -m "modified B"
bzr commit -m "modified C"

At this point, if you do "bzr log B --XXX" what happens. There are a few
options:

a) You see "added A", "rename B=>C, A=>B", "modified B".

   This is the current behavior of "bzr log B". It looks in the current
   WT to find what is at "B" (currently file_id1) and then gives *that*
   files log.

b) You see "added A", "added B", "rename B=>C, A=>B", "modified B".

   This would be the case if you start with the current working tree,
   and found "B", and then as you go back in history, you see that there
   was a different file that was named B in the past, and then included
   tracking its history.

c) You see all commits.

   This would be the case if you first iterated through all inventories
   and found any file named "B" and grabbed its file-id. You then grab
   the per-file graphs of all of those file ids, and display the union.

d) You see "modified B", "rename B=>C, A=>B" and "added B".

   This is the case if you don't follow renames at all. And just show
   the logs of whenever something was called B. This (I believe) is the
   default behavior of 'git' when you give it a path to log, though I
   think there are some flags to have it track history.


In my opinion, (c) is better than (b). If you are going to include
everything that has been called "B" then you should display the *new*
changes, and not just the old ones.

It gets even a bit uglier if "B" was a directory with children. As
suddenly you start going backwards, and then you find a directory and
need to include all of the children of that directory. Because at that
point you then need to move back and forth in time looking for anything
that was a child of any of the directories that you are now tracking.

As such, (d) is dramatically easier to implement, and the user can be
responsible for then asking for the log of the file_id2 if they see the
rename and want to see more information. They also can ask for the log
of "C" since they can see that it was also the file "B" at some point in
the past.


IMO, (c) is the "most correct" answer, but also the hardest to
implement, and the slowest at runtime, because you have to do a lot of
"back-and-forth" to handle all the edge cases. If you only handled
file-ids and not children of directories, then it could be handled in
2-passes, but I think you end up with an extra pass-per-new-directory if
we want to include the logs of all children underneath a directory.


I would think that for many people (d) is the "good enough" answer. You
will be able to see when a file is renamed into or out of a directory,
and you can make a separate request if you want more information about
that file.


John
=:->

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAklk+2QACgkQJdeBCYSNAAPLAgCgx6oTOfMThIx6mUHNPMy4nzf8
hRQAoLktYb9glk4ClRdt4OBBjdLfA5b2
=dXdx
-----END PGP SIGNATURE-----