Jeff King wrote:
> 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
Ah, I was perhaps over-specializing for my own usecase, where
everything is based off 'master'. I never considered 'master' a "true
upstream" because I throw away topic branches after the maintainer
merges them. If you have long-running branches that you work on a
daily basis, the issue is somewhat different.
>> 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").
My primary concern is that the proposed @{publish} should be a
first-class citizen; if it has everything that @{u} has, then we're
both good: you'd primarily use @{u}, while I'd primarily use
@{publish}.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html