Re: Re: Find out on which branch a commit was originally made) (was ANNOUNCE git-what-branch)

In message <32741263.335615.1285247653984.JavaMail.root@mail.hq.genarts.com>, S tephen Bash writes:

    ----- Original Message -----
    > From: "Seth Robertson" <in-gitvger@baka.org>
    > To: "Artur Skawina" <art.08.09@gmail.com>
    > Cc: "Stefan Haller" <lists@haller-berlin.de>, git@vger.kernel.org
    > 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