Shawn Pearce <spearce@xxxxxxxxxxx> writes: >> Strictly speaking, however, the config file is a wrong place to >> store it. For one thing it has core.sharedrepository and >> receive.denynonfastforwards that are true configuration to >> control the behaviour of git _at_ _the_ _repository_ the >> configuration is at. The new "branch property" are primarily to >> help the other end, and the "filtering rewinding ones" we want >> at the clone/fetch side wants that information only and not >> interested in the true configuration information at that >> repository. > > Yes, of course. I never suggested copy the entire configuration > as is. I never misunderstood your plan as such. I was more worried about a case where you clone from a not-so-public repository and the config file has some information of sensitive nature. Currently we do not have any such variable, so I am probably being a bit paranoid here, but using the config for the purpose of what we are discussing right now closes the door to store sensitive information and declare that the config file at the remote is "none of the cloner's business". However,... > Besides of which, lets not forget that something like: > > [branch "master"] > rewinds = false > [branch "pu"] > rewinds = true > > is not only data for the client to examine. It can be useful in > say git-receive-pack as a much more fine-grained alternative to > receive.denynonfastforwards. If the server's policy is to not > rewind a branch then receive-pack shouldn't let a remote user > rewind it. At which point its useful to have that branch data > in $GIT_DIR/config. :-) This is a good point. If we want to ever have a 'not to be leaked' configuration per repository, we can have a separate, private, configuration file to store that, so I probably should not worry too much about this at this point. I'm Ok with having this in the usual config -- the convenience outweighs the purity. To summarize: * A repository can have branch."foo".rewinds configuration to mark the "foo" branch to be subject to rewinding. This configuration variable defaults to false. * Receive.denynonfastforwards is currently a boolean but a new value, "per-branch", is also allowed. When it is set to "per-branch", non fast-forward update is allowed only when branch."foo".rewinds is true for the branch. * A cloner creates "Pull: refs/heads/*:refs/remotes/origin/*" (or config equivalent) upon cloning. When it clones, it downloads the config from the remote in order to see which are marked as "rewinds". It makes tracking branches for only the ones that are not marked as "rewinds" by default. We might have an option to do '+' variant glob, and clone all branches. * Subsequent fetch, when the glob is not '+' variant, would download the config from the remote in order to see which are marked as "rewinds", and ignores the branches that are marked as such. I am a bit unhappy that subsequent fetches have to re-read the remote config every time. I can sort-of-see we can cram the "this is expected to be rewound" information as part of peek-remote exchange to avoid the overhead, but I do not think it is easily doable for dumb transports without breaking the backward compatibility. To avoid this, we need to remember what remote branches we have seen but decided not to track, perhaps because they were marked as "rewinds". Subsequent fetches first learn what are on the remote side, and only when it sees a branch that we do not track and we have not seen, it needs to re-read the remote config to see if that is to be tracked (in which case we would create a new tracking branch) or ignored (in which case we would remember that we will ignore this branch in the future fetches). - 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