From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:17
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
* lt/follow (Tue Jun 19 14:22:46 2007 -0700) 1 commit
+ Finally implement "git log --follow"
Has leaks, and it won't graduate to 'master' without
documentation.
Also I am not convinced its handling of merges is sane. If you
have an ancestry graph like this, and the commit A renames the
followed path, it would show the file _before_ rename, which is
very good.
o-------B---A---o----o
/
o----C------'
But the code changes pathspec globally, so when we are looking
at C, it may or may not have that (before-renamed) path there.
At least, the patch is small and would not affect codepath that
does not use this option, so in that sense it is relatively safe
change, though.
* jc/oneline (Fri Jun 15 13:19:07 2007 +0100) 4 commits
+ pp_header(): work around possible memory corruption
+ Fix ALLOC_GROW off-by-one
+ Extend --pretty=oneline to cover the first paragraph,
+ Lift 16kB limit of log message output
* jk/add-empty (Tue Jun 12 23:42:14 2007 +0200) 2 commits
+ builtin-add: simplify (and increase accuracy of) exclude handling
+ dir_struct: add collect_ignored option
Will merge this weekend.
* ns/clone (Sat Jun 16 15:26:08 2007 -0700) 1 commit
+ Cloning from a repo without "current branch"
Will merge this weekend.
* js/filter (Fri Jun 8 23:28:50 2007 +0200) 11 commits
+ filter-branch: subdirectory filter needs --full-history
+ filter-branch: Simplify parent computation.
+ Teach filter-branch about subdirectory filtering
+ filter-branch: also don't fail in map() if a commit cannot be
mapped
+ filter-branch: Use rev-list arguments to specify revision ranges.
+ filter-branch: fix behaviour of '-k'
+ filter-branch: use $(($i+1)) instead of $((i+1))
+ chmod +x git-filter-branch.sh
+ filter-branch: prevent filters from reading from stdin
+ t7003: make test repeatable
+ Add git-filter-branch
Will merge this weekend.
* ew/svn (Wed Jun 13 02:23:28 2007 -0700) 1 commit
+ git-svn: allow dcommit to retain local merge information
Haven't heard major breakage report, so hopefully can merge by
the end of the month.
* ml/worktree (Fri Jun 8 22:57:55 2007 +0200) 9 commits
+ make git barf when an alias changes environment variables
+ setup_git_directory: fix segfault if repository is found in cwd
+ test GIT_WORK_TREE
+ extend rev-parse test for --is-inside-work-tree
+ Use new semantics of is_bare/inside_git_dir/inside_work_tree
+ introduce GIT_WORK_TREE to specify the work tree
+ test git rev-parse
+ rev-parse: introduce --is-bare-repository
+ rev-parse: document --is-inside-git-dir
I've been resisting this but I think its definition of is-bare
is a bit saner than what we have in 'master', and I think it is
the right direction in the longer term. HOWEVER, I am not sure
about the implementation and corner cases, e.g. what should it
do in receive-pack? You cannot rely on user setting GIT_WORK_TREE
environment -- rather, receive-pack is responsible for setting
up a sane environment for other commands to work in.
* jo/init (Thu Jun 7 07:50:30 2007 -0500) 2 commits
- Quiet the output from git-init when cloning, if requested.
- Add an option to quiet git-init.
Also I am not convinced its handling of merges is sane. If you
have an ancestry graph like this, and the commit A renames the
followed path, it would show the file _before_ rename, which is
very good.
o-------B---A---o----o
/
o----C------'
I agree. That's even what I tried to explain (but your graph is better) in
my commit message, when I was talking about how it linearizes the history
in "git log" order, and decides that renames happen "within that
linearized" world.
You can actually see an *example* of this by doing
git log --stat --follow arch/i386/pci/common.c
on the old historical Linux archive (the BK import one, not the bkcvs
import - the latter has been linearized by bkcvs so won't show concurrent
development anyway).
What you get is:
[ ... ]
commit f9001d4262148fbfb7ecdcb88c73d9791c1ac0ad
Author: Greg Kroah-Hartman [off-list ref]
Date: Mon May 6 20:18:16 2002 -0700
Move arch/i386/kernel/pci/ to arch/i386/pci/
arch/i386/{kernel => }/pci/common.c | 0
1 files changed, 0 insertions(+), 0 deletions(-)
commit bbb283cca10b2d2c935ae35327620ebae07f7d80
Author: Patrick Mochel [off-list ref]
Date: Mon May 6 20:09:44 2002 -0700
Move arch/i386/kernel/pci/ to arch/i386/pci/
arch/i386/kernel/pci/common.c | 206 -----------------------------------------
1 files changed, 0 insertions(+), 206 deletions(-)
[ ... ]
and this is an artifact of two _concurrent_ directory moves, and look at
what "git log --follow" did: it actually found the rename (we looked at
Greg's version first), but then *because* it found the rename, it is now
starting to look at the *previous* name, which was
arch/i386/kernel/pci/common.c
and when it then sees the rename in Pat's commit, it's no longer finding
that previous entry as a "new file that got created" (which triggers the
rename logic), but now it finds that filename has being *removed* (because
the _old_ filename really did go away - it got renamed!)
This is 100% logical within that linearized history, but it's a bit
surprising. But it's how "git log --follow" just works.
If you want to see the real history, you need to do it with "git blame",
which actually understands about merges, or with some graphical viewer
that would be extended to follow renames when it notices that a filename
goes away.
But "git log" itself really fundamentally has no clue, and you really
should see "git log" as a *linearization* thing. It linearizes the history
by creating a one-dimensional streaming log. And within that linearized
history, there can not be anything like "concurrent renames".
Linus
But "git log" itself really fundamentally has no clue, and you really
should see "git log" as a *linearization* thing. It linearizes the history
by creating a one-dimensional streaming log. And within that linearized
history, there can not be anything like "concurrent renames".
Btw, just to clarify:
This is absolutely not somethign unique to "--follow" and rename
detection!
when you do a simple "git log -p", you will very commonly see the issue of
the same patch being applied twice, and if you think of the linearized
"git log" output is somehow "the Truth" with a capital "T", then you'd
obviously believe that the thing shows up twice in the end result.
It doesn't even have to be the same patch: you can have a patch that shows
up in one branch, and that *never* makes it into the end result, even
though the other branch didn't "undo" it. A merge may have chosen just the
one side (not necessarily due to "-s ours" or anythign like that: a merge
conflict may have been resoled that way).
So the individual logs of changes are not "meaningful" in that sense. Not
with --follow, and not without. They are a locally linearized version of
history, and as such you cannot put the world together just based on them.
You need to have the bigger picture to get the end result.
Does that mean that linearization is meaningless? No, obviously not. Does
it mean that you *can* get confused by it? Yes, absolutely. Does rename
detection add new _ways_ of getting confused? Oh, YES! The example from
the kernel is a great one.
I still think "git log --follow" is actually a really good thing. People
will find places like this where they are confused, and maybe we'll have
to teach them about the effects of linearizing their history, but
especially if you come from the CVS/SVN world, your history has _always_
been linear, so git will always get that case right.
And once you get used to merges, you'll start understanding why git does
what git does more, and then the "git log --follow" behaviour will still
perhaps not be what you might always want at any particular point in time,
but it's something you can understand and deal with.
And it's still hugely preferable to "file identities", which have their
own (and much more fundamental) problems over merges.
Linus