On Mon, Aug 15, 2005 at 05:18:43PM -0700, Junio C Hamano wrote:
> If you are referring to what I said about the user having some
> control over both ends hence it should be possible to arrange to
> use the same name on both ends to reduce mental burden, Pasky
> and others convinced me otherwise during later discussions, and
> the current core knows how to do renaming pushes.
I wasn't referring to any particular post just a general idea that came
up in the thread. I wanted a starting point to present my thoughts. :-)
> $ cat .git/remotes/ko
> URL: master.kernel.org:/pub/scm/git/git.git/
> Push: master pu rc
> Pull: master:ko-master pu:ko-pu rc:ko-rc
This is very close to what I was getting at. It records each branch
involved and wether the relationship is push or pull (or possibly both).
If I may, let me give an example of something I think could serve the
purpose a little more simply and generically.
Let's say I start with the following:
% ls .git/refs/heads
master
mylocalbranch
myremotebranch
ko-master
% cat .git/branches/ko-master
master.kernel.org:/pub/scm/git/git.git
I would add something like this: (I didn't put much thought into the
actual directory and file names, forgive me. ;-)
% cat .git/branches/relationships
pull:ko-master:master
pull:master:mylocalbranch # The next two document my flow locally
pull:mylocalbranch:master
push:master:myremotebranch # I push my master to a remote that I control
_OR_
% ls .git/relationships/*
pull:ko-master:master
pull:master:mylocalbranch
pull:mylocalbranch:master
push:master:myremotebranch
I think this is flexible and could easily support the workflow that you
present below. You could do the following as a convenience in using
fetch in addition to what I suggest above.
% cat .git/remotes/ko
push: master:ko-master pu:ko-pu rc:ko-rc
pull: ko-master:master ko-pu:pu ko-rc:rc
I might argue that this is now a job for a porcelain script or
something.
With the addition of the simple relationships file a complete graph of
your workflow could derived. There is no assumption on what the
workflow is nor if the branches are local or remote. This work flow can
be arbitrarily simple or complex but further complexity can and should
be handled in the porcelains.
> The expected workflow with the above example "remotes" file is
> for me to be able to do this:
>
> (1) fetch from master.kernel.org (that is the source of the
> mirroring for everybody to see on {www,rsync}.kernel.org)
> before starting my day. The current "git fetch" does not
> do this, but make it:
>
> $ git fetch ko
This is still doable. As is this...
> (2) after doing work in my private repository, push to
> master.kernel.org with:
>
> $ git push ko
>
> Note that I am _not_ expecting for "git push/pull/fetch"
> commands to dynamically update .git/remotes/ file whenever it
So, with the way I suggest splitting up refspecs and 'relationships' I
_would_ suggest dynamically adding to (but not deleting from) the
relationships file. But, I agree with you about the refspec. I think
this should be 100% supplied by the user or porcelain.
Adding relationships dynamically will be a good way to document whatever
flow is being used. Also, the savy user can periodically check the file
(or a porcelain with a pretty interface could do something intelligent
with it) to see how his work flow has evolved. He can also
delete relationships that are no longer needed if he is a clean-freak
like me ;-)
I really think there is some good common ground here. Let's keep going
with this. I actually have an idea brewing up for a porcelain to handle
work-flow in a tightly-knit corporate type development environment.
Hey, I've enjoyed the discussion. I hope to make a valuable
contribution to git. I think it has incredible potential.
Cheers,
Carl
> would not push usual "master pu rc" but create a new "testing"
> branch there, starting at the commit which is the head commit of
> the local "pu" branch. This is a one-shot override, so next
> time around, "git push ko" will do the usual three heads that is
> recorded in the .git/remotes/ko file.
>
>
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Carl Baldwin Systems VLSI Laboratory
Hewlett Packard Company
MS 88 work: 970 898-1523
3404 E. Harmony Rd. work: [EMAIL PROTECTED]
Fort Collins, CO 80525 home: [EMAIL PROTECTED]
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
