# wor...@alum.mit.edu / 2014-09-29 11:45:00 -0400:
> > From: Roman Neuhauser <neuhau...@sigpipe.cz>
> > i'm writing an alternative to git-requet-pull. its output includes
> > a log of the commit range, eg:
> > 1/3 76a23b86 043603cc README fancier
> > 162441d0 README
> > 2/3 87990615 ab984c9b ignore vim swapfiles
> > 32682119 .gitignore
> > 3/3 2c842d2d 2ab371a4 README is now README.txt
> > each commit is represented by a line giving its position in the range,
> > the treeid, the commitid and the subject line, followed by a series of
> > lines identifying affected files, each line with the objectid and path.
> > i'm gathering the data with `git-rev-list --objects`, but it doesn't
> > mention objects that were moved (git mv) in a given commit; this is
> > visible in the last (3/3) commit in the example above: that commit was
> > just `git mv README README.txt`.
> > i want the output to identify moves and copies. what are my options?
> > am i missing an option in git-rev-list(1)? should i use a different
> > piece of plumbing?
> The fundamental problem is that Git's data structures don't list moves
> and copies. For that matter, they don't list adds and deletes,
> either. As stored, each commit just tells the contents of the
> directory tree. What you appear to want is something that compares
> one or more commits and tells what the differences between them are.
yup, i'd like a plumbing equivalent of `git log --raw ...`. AFAICT
the closest to that is git-diff-tree, except that implies N invocations
instead of one, a sad loss of efficiency i'd love to avoid.
> OTOH, is that what you *really* want? You say that you're "writing an
> alternative to git-request-pull". What is the definition of this
> output? What purposes do you expect the output to be put to?
> For instance, when you're pulling commit 3/3 from the remote, you
> don't *need* to download the blob that is the current contents of
> README.txt (and the former contents of README) because you already
> have it in your repository. So "git-rev-list --objects" doesn't list
this is for human consumption in an email-based code review process.
think git-request-pull for the overall picture plus git-format-patch
for individual commits. from the readme:
Pull requests are often sent repeatedly: Alice clones Bob's
repository, commits some changes and sends him a pull request.
Bob reviews the proposed changes and requests a few modifications.
Alice tweaks her branch as requested and sends another pull request.
Bob is a busy person and wants a very quick overview of the
differences between the old and new pull request. Alice would do well
to tell Bob which parts of the patch series changed in the second
You received this message because you are subscribed to the Google Groups "Git
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email
For more options, visit https://groups.google.com/d/optout.