"Santi Béjar" [off-list ref] writes:
On 12/8/06, Josef Weidendorfer [off-list ref] wrote:
quoted
Clarify the meaning of branch.*.merge option and add a similar
branch.*.localmerge option, which can be used to specify a local
tracking branch to be merged by default.
Previously, if branch.*.merge was specified but did not match any
ref, the message "No changes." was not really helpful regarding
the misconfiguration. This now gives a warning.
The value of branch.*.merge can be a list to get an octopus
merge. I chose the same way for branch.*.localmerge, and if
you specify both options, the octopus merge will have even
more parents ;-)
Signed-off-by: Josef Weidendorfer <redacted>
Ack for the documentation part. But the localmerge part is almost
equivalent to my patch to allow the branch.<name>.remote equal to ".".
I am not so sure about the "localmerge" stuff anymore.
What convenience would it buy us (including but not limited to
new people), and if there is any, would that outweigh the
potential confusion factor to have two different configuration
variables that do exactly the same thing whose sole difference
is which side of the fetched branch namespace it uses to specify
the merge source?
On Friday 08 December 2006 22:38, Junio C Hamano wrote:
"Santi Béjar" [off-list ref] writes:
quoted
On 12/8/06, Josef Weidendorfer [off-list ref] wrote:
quoted
Clarify the meaning of branch.*.merge option and add a similar
branch.*.localmerge option, which can be used to specify a local
tracking branch to be merged by default.
I am not so sure about the "localmerge" stuff anymore.
What convenience would it buy us (including but not limited to
new people), and if there is any, would that outweigh the
potential confusion factor to have two different configuration
variables that do exactly the same thing whose sole difference
is which side of the fetched branch namespace it uses to specify
the merge source?
I just came up with a concrete patch.
I am not saying that this is the only true solution.
Actually, Jakubs one with allowing arbitrary refspecs is nice.
The only problem is that it is not consistent which refspec
shortcuts otherwise, or?
However, you should take the documentation part and the warning
when there is no match .
<opublikowany i wysłany>
Junio C Hamano wrote:
"Santi Béjar" [off-list ref] writes:
quoted
On 12/8/06, Josef Weidendorfer [off-list ref] wrote:
quoted
Clarify the meaning of branch.*.merge option and add a similar
branch.*.localmerge option, which can be used to specify a local
tracking branch to be merged by default.
Previously, if branch.*.merge was specified but did not match any
ref, the message "No changes." was not really helpful regarding
the misconfiguration. This now gives a warning.
[...]
quoted
Ack for the documentation part. But the localmerge part is almost
equivalent to my patch to allow the branch.<name>.remote equal to ".".
I am not so sure about the "localmerge" stuff anymore.
What convenience would it buy us (including but not limited to
new people), and if there is any, would that outweigh the
potential confusion factor to have two different configuration
variables that do exactly the same thing whose sole difference
is which side of the fetched branch namespace it uses to specify
the merge source?
What about my proposal to allow for full refspec, or :<localbranch>
to be specified? I.e. allow all the following forms:
branch.<name>.merge = refs/heads/<remotebranch>
branch.<name>.merge = refs/heads/<remotebranch>:refs/remotes/<remote>/<localbranch>
branch.<name>.merge = :refs/remotes/<remote>/<localbranch>
By the way, if branch.*.remote is equal to ".", remote branch is
local branch.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git