[openstack-dev] [git-review] Supporting development in local branches

Yuriy Taraday yorik.sar at gmail.com
Thu Aug 7 22:52:27 UTC 2014


On Thu, Aug 7, 2014 at 7:36 PM, Ben Nemec <openstack at nemebean.com> wrote:

> On 08/06/2014 05:35 PM, Yuriy Taraday wrote:
> > On Wed, Aug 6, 2014 at 11:00 PM, Ben Nemec <openstack at nemebean.com>
> wrote:
> >> You keep mentioning detached HEAD and reflog.  I have never had to deal
> >> with either when doing a rebase, so I think there's a disconnect here.
> >> The only time I see a detached HEAD is when I check out a change from
> >> Gerrit (and I immediately stick it in a local branch, so it's a
> >> transitive state), and the reflog is basically a safety net for when I
> >> horribly botch something, not a standard tool that I use on a daily
> basis.
> >>
> >
> > It usually takes some time for me to build trust in utility that does a
> lot
> > of different things at once while I need only one small piece of that.
> So I
> > usually do smth like:
> > $ git checkout HEAD~2
> > $ vim
> > $ git commit
> > $ git checkout mybranch
> > $ git rebase --onto HEAD@{1} HEAD~2
> > instead of almost the same workflow with interactive rebase.
>
> I'm sorry, but "I don't trust the well-tested, widely used tool that Git
> provides to make this easier so I'm going to reimplement essentially the
> same thing in a messier way myself" is a non-starter for me.  I'm not
> surprised you dislike rebases if you're doing this, but it's a solved
> problem.  Use git rebase -i.
>

I'm sorry, I must've mislead you by using word 'trust' in that sentence.
It's more like understanding. I like to understand how things work. I don't
like treating tools as black boxes. And I also don't like when tool does a
lot of things at once with no way back. So yes, I decompose 'rebase -i' a
bit and get slightly (1 command, really) longer workflow. But at least I
can stop at any point and think if I'm really finished at this step. And
sometimes interactive rebase works for me better than this, sometimes it
doesn't. It all depends on situation.

I don't dislike rebases because I sometimes use a bit longer version of it.
I would be glad to avoid them because they destroy history that can help me
later.

I think I've said all I'm going to say on this.


I hope you don't think that this thread was about rebases vs merges. It's
about keeping track of your changes without impact on review process.

-- 

Kind regards, Yuriy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140808/cafb59c4/attachment.html>


More information about the OpenStack-dev mailing list