Re: Branch metainformation

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


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

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]