In message <32741263.335615.1285247653984.JavaMail.root@xxxxxxxxxxxxxxxxxxx>, S
tephen Bash writes:
----- Original Message -----
> From: "Seth Robertson" <in-gitvger@xxxxxxxx>
> To: "Artur Skawina" <art.08.09@xxxxxxxxx>
> Cc: "Stefan Haller" <lists@xxxxxxxxxxxxxxxx>, git@xxxxxxxxxxxxxxx
> Sent: Wednesday, September 22, 2010 7:26:19 PM
> Subject: Re: Find out on which branch a commit was originally made) (was ANNOUNCE git-what-branch)
>
> ... I wanted something completely different. Something more
> like: if a bug was introduced in commit X, what releases or branches
> has it contaminated (or more positively, if a feature was introduced,
> where was it made available). The simple case is figuring out on
> which branch a commit was originally made.
Wait... When you restate the problem that way, isn't
git-{branch,tag} --contains the right answer? I'm curious how you
(and others) would differentiate the approaches...
Oh, it is, don't get me wrong. I actually use `git-branch --contains`
in the script to generate my candidate list. This doesn't solve the
cherry-pick problem, but I don't solve that either (yet). I found it
difficult to verbalize exactly why this was needed--I know I have
needed it in the past which was why I pounced on the thread and used
the ideas to write git-what-branch
http://github.com/SethRobertson/git-what-branch
If I were to frame this discussion, I think the value of
git-what-branch is the ability to extract the branch name that a
commit was created on. In many environments the branch name may
be useless (see the i18n example earlier in this discussion), but
at least in our corporate environment, branches (especially those
that are going to merge into mainline development) are named very
consistently. So in our situation the branch name can produce
information that may not be captured in the standard reporting
products (branch names transform into conventional tag names,
branch names imply a lead developer, branch names spur developers'
memories, ...).
Exactly. The ability to see if a commit was born on a branch or what
branch it was merged to first is what is most important (anonymous
branches do exist even if you try to use --rebase consistently) so the
ability to find which branch it merged into first is also important.
This is the default operating mode of git-what-branch.
To a lesser extent, fornensics to help understanding how a commit
merged into a specific target may also be interesting. It would be
even nicer if we could express a path of interest to gitk so that you
could have that specific path highlighted in a `gitk --all` output.
Hmm. Path/commit highlighting would be a nice feature in gitk no
matter what. --highlight-stdin to highlight specific commits (and
ideally an algorithm to allow the connecting arcs for adjancent
commits to be highlighted. There is already an interestedin hammer
Also being able to highlight specific commits at runtime (probably a
different color) and potentially enter a commit note would be pretty
cool as well. Unfortunately I have a different skill-set.
-Seth Robertson
--
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