Andreas Krey <a.krey@xxxxxx> writes: > On Thu, 17 Dec 2009 16:07:08 +0000, Junio C Hamano wrote: > ... >> Also "git pull --remember $there $this" might be a good way to tell the >> configuration mechanism from the UI to remember that "I always want to >> merge $this branch from $there while on the branch I am currently on", and >> its implementation may probably use "git branch --reconfigure" internally. > > Actually my favorite would be 'git push --track $there', pushing > the current local branch to $there and setting up tracking. That > way the tracking decision need not be made before the remote > branch actually exists. Yeah, it may be useful, but that belongs to the same "in addition to the most flexible form, we might want to _also_ do so" category, as the one that makes "git pull" remember. The advantage of remembering upon the first pull is that the request to remember doesn't involve any "push is reverse of pull" indirection. Instead, it is exactly what the user actually has done once: "I'm doing this once, remember it for me". Compared to it, I think it is less obvious to make the first push remember its reverse [*1*]. Another issue that you need to think about is how you will allow users to set up "integrate with merge or rebase" when making "push" remember. An option with "pull" would make it much more obvious what is going on, as the user would say "git pull --rebase --remember $there $this" if rebasing is desired, and that is what is going to be remembered; again that is thanks to the "I'm doing this once, remember it for me" semantics. [Footnote] *1* I am not saying "if you have 'pull --remember' you don't need 'push --remember'" or vice versa. As long as each (judged individually) makes sense we could have both. -- 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