On Tue, Jan 07, 2014 at 04:17:00AM +0530, Ramkumar Ramachandra wrote:
> Junio C Hamano wrote:.
> > As I said in the different subthread, I am not convinced that you
> > would need the complexity of branch.*.forkedFrom. If you set your
> > "upstream" to the true upstream (not your publishing point), and
> > have "remote.pushdefault"set to 'publish', you can expect
> >
> > git push
> >
> > to do the right thing, and then always say
> >
> > git show-branch publish/topic topic
>
> I think it's highly sub-optimal to have a local-branch @{u} for
> several reasons; the prompt is almost useless in this case, and it
> will always show your forked-branch ahead of 'master' (assuming that
> 'master' doesn't update itself in the duration of your development).
I actually use local-branch @{u} all the time to represent inter-topic
dependencies. For example, imagine I have topic "bar" which builds on
topic "foo", which is based on master. I would have:
[branch "foo"]
remote = origin
merge = refs/heads/master
[branch "bar"]
remote = .
merge = refs/heads/foo
When I rebase "foo", I want to rebase it against upstream's master. When
I rebase "bar", I want to rebase it against foo. And naturally, upstream
does not necessarily have a "foo", because it is my topic, not theirs (I
_may_ have published my "foo" somewhere, but that is orthogonal, and
anyway my local "foo" is the most up-to-date source, not the pushed
version).
As an aside, if you want to rebase both branches, you have to topo-sort
them to make sure you do "foo" first, then rebase "bar" on the result.
My daily procedure is something like:
all_topics |
while read topic; do "echo $topic $(git rev-parse $topic@{u})"; done |
topo_sort |
while read topic upstream; do
git rebase $upstream $topic || exit 1
done
> While doing respins, the prompt doesn't aid you in any way. Besides,
> on several occasions, I found myself working on the same forked-branch
> from two different machines; then the publish-point isn't necessarily
> always a publish-point: it's just another "upstream" for the branch.
Right, things get trickier then. But I don't think there is an automatic
way around that. Sometimes the published one is more up to date, and
sometimes the upstream thing is more up to date. You have to manually
tell git which you are currently basing your work on. I find in such a
situation that it tends to resolve itself quickly, though, as the first
step is to pull in the changes you pushed up from the other machine
anyway (either via "git reset" or "git rebase").
-Peff
--
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
