Hello!
This is not a ready-to-use proposal, but I think my message can prompt
useful changes in GIT or in the "porcelain".
Let's see how remote changes end up in the head branch of the local
repository (sorry for possible mistakes in terminology):
branch in "remote" local index,
a remote -------> branch -------> branch ------> tree
repository (e.g. origin) (e.g. master)
Brought in sync by:
fetch merge checkout
Relationship stored in:
.git/remotes nowhere!!! .git/HEAD
If I fetch a remote branch, git knows where to get changes. If I change
the current branch, git remembers that. But git doesn't remember the
relationship between branches mirroring the remote branches and branches
used for local development.
There are situations when I want to work for a significant time on a
certain branch. Significant time means that changes are made by
others, and I'm supposed to integrate them and make more changes. Yet I
may want to take advantage of some patches from another team that uses
the other repository.
I want GIT and porcelains work the same way if I'm working with
repository 1 or repository 2. As it stands now, git gives preferential
treatment to the "origin" branch. Whatever branch I'm on, "git-pull"
will pull from "origin". I believe the special role of the "origin"
branch should be reduced to cg-clone and similar commands.
I think it would be convenient to have git remember the remote branch
for the given local branch. git should know that if HEAD points to
"local-B", "git-fetch" should fetch from "remote-B", not from "origin".
To implement this, git would have to implement attributes for local
branches (other ideas are welcome). Currently, there are no attributes
for local branches other than the top SHA1 in .git/refs/heads/
Once at the topic of branch attributes, let's see what else could be
useful? I think that would be the creator of the branch and the comment
(e.g. "this is for tested commits only, to be merged tomorrow" etc).
Where can this data be stored? Probably in blobs pointed to by refs in
e.g. .git/refs/branch-data/ or just in plain files e.g.
under .git/branch-data/
I know, it sounds like a lot of work to save a few keystrokes. But I
think it may be worth it. Working on different branches should have the
same "look and feel". Otherwise, git would repeat a design error of
CVS, where the head branch was given preference e.g. for date based
updates.
I'm sorry, reading this mailing list is beyond my capabilities, so
certain overlaps with other postings may be expected, unless I'm
suggesting something totally off-base :-)
--
Regards,
Pavel Roskin
-
: 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