Branch metainformation

Branch metainformation

[Jakub Narebski]

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

Re: Branch metainformation

[Johannes Schindelin]

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 <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

Re: Branch metainformation

[Junio C Hamano]

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.

Re: Branch metainformation

[Johannes Schindelin]

Hi,

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

> 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...

> 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