----- Original Message -----
From: G. Sylvie Davies
To: Git for human beings
Cc: flatw...@users.sourceforge.net
Sent: Monday, January 23, 2017 8:19 PM
Subject: Re: [git-users] Finding a string somewhere in a repository after a
given commit.
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> 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:
"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
The two dot and three dot notation descriptions were recently updated, and
hopefully I got them changed to something slightly better, but the can still be
tricky, especially with remote branches
so: `master..my_feature` (two dots)
root--x-x-x-x-o-y-y-y-y - master
. \
. z-z-z-z-z - my_feature
we have that my_feature was branched (fork point / merge base) at the commit
`o`.
Master continued as y-y-y etc.
My_feature continued as z-z-z etc.
hence `master..my_feature` is everything on my_feature (those z-z-z commits),
excluding those reachable from master (those y-y-y commits, 'o' and the earlier
x-x-x commits), becoming the same as o..myfeature, which then becomes the same
as `my_feature ^o` which says not to take 'o' or anything earlier.
meanwhile `master...myfeature` (three dots)
is the 'symetric difference', with o..master being the left (hand) side, and
o..my_feature being the right (hand) side, again without 'o', the fork point.
Philip
--
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.
