Re: Am able to delete a file with no trace in the log

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> writes:

> What happens is that "git log" with a filename will always simplify the 
> history to the side that matches. And yes, "matching" can and does include 
> "doesn't exist in child, doesn't exist in parent"
>
> Now, I admit that in this case the matching heuristic is dubious, and 
> maybe we should consider "does not exist in result" to not match any 
> parent. We already think that "all new" is special ("REV_TREE_NEW" vs 
> "REV_TREE_DIFFERENT"), so maybe we should think that "all deleted" is also 
> special ("REV_TREE_DEL")

Sorry, but I do not quite understand this comment.  REV_TREE_NEW can be
treated differently from REV_TREE_DIFFERENT but that only happens if you
know about --remove-empty option, and no scripted (and later converted to
C) Porcelain uses that option by default.

Also, and more on the topic of simplification, if one parent matches the
child (i.e. REV_TREE_SAME), the merge history is simplified by discarding
other parents, regardless of the nature of their differences, be they
REV_TREE_NEW or REV_TREE_DIFFERENT, so in that sense we do not even
special case REV_TREE_NEW at all for the purpose of merge simplification.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]