2006/10/17, Junio C Hamano <junkio@xxxxxxx>:
[...]
You have an upstream repository that has more than one branches
you are interested in, say "master" and "next". And you work on
top of both of them, so you have two branches of your own that
correspond to them.
So you organize your remote section perhaps like this:
[remote."origin"]
url = git://git.k.o/.../git.git/
fetch = refs/heads/master:refs/remotes/origin/master
fetch = refs/heads/next:refs/remotes/origin/next
fetch = +refs/heads/pu:refs/remotes/origin/pu
[branch."master"]
remote = origin
merge = refs/heads/master
[branch."next"]
remote = origin
merge = refs/heads/next
That is, your refs/heads/master corresponds to upstream's master
branch and your next corresponds to upstream's next branch.
When you are on your "master" you would merge changes made to
upstream's master into it with "git pull".
Yes, that is.
By the way, could you add descriptions on remote.* to
Documentation/config.txt?
I'll try. Off-topic: Do you want also docs for the ^@ notation and an
implementation in git-rev-parse?
After doing a "git pull" while on your "master" and finishing
working on your "master", you might switch to your "next". At
that point, if you want to merge upstream changes without
re-fetching, you can do either of the following:
git pull . remotes/origin/next
git pull --local
(the former can be "git pull" if "branch.next.remote=.").
I think this is the point of your two patches, and in that
sense, the --local one makes "branch.remote=." patch
unnecessary.
I see them differently. "branch.remote=." is when there is no upstream
(e.g., for your next and master branches in git.git).
While these save typing on "git pull", two things bother me.
* the tool is not helping you decide if you can get away
without re-fetching. you need to remember that (1) you
fetched from the upstream to update "master" recently _and_
(2) because of your [remote."origin"] configuration your
remotes/origin/next was updated while you pulled into your
"master".
You never know if you can get away without re-fetching (or I don't
parse this sentence :). The way I see it, you always us "git pull"
except when you want to merge the exactly the already fetch branch
because (1) you want to merge the same upstream as with other branch
(2) you don't have access to the remote repository (3)...
* while the workflow assumes that one local branch is tied
closely to one remote branch (in this example, tracked under
remotes/origin), the rest of the tools do not take advantage
of that assumption to help you decide what to do next.
This is the next item in my TODO :)
Next with a program similar to "svn info" showing misc info about a branch.
For example, if each of your local branch is tied closely to one
remote branch, you should be able to "git fetch" to update the
tracking branches and then ask:
- what changes are in remote that I haven't merged?
- what happens when I pull --local right now?
- what changes if any are in mine alone missing from remote?
- can I push to remote right now (i.e. would it fast-forward)?
- how fresh is the tracking branch that corresponds to my
current branch?
Right now, these require you to spell out the name of the
tracking branch. Assuming you are on your "next" branch:
git log ..remotes/origin/next
git log remotes/origin/next..
git log remotes/origin/next...next [*1*]
git show-branch remotes/origin/next next
tail -n 1 .git/logs/remotes/origin/next
would be the ways to ask the above questions (and the last one
is unreadable unless you can do strptime in your head).
Maybe we can introduce a new extended SHA-1 notation to mean
"the tracking branch this branch usually merges from". Then we
can say:
git log ..^
git log ^..
git log ^...
git show-branch ^ next
I am not sure '^' is syntactically viable, but hopefully you get
the idea.
I get it. Another idea is to have a .git/ORIGIN that points to the
tracking branch so you could say:
git log ..ORIGIN
git log ORIGIN..
git log ORIGIN...
git show-branch ORIGIN next
One advantage is that it only needs changes to "git checkout" (and
possibly others but not to plumbing ones).
Another is that the ^ notation forces the low level tools to follow
configs in [branch."..."] and [remote."..."].
[*1*] While three-dots symmetric difference is a nice addition
made recently, I often find it irritating that the output does
not tell which branch each of the commit is reachable from, and
end up running show-branch, which does. Would anybody have a
clever idea to fix this cleanly?
I don't know if it is a clever idea but...
We could use the git-name-rev method:
$git log a...b
commit sha1 (a)
....
commit sha1 (a^)
....
commit sha1 (b^)
....
commit sha1 (b)
....
and without this when on both branches.
Santi
-
To unsubscribe from this list: 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