Hi, thanks for the response.
On May 7, 2008, at 9:22, Junio C Hamano wrote:
You got no reactions, neither
positive nor negative, partly due to this sentence, I suspect.
I got one response from someone who said he had implemented the same
thing in one of his branches. That seemed to confirm the idea for
me. Some additional features were suggested to be built on top of
this, but I didn't read it as necessary for proceeding.
Please sign-off your patches (see Documentation/SubmittingPatches).
Oh thanks, I hadn't seen this. I read it as well as the
CodingGuidelines document.
+ When `never`, rebase is never automatically set to true.
+ When `local`, rebase is set to true for tracked branches of
+ other local branches.
+ When `remote`, rebase is set to true for tracked branches of
+ remote branches.
+ When `always`, rebase will be set to true for all tracking
+ branches.
+ This option defaults to never.
How does this interact with a similarly named configuration option,
autosetupmerge, whose settings can be false, true, and always?
I can direct the user to the autosetupmerge config documentation
since it also documents the flags that override its behavior. Is this
acceptable?
branch.<name>.remote::
When in branch <name>, it tells `git fetch` which remote to fetch.
If this option is not given, `git fetch` defaults to remote
"origin".
This is not your fault, but can anybody guess what the exact command
sequence to cause the named branch to be advanced by rebasing, only by
reading this entry?
branch.<name>.rebase::
When true, rebase the branch <name> on top of the fetched
branch,
instead of merging the default branch from the default
remote.
I can't. Perhaps we would need "when "git pull" is run" or
something at
the end.
I'll submit this as a separate patch.
Is this correct?
[...]
You might want to check how the setup_tracking() decides when to say
remote/local in its printf().
Oh thanks, I clearly didn't understand this and just relied on my
tests passing by coincidence.
I'll resubmit my patch with your recommendations, thanks.
--
Dustin Sallings
--
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
