# Branch metainformation 4 messages from 2006-04-20 to 2006-04-20. Participants: Jakub Narebski, Johannes Schindelin, Junio C Hamano. Thread: https://gitlist.dev/t/3927 ## Jakub Narebski, 2006-04-20 07:39 Subject: Branch metainformation Message-ID: URL: https://gitlist.dev/e/e27dqv%24u6f%241%40sea.gmane.org ``` It seems that ever so often there is question posted on this list on which the answer is to add '+' in 'pu' branch 'Pull:' line. I think that it is not a good policy to have puller to remember which branches can be fast-forwarded, and which needs to be merged. It should be an information set and stored by person managing the branch (pullee), as some kind of metainformation for the branch (like description and optional signature is for tags). Perhaps then there would be a place for short, one-line description of the branch... -- Jakub Narebski Warsaw, Poland ``` ## Johannes Schindelin, 2006-04-20 09:37 Subject: Re: Branch metainformation Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0604201131240.9099%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: ``` Hi, On Thu, 20 Apr 2006, Jakub Narebski wrote: > It seems that ever so often there is question posted on this list on which > the answer is to add '+' in 'pu' branch 'Pull:' line. I think that it is > not a good policy to have puller to remember which branches can be > fast-forwarded, and which needs to be merged. It should be an information > set and stored by person managing the branch (pullee), as some kind of > metainformation for the branch (like description and optional signature is > for tags). > > Perhaps then there would be a place for short, one-line description of the > branch... I have an alternative in my private repository: When git-pull/git-fetch are called with "-S ", then the current URL is set as URL for that shorthand, and the rest is *added* as Pull line. However, this all depends on my (rejected) patch to move the remotes information into the config file. I have not backported the "-S" feature to the non-config remotes, since I 1) do not need it myself, and 2) am wary that it is not that easy to ensure data integrity by shell-scripting. Ciao, Dscho ``` ## Junio C Hamano, 2006-04-20 10:18 Subject: Re: Branch metainformation Message-ID: <7vwtdkzh1u.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vwtdkzh1u.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Johannes Schindelin writes: > However, this all depends on my (rejected) patch to move the remotes > information into the config file. You seem to keep saying rejected, but IIRC you did not finish it IOW the patch was not ready to be merged. I do not recall, for example, reading the part that touches git-parse-remote or git-fetch to read from the config, but it was a long time ago and my recollection is vague. While we are talking about per branch property, some issues raised on the list (and #git) recently would be helped by a convention (and perhaps some core side support) for per-branch property. Here is a short list. + When I am on branch X, I would want "git pull" to pull (i.e. fetch and merge) from repository Y, not always "origin". + When I am on branch X, I would want "git push" to push to repository Y (we do not even use "origin" as the default for push). + This branch is not to be rebased (you could do this using custom pre-rebase hook but having a standard "branch property" would make it easy for such a hook to decide. - Do not merge and base your work on this branch -- this is "view only" and unstable (e.g. "pu" in git.git). If we were to do a remote to config reorganization (for that we need a migration plan and a period that we support both), the per-branch configuration should be designed to support at least the commonly asked ones. ``` ## Johannes Schindelin, 2006-04-20 11:41 Subject: Re: Branch metainformation Message-ID: URL: https://gitlist.dev/e/Pine.LNX.4.63.0604201335070.13022%40wbgn013.biozentrum.uni-wuerzburg.de In-Reply-To: <7vwtdkzh1u.fsf@assigned-by-dhcp.cox.net> ``` Hi, On Thu, 20 Apr 2006, Junio C Hamano wrote: > Johannes Schindelin writes: > > > However, this all depends on my (rejected) patch to move the remotes > > information into the config file. > > You seem to keep saying rejected, but IIRC you did not finish it I had another impression: people seemed less than enthusiastic about it. But maybe I misunderstood, and only the automatic rewriting part was disliked. I'll try to find time to clean the patch and resend it... > While we are talking about per branch property, some issues > raised on the list (and #git) recently would be helped by a > convention (and perhaps some core side support) for per-branch > property. Here is a short list. > > + When I am on branch X, I would want "git pull" to pull > (i.e. fetch and merge) from repository Y, not always "origin". > > + When I am on branch X, I would want "git push" to push to > repository Y (we do not even use "origin" as the default for > push). > > + This branch is not to be rebased (you could do this using > custom pre-rebase hook but having a standard "branch property" > would make it easy for such a hook to decide. > > - Do not merge and base your work on this branch -- this is > "view only" and unstable (e.g. "pu" in git.git). > > If we were to do a remote to config reorganization (for that we > need a migration plan and a period that we support both), the > per-branch configuration should be designed to support at least > the commonly asked ones. Hmm. ATM the syntax I use is [remote.company] url = company.com:gits/daproject pull = origin push = master Some bits of your wishes could be written as [branch.pu] rebase = no pull = company Ciao, Dscho ```