Re: git rebase: yet another newbie quest.
John Keeping j...@keeping.me.uk writes: On Fri, Sep 05, 2014 at 02:28:46PM +0400, Sergey Organov wrote: ... # Then I realize I need more changes and it gets complex enough to # warrant a topic branch. I create the 'topic' branch that will track # 'master' branch and reset 'master' back to its origin (remote # origin/master in original scenario). git checkout -b topic git branch --force master origin_master This line is the problem, because the purpose of the `--fork-point` argument to `git rebase` is designed to help people recover from upstream rebases, which is essentially what you create here. So when rebase calculates the local changes it realises (from the reflog) that the state of master before this command was before you created the branch, so only commits after it should be picked. Thanks, but I did realize it myself (after I spent a few hours figuiring it out). The question is what should I have done instead? -- Sergey. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase: yet another newbie quest.
Theodore Ts'o ty...@mit.edu writes: I'm not going to say what you *should* have done, since it's not clear whether anything close to what you were doing is a supported workflow. But I can tell you what I *do* myself. Personally, I vastly distrust git pull --rebase. Thank you for sharing your experience! In the particular case at hand though, git rebase is the actual cause of the problem, not git pull --rebase. So in general, my pulls are all the equivalent of git pull --ff-only, and if I want to rebase the topic branch (which in general, is a bad idea to do regularly; I will generally not do it at all until I'm almost done). So I'll branch the topic branch off of origin (which tracks origin/master, typically): git checkout -b topic1 origin hack hack hack git commit ... make In general, I will only rebase a topic branch when it's needed to fix a serious conflcit caused by significant changes upstream. And in that case, I might do something like this: git checkout topic1 git rebase origin/master make make check Yeah, it's a good way to do things, but for most of quick fixes I'm lazy to create topic branch, and in this case it lead to a nasty unexpected trouble. I didn't intend to make topic branch from the very beginning, and already made a commit or two on the remote tracking branch bofore I realized I'd better use topic branch. It'd create no problem as far as I can see, provided vanilla git rebase has sane defaults. That said, I've already been once pointed to by Junio that my definition of sane doesn't take into account workflows of others, so now I try to be carefull calling vanilla git rebase names. Please also notice that I didn't pull immediately after I've re-arranged my branches, and this fact only made it more difficult to find and isolate the problem. [...] P.S. There is a separate, and completely valid discussion which is how to prevent a newbie from falling into a same trap you did. I'll defer that discussion to others... Yeah, it'd be fine if at least documentation is fixed. -- Sergey. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase: yet another newbie quest.
On Mon, Sep 08, 2014 at 05:52:44PM +0400, Sergey Organov wrote: I didn't intend to make topic branch from the very beginning, and already made a commit or two on the remote tracking branch bofore I realized I'd better use topic branch. It'd create no problem as far as I can see, provided vanilla git rebase has sane defaults. That said, I've already been once pointed to by Junio that my definition of sane doesn't take into account workflows of others, so now I try to be carefull calling vanilla git rebase names. Right, so what I typically in that situation is the following: on the master branch hack hack hack git commit hack hack hack git commit oops, I should have created a topic branch git checkout -b topic-branch git branch -f master origin/msater This resets the master branch to only have what is in the upstream commit. Please also notice that I didn't pull immediately after I've re-arranged my branches, and this fact only made it more difficult to find and isolate the problem. It's also the case that I rarely will do a git rebase without taking a look at the branches to make sure it will do what I expect. I'll do that using either gitk or git lgt, where git lgt is defined in my .gitconfig as: [alias] lgt = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit And typically what I will do is something like this: gitk -20 master origin/master topic -or- git lgt -20 master origin/master topic The git lgt command is very handy when I want to see how the branches are arranged, and I'm logged remotely over ssh/tmux or some such, so gitk isn't really available to me. Cheers, - Ted -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase: yet another newbie quest.
Theodore Ts'o ty...@mit.edu writes: On Mon, Sep 08, 2014 at 05:52:44PM +0400, Sergey Organov wrote: I didn't intend to make topic branch from the very beginning, and already made a commit or two on the remote tracking branch bofore I realized I'd better use topic branch. It'd create no problem as far as I can see, provided vanilla git rebase has sane defaults. That said, I've already been once pointed to by Junio that my definition of sane doesn't take into account workflows of others, so now I try to be carefull calling vanilla git rebase names. Right, so what I typically in that situation is the following: on the master branch hack hack hack git commit hack hack hack git commit oops, I should have created a topic branch git checkout -b topic-branch git branch -f master origin/msater This resets the master branch to only have what is in the upstream commit. But that's *exactly* what lead me to the problem! Here is relevant part of my script: git checkout -b topic git branch --force master origin_master git branch -u master except that I wanted to configure upstream as well for the topic-branch, that looks like pretty legit desire. If I didn't, I'd need to specify upstream explicitly in the git rebase, and I'd not notice the problem at all, as the actual problem is that git rebase and git rebase upstream work differently! -- Sergey. P.S. Nice 'lgt' alias, BTW. I simply use: $ git help hist git hist' is aliased to `log --oneline --graph --decorate' stolen somewhere. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase: yet another newbie quest.
On Mon, Sep 08, 2014 at 07:47:38PM +0400, Sergey Organov wrote: except that I wanted to configure upstream as well for the topic-branch, that looks like pretty legit desire. If I didn't, I'd need to specify upstream explicitly in the git rebase, and I'd not notice the problem at all, as the actual problem is that git rebase and git rebase upstream work differently! Right, so I never do that. I have master track origin/master, where it automagically does the right thing, but I'm not even sure I can articulate what it *means* to have topic also track origin/master. I just don't have a mental model for it, and so it falls in the category of it's too complicated for my simple brain to figure out. So I just do git rebase master, and I would never even *consider* doing a git pull --rebase. I'll do a git fetch, and then look at what just landed, and and then checkout master, update it to origin/master, and then run the regression tests to make sure what just came in from outside actually was *sane*, and only then would I do a git checkout topic; git rebase master, and then re-run the regression tests a third time. Otherwise, how would I know whether the regression came in from origin/master, or from my topic branch, or from the result of rebasing the topic branch on top of origin/master? And of course, this goes back to my observation that I don't rebase my topic branchs all that often anyway, just because the moment you do the rebase, you've invalidated all of the testing that you've done to date. In fact, some upstreams will tell explicitly tell you to never rebase a topic branch before you ask them to pull it in, unless you need to handle some non-trivial merge conflict. Cheers, - Ted -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase: yet another newbie quest.
Theodore Ts'o ty...@mit.edu writes: On Mon, Sep 08, 2014 at 07:47:38PM +0400, Sergey Organov wrote: except that I wanted to configure upstream as well for the topic-branch, that looks like pretty legit desire. If I didn't, I'd need to specify upstream explicitly in the git rebase, and I'd not notice the problem at all, as the actual problem is that git rebase and git rebase upstream work differently! Right, so I never do that. I have master track origin/master, where it automagically does the right thing, but I'm not even sure I can articulate what it *means* to have topic also track origin/master. You got it somewhat wrong. I intended 'topic' to track 'master', not 'origin/master'. I just don't have a mental model for it, and so it falls in the category of it's too complicated for my simple brain to figure out. I thought it's rather common for one local branch to track another in the git world. At least all machinery is there, and I don't see how tracking local branch is different from tracking remote branch, fundamentally. So I just do git rebase master, and I would never even *consider* doing a git pull --rebase. I'll do a git fetch, and then look at what just landed, and and then checkout master, update it to origin/master, and then run the regression tests to make sure what just came in from outside actually was *sane*, and only then would I do a git checkout topic; git rebase master, and then re-run the regression tests a third time. Yeah, and I simply wanted to shorten it to git checkout topic; git rebase, by making git remember I want to rebase w.r.t. 'master' by default. Otherwise, how would I know whether the regression came in from origin/master, or from my topic branch, or from the result of rebasing the topic branch on top of origin/master? As far as I can see, what I did is almost exactly what you do, except I didn't want to tell master every time I want to rebase 'topic' branch. Configuring tracking branch and saying just git rebase when you are on the branch seems to be logical, and there doesn't seem to be anything wrong with it (except strange git default behavior), or does it? And of course, this goes back to my observation that I don't rebase my topic branchs all that often anyway, just because the moment you do the rebase, you've invalidated all of the testing that you've done to date. In fact, some upstreams will tell explicitly tell you to never rebase a topic branch before you ask them to pull it in, unless you need to handle some non-trivial merge conflict. That's good advice indeed, but it's unrelated to the issue at hand, as you still rebase, sooner or later. -- Sergey. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase: yet another newbie quest.
I'm not going to say what you *should* have done, since it's not clear whether anything close to what you were doing is a supported workflow. But I can tell you what I *do* myself. Personally, I vastly distrust git pull --rebase. So in general, my pulls are all the equivalent of git pull --ff-only, and if I want to rebase the topic branch (which in general, is a bad idea to do regularly; I will generally not do it at all until I'm almost done). So I'll branch the topic branch off of origin (which tracks origin/master, typically): git checkout -b topic1 origin hack hack hack git commit . . . Then I might do something like this to do a build: git fetch origin ; git branch -f origin origin/master# this is optional git checkout -B build origin git merge topic1 git merge topic2 ... make In general, I will only rebase a topic branch when it's needed to fix a serious conflcit caused by significant changes upstream. And in that case, I might do something like this: git checkout topic1 git rebase origin/master make make check This basically goes to a philosophical question of whether it's simpler to tell users to use a single command, such as git pull --rebase, or whether to tell users to use a 2 or 3 commands that conceptually much more simple. Personally, I type fast enough that I tend to use simple commands, and not try to use things like automated branch tracking. That way I don't have to strain my brain thinking about things like fork points. :-) OTOH, some people feel that it's better to make things like git pull --rebase work and do the right thing automatically, because competing DSCM allows you to do it in a single command. And indeed, if you use git pull --rebase without any topic branches, it works fine. But then when you start wanting to do things that are more complicated, the automated command starts getting actually harder and more confusing (at least in my opinion). I don't know if a workflow involving topic branches was even expected to work with git pull --rebase, and if so, how to set things up so that they do work smoothly. All I know is that the issue never arises with me, because it's rare that I use git pull, let alone git pull --rebase. That's because I usually like to take a quick look at what I've pulled (using gitk, or git log) before do the merge operation. If I'm doing a pull from a repo that I control, and so I think I'm sure I know what's there, I might skip the git fetch, and do a git pull --ff-only instead. But in general I prefer to do the merging separate from the pull operation. Cheers, - Ted P.S. There is a separate, and completely valid discussion which is how to prevent a newbie from falling into a same trap you did. I'll defer that discussion to others... -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase: yet another newbie quest.
On Fri, Sep 05, 2014 at 02:28:46PM +0400, Sergey Organov wrote: ... # Then I realize I need more changes and it gets complex enough to # warrant a topic branch. I create the 'topic' branch that will track # 'master' branch and reset 'master' back to its origin (remote # origin/master in original scenario). git checkout -b topic git branch --force master origin_master This line is the problem, because the purpose of the `--fork-point` argument to `git rebase` is designed to help people recover from upstream rebases, which is essentially what you create here. So when rebase calculates the local changes it realises (from the reflog) that the state of master before this command was before you created the branch, so only commits after it should be picked. For the case when the upstream of a branch is remote, this is normally what you want. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
