On Monday, January 23, 2017 at 11:05:28 AM UTC-8, Michael Gersten wrote:
>
>
> On 2017-01-23, at 2:38 AM, Konstantin Khomoutov <
> flat...@users.sourceforge.net <javascript:>> wrote:
> > ...
> >
> > In particular, refer to:
> >
> > * the `git log` manual for the description of the
> > "-Sstring" command-line option (the mode it enables is called
> > "pickaxe"; see also "--pickaxe-regex" and "--pickage-all" modifiers to
> > it, and the "-G" command-line option);
> > * to the `git rev-list` manual for the "--branches" option;
> > * and the gitrevisions manual for the ^commit notation.
>
> ... and, to something called "gitdiffcore" ... gee, this is exactly where
> those "smart tools" that Linux was talking about are found.
>
> So this is the first I've heard of "diffcore". I'm not even using
> "diff-tree", "diff-index", or "diff-files" -- but I'm sure that everything
> else uses them.
>
> ===
>
> Now, in reading all this, I'm realizing I have a fundamental
> misunderstanding of git.
>
> To me, the commits reachable from a given commit are those that come after
> it. The future from the commit.
> To git, it's the exact opposite. The history before the commit.
>
> This makes sense -- a commit object records all the heads that were merged
> together to make it, so a commit records its past, not its future.
>
> So how does git determine the future from commit X when the data only
> tracks the history before X?
>
>
Commands that take "--contains" are handy for looking to the future (from a
given commit). E.g.,
git branch --contains <commit-id>
"git for-each-ref" is my favourite command that takes "--contains".
I don't know how git does this under the hood.
> ===
>
> Can someone give me a better understanding of ".." and "..."? I thought
> ".." meant "everything from A to B", but apparently it is actually more
> general than that, and I don't understand "..." at all.
>
>
As for "A..B" vs. "A...B", "git help gitrevisions" explains all of this
very nicely:
<rev1>..<rev2>
Include commits that are reachable from <rev2> but exclude those
that are reachable from <rev1>. When either <rev1> or <rev2> is omitted, it
defaults to HEAD.
<rev1>...<rev2>
Include commits that are reachable from either <rev1> or <rev2>
but exclude those that are reachable from both. When either <rev1> or
<rev2> is omitted, it defaults to HEAD.
But let's see if [git-users] let's me upload an inline image. :-)
Consider this commit history:
<https://lh3.googleusercontent.com/-1YtAFzjLHSM/WIZlPe-EYEI/AAAAAAAAAHw/xMdKWqB9Li4jhcJ7P5BPI7wmn7HLtAj1ACLcB/s1600/branch.png>
"master..branch" means: everything reachable from "branch" (10ee95b in
this case) that is not also reachable from "master" (a0c6ff6):
10ee95b yes
62ee2a5 yes
afe0d7b no, because it's reachable from master
And so "master..branch" is a great way to select all commits on a branch up
to the moment it branched off the mainline.
"master...branch" is kinda like an xor: everything reachable from "branch"
as well as everything reachable from "master", but nothing that is
reachable from both:
10ee95b yes
a0c6ff6 yes
62ee2a5 yes
02a950a yes
afe0d7b no, because it's reachable from both
If you wanted to specify it more pedantically, you could invoke git log
like this achieve the same thing:
git log master branch ^$(git merge-base master branch)
(e.g., please give me master, branch, and exclude everything from their
merge-base).
- Regards,
Sylvie Davies
p.s. If you want to make graphs like that yourself (assuming it uploaded,
never count your chickens!) just copy & paste output of "git log" here:
http://bit-booster.com/graph.html
> ---
> Entertaining minecraft videos
> http://YouTube.com/keybounce
>
>
--
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
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
