<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 7, 2014 at 7:36 PM, Ben Nemec <span dir="ltr"><<a href="mailto:openstack@nemebean.com" target="_blank">openstack@nemebean.com</a>></span> wrote:<br>

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

<div style><br></div><div style>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


I think I've said all I'm going to say on this.</blockquote></div><div class="gmail_extra"><br></div>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.<br clear="all">

<div><br></div>-- <br><br><div>Kind regards, Yuriy.</div>
</div></div>