threads / discuss / 3927

Branch metainformation

Subject: Branch metainformation

## tl;dr

4 messages between Apr 20, 2006 and Apr 20, 2006.

replies: 3people: 3as markdown or json

Jakub Narebski· Apr 20, 2006, 07:39 UTC · lore

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· Apr 20, 2006, 09:37 UTC · re: Jakub Narebski · lore

Re: Branch metainformation

Hi,

On Thu, 20 Apr 2006, Jakub Narebski wrote:

Show 10 quoted lines

> 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 <nick>", 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· Apr 20, 2006, 10:18 UTC · re: Johannes Schindelin · lore

Re: Branch metainformation

Johannes Schindelin <Johannes.Schindelin@gmx.de> 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· Apr 20, 2006, 11:41 UTC · re: Junio C Hamano · lore

Re: Branch metainformation

Hi,

On Thu, 20 Apr 2006, Junio C Hamano wrote:

Show 6 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> 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...

Show 23 quoted lines

> 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