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
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
More majordomo info at

Reply via email to