On 09/20/10 01:54, Seth Robertson wrote:
> In message <4C9698C5.70607@xxxxxxxxx>, Artur Skawina writes:
>
> On 09/20/10 00:03, Seth Robertson wrote:
>>>>>> A---B---C topic
>>>>>> / \
>>>>>> D---E---F---G---H---I---J---K---L---M---N master
>>>>>> \ /
>>>>>> O---P---Q another-topic
>>>
>>>>> No, that's not what I need either. After thinking about it more, I
>>>>> think what I want is "of all merges in the ancestry path from B to
>>>>> master, show only those whose first parent can't reach B." The result
>>>>> is the list of all merges that were involved in bringing B to master.
>>>
>>>
>>>> This would work, and i don't see a way to optimize it in git-speak,
>>>> given that you don't want to see any extra trailing merges. [...]
>>>
>>> The provided command actually doesn't work for me for all cases. It
>>> works for the simple case of "B", but does not work for "F", because F
>>> saw merge H & M. I think we need --not --first-parent, except that
>>
>> Well, F was never on a separate branch, so the command returning ""
>> is arguably the right thing.
>
> I'd like a command that would tell me the right branch something was
> on whether it was on master or topic or whatever. If instead of
> "master" the branch was named "supertopic" and master commit AA had
> child D would that make a difference?
Like i said, "arguably". In theory, no, there is no difference. In
practice, some branches will be more long-lived than others -- and
certain conventions will apply. Hence, i think that answer /is/ the
right one, in context -- that script was specifically looking for
info on /another/ branch.
>>> doesn't actually work in this case either. However, if we get the
>>> full --first-parent rev-list and look for our commit, that works.
>>> This is incredibly painful, though.
>>> ----------------------------------------------------------------------
>>> #!/bin/sh
>>> TARGET=`git rev-list -n 1 $1`
>>> git branch -a --contains $1 | sed 's/^\** *//' | grep -v ' -> ' |
>>> while read br; do
>>> if git rev-list --first-parent $br | grep -q "$TARGET"; then
>>> echo $br
>>> fi
>>> done
>>> ----------------------------------------------------------------------
>
>> And it does not work if you no longer have the branches around...
>
> If something doesn't have a name I am not very interested in it (for
> my purposes, your milage may vary). Presumably the other code could be
> combined with my inner loop.
>
>> But even if you kept all the old refs, this would return
>> "another-topic"+"master", which is hardly the right answer.
>
> I'm not sure how you can figure out when a branch was first created.
> We might "know" that master is older than the others, but if this
> commit was on another-topic and supertopic we cannot use that
> intuition..
>
> Returning all possible branch names at least gives the user somewhere
> to start and does not give them ones which are obviously insane.
If you want to find out on which branch a change was committed and
"master" is right for 'F', then the "another-topic" part of that
answer is problematic -- every commit on that branch is a descendant
of 'F", and so is everything in between $common_base ('J') and master.
If you /don't/ treat master as special (ie don't treat the first
parent as special) what is then the difference vs a simple
"git branch -a --contains F"?
IOW, why would the right answer for 'F' be both 'master' and
'another-topic', but for 'B' - just 'topic'?
artur
--
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