[Insight-developers] ITK / Gerrit question

[Marcus D. Hanwell]

I see your point, and realize we all work differently - let me look into this.

Marcus

On Tue, Oct 26, 2010 at 6:36 PM, Hans Johnson <hans-johnson at uiowa.edu> wrote:
> I agree.  I do this all the time too.  When I am not on the "no branch"
> branch, I don't know what I'm working on, and that seems dangerous to me.
>
> On 10/26/10 2:43 PM, "Bill Lorensen" <bill.lorensen at gmail.com> wrote:
>>
>> Some of us are doing multiple reviews at the same time. And some of us
>> always make a branch when we are reviewing.
>>
>> Also, a branch is useful if you are going to push another user's
>> gerrit patch to the stage.
>>
>> Right now, I manually do a git checkout -b topic_name and I cut the
>> topic name from the gerrit page so that I don't misspell it.
>>
>> I would find this very useful.
>>
>> On Tue, Oct 26, 2010 at 1:21 PM, Marcus D. Hanwell
>> <marcus.hanwell at kitware.com> wrote:
>>> On Tue, Oct 26, 2010 at 11:40 AM, Luis Ibanez <luis.ibanez at kitware.com>
>>> wrote:
>>>>
>>>> Hi Marcus,
>>>>
>>>> At the ITK tcon we were wondering if we could modify our installation of
>>>> Gerrit
>>>> to have the git command line create a branch with the topic that is just
>>>> checked out.
>>>>
>>>> so, to change:
>>>>
>>>> git fetch ssh://ibanez@review.source.kitware.com:29418/ITK
>>>> refs/changes/34/234/1
>>>> && git checkout FETCH_HEAD
>>>>
>>>> into
>>>>
>>>>
>>>> git fetch ssh://ibanez@review.source.kitware.com:29418/ITK
>>>> refs/changes/34/234/1
>>>> && git checkout FETCH_HEAD -b topic-name
>>>>
>>>>
>>>> Do you think this could be done ?
>>>>
>>> I think it could be done, but the majority of the time when reviewing
>>> a topic branch there is no need to make it into a named topic branch.
>>> You only really need to assign it a name if you are going to stage it,
>>> and merge it. Then a,
>>>
>>> git checkout -b topic-name
>>>
>>> Would give you that from the detached head. You still need to ensure
>>> you are at the tip of the topic, and most of the time I would rather
>>> have the current behavior. I can take a look and see where the change
>>> would be required, and how likely it is that it would be accepted
>>> upstream (as we would rather not maintain a patched version of Gerrit
>>> long term).
>>>