On 13/02/14 10:55, Robert Dailey wrote:
> I have the following alias defined:
> sync = "!f() { cbr=$(git rev-parse --abbrev-ref HEAD); git co $1 &&
> git pull && git co $cbr && git rebase $1; }; f"
>
> The goal is to basically update a local branch which tracks a branch
> on a remote, and then rebase my local topic branch onto that updated
> local branch.
Generally speaking there is little benefit in manually keeping a local
branch that just tracks a remote one because you already have a "remote
tracking branch" which gets updated whenever you fetch from that remote.
So you could be doing something like
git fetch origin # or whatever other remotes you may have configured
git rebase origin/master # or whatever branch you're tracking
You can also tell git this kind of information when you create your
topic branch and git will to this all for you.
git checkout -b topic1 origin/master
git pull -r # -r makes pull run fetch + rebase instead of pull + merge
If you already have a topic branch and you want to tell it what remote
branch (upstream) to track you can do that too.
git checkout topic
git branch -u origin/master
git pull -r
> I do this instead of just rebasing onto origin/master. Example:
>
> git checkout master
> git pull --rebase origin master
> git checkout topic1
> git rebase master
>
> I could do this instead but not sure if it is recommended:
>
> git checkout topic1
> git fetch
> git rebase origin/master
I do it all the time. Actually I set the upstream and I can just use
'git pull -r'.
> Any thoughts on the alias I created? I'm a Windows user and still new
> to linux stuff, so if it sucks or could be simplified just let me
> know.
Aliases are fine to save yourself some typing. In this case I think you
can just set the upstream branch and use 'git pull -r'. There is a
config option to make this the default but you probably want to be
comfortable with the difference between merging and rebasing before you
set that.
> And as a secondary question, just curious what people think about
> rebasing onto a remote tracking branch. When I do merges I usually
> refer to the remote branch, but during rebase I use the local branch
> instead, but I don't know if there is any functional reason to not
> skip the local branch and go straight to the remote tracking branch
> (it saves a step).
Branches are branches. You might use multiple local branches to separate
dependent topics that you're working on. You might do the same with
remote branches if you have topics based on other peoples work.
--
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
