Jakub Narebski <jnareb@xxxxxxxxx> wrote: > Junio C Hamano wrote: > > Pull: +refs/heads/*:refs/remotes/<origin>/* > > I hope that it also works with the remote.origin config file > section instead of $GIT_DIR/remotes/origin Yes, it does. Fortunately Git is relatively consistent. :-) > > Forcing with '+' is debatable, but with separate-remote layout, > > remotes/*/ hierarchy is to track what the remote has, and you > > cannot do much else other than noticing and warning when the > > remote end does funny things to its refs anyway, so I think > > having '+' might be a better default. > > Perhaps, perhaps not. It would be nice to have configuration option > that would tell that history of given branch is being changed, and > the ability to ask about it remotely, so git-clone would be able > to add this + _when needed_ automatically. > > But it's a fact that with separate remote the need to use fast-forward > check is lessened, and it might be more important to not confuse first > time user with having to modify $GIT_DIR/remotes/origin or remote.origin > config section to fetch from the repository he/she cloned from. Yes. From an out-of-the-box-make-Git-appear-to-be-easier-to-use point of view tossing + into the Pull:/remote.<name>.fetch setup might seem like the right thing to do. It lets the end-user blindly follow the upstream repository they cloned from. Almost. The problem becomes when the user makes a topic branch off say Junio's `pu` branch and later after doing a fetch and looking at the log of `remotes/origin/pu` decide to pull the updated `pu` into their topic branch, so they can continue testing. But now they are in merge hell as Junio has completely rebased `pu` and what was there isn't, and what's there now ain't compatible... and the new user curses at Git. Needing to put + in front of a refspec (or needing to fetch it with --force) is the user agreeing that something _evil_ is going on with the upstream and that they acknowledge this may cause problems for them locally. I would prefer to see the upstream be able to publish a short description of each branch, where the repository owner can describe the policy of that branch, as well as have a machine readable setting on each branch indicating if that branch will be rewound from time to time, or never rewound. git-clone should skip rewinding branches by default, unless the user adds an option (e.g. --include-rewinding-branches). This way new users to git.git don't get the `pu` branch unless they really mean to get it, at which point they have hopefully also read the upstream's description of the `pu` branch and its rewinding policy, and can at least start to grasp what is going to happen if they start to work with the branch. > > I am not sure if 'merge in corresponding branch' is the only > > valid workflow, however. I am reluctant to make the system > > automatically do so if the solution makes other workflows more > > painful to follow. Automatically merging remotes/origin/$foo > > when on $foo branch is not good enough, in other words (also, > > there may be a hierarchy under remotes/ other than origin). It > > might make sense to introduce "Merge: " in remotes/ file and if > > they are present use "Pull: " only to decide what are fetched > > and use "Merge: " to decide what is merged (if we were doing the > > system from scratch, the former would have been named "Fetch: " > > but it is too late now). > > If you add "Merge: " in remotes/, then please add it also in > remote section in config file. Config file has now > branch.<branchname>.merge (and it would be nice if clone would > set ou this for local branches corresponding to remote branches), > but it is not the same. I'm against adding anything to the remotes/ file format. We already have branch.<name>.merge to indicate what the default source for a git-pull on the branch named <name> should be. git-branch probably should fill that entry in when a branch is created from a remotes ref. -- Shawn. - 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