Junio C Hamano wrote: > Now separate-remote layout is the default for newly cloned > repositories, I think it is a good time to make further effort > to make things easier to use. Here are some of the ideas off > the top of my head. [...] > * Change the default contents of $GIT_DIR/remotes/origin The question is: do we continue to use remotes/ file, or do we save remotes info in the config file: remote.<name>.url, remote.<name>.fetch, remote.<name>.push and branch.<name>.merge (in our case '[remote "origin"]' section)? > Currently we list all the remote branches that exist when the > clone is made, making sure that the branch pointed at by HEAD at > the remote is listed first. The intent is to track every branch > at the remote but merge in the "primary" branch to us. > > Two issues that have been raised about this is: > > - the intent to track every branch is good, but the current > implementation means we would not notice new branches at the > remote. > > - merging the "primary" branch is good only when the user is on > the corresponding "primary" branch. It is usually a wrong > thing to do when on another branch. > > The first issue can be solved, with the help of recent "glob > pattern refspec in fetch" from Andy. I am thinking about making > the default contents of $GIT_DIR/remotes/origin to be: > > URL: <url of the cloned repository> > Pull: +refs/heads/<primary>:refs/remotes/<origin>/<primary> > Pull: +refs/heads/*:refs/remotes/<origin>/* > > to address this issue. I hope that it also works with the remote.origin config file section instead of $GIT_DIR/remotes/origin > Side note: <primary> is what HEAD pointed at at the > remote when the clone was made, and <origin> is usually > 'origin' but "git clone -o $origin" can override it. > > 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. > The right thing to do to address the second issue is less clear. > If the "upstream" has two more-or-less equally prominent > branches, say 'main' and 'test', it may make sense to use > corresponding two branches on the local side and merge 'main' > from the remote when on local 'main' and merge 'test' when on > local 'test'. Even when dealing with a specific topic branch, > that would hold true for most of the time. A topic branch > refs/heads/bug#2073 to work on the bug 2073 can be published at > the central distribution point. The proposed updates to > $GIT_DIR/remotes/origin file would track it with > refs/remotes/origin/bug#2073 and interested people can create a > local branch refs/heads/bug#2073 from it and work on it, which > makes it easy to polish a topic branch in a collaborative way. > > 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. -- Jakub Narebski Warsaw, Poland ShadeHawk on #git - 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