Re: Making note, in the repository, of push/pull relationships
On Tue, Aug 16, 2005 at 02:09:08PM -0700, Junio C Hamano wrote: > And presumably you have .git/branches/myremotebranch file that > says something like "master.kernel.org:/pub/scm/git/git.git". > Or should the last line of relationships file be spelled just > push:master:ko-master? Oops, I did intend to add just that to .git/branches/myremotebranch. > > % 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. > > Probably. > > My primary interest in discussing this is to see Porcelain folks > agree on what notation and semantics to use, and probably set an > example by having the minimum base in the barebone Porcelain. This sounds good. > Personally I think there are two kinds of patch-flow: one that > is pretty much static that can easily be described with > something like your relationships notation, and ad-hoc one that > I think should not automatically contaminate the established > static flow your relationships notation nicely describes. The > corporate world may put disproportional stress on the importance > of the former, but my feeling is that ad-hoc patch-flow that is > outside your usual static patch-flow is just as important; see > Documentation/howto/using-topic-branches.txt for why. I don't doubt the utility of these topic branches. In fact, I think it what he's doing with this is great. This is exactly the kind of thing the 'relationships' could help out with. As he creates branches from existing branches, pushes, pulls and merges between them the relationships files would maintain a record of this. Let's say, for example, he made a change on speed-up-spinlocks and merged it to test. Later, a bug is found and he fixes the bug on the speed-up-spinlocks branch. Now, a script could run using the relationships files that could immediately tell that the test branch is behind the speed-up-spinlocks branch and that they should be merged. For someone who has a lot of different things to do this will be valuable. I would leave maintenance of any static work flows up to the porcelains. If a project chose to use some sort of static flow then it can simply populate the relationships files to help drive pushing and pulling if some rogue developer were to use git alone or some other porcelain (thus maintaining compatibility between porcelains). If a porcelain wanted to be very strict about adherance to a static flow then checking the relationships could tell if something 'bad' has been done outside of that porcelain. I hope I'm being clear. Please let me know if something is not clear. Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems 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
Re: Making note, in the repository, of push/pull relationships
Carl Baldwin <[EMAIL PROTECTED]> writes: > 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 And presumably you have .git/branches/myremotebranch file that says something like "master.kernel.org:/pub/scm/git/git.git". Or should the last line of relationships file be spelled just push:master:ko-master? > % 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. Probably. My primary interest in discussing this is to see Porcelain folks agree on what notation and semantics to use, and probably set an example by having the minimum base in the barebone Porcelain. Personally I think there are two kinds of patch-flow: one that is pretty much static that can easily be described with something like your relationships notation, and ad-hoc one that I think should not automatically contaminate the established static flow your relationships notation nicely describes. The corporate world may put disproportional stress on the importance of the former, but my feeling is that ad-hoc patch-flow that is outside your usual static patch-flow is just as important; see Documentation/howto/using-topic-branches.txt for why. - 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
Re: Making note, in the repository, of push/pull relationships
Hi, On Tue, 16 Aug 2005, Carl Baldwin wrote: > So, just a question. What, exactly, is meant by 'cross-pulling'? When I say "cross-pulling" I mean that a branch is pulled from a remote repository, where the named head is called "a", but that reference is pulled into the local branch whose head is "b". Example: --snip-- > git-ls-remote-script junio abe0582207c72ec848e78707577c61a98f5c633drefs/heads/master c506e5687b9257c6182950f245d58cf839abfae4refs/heads/pu 1f40c7c24d999675df818f9d7824937a964f9f40refs/heads/rc 0918385dbd9656cab0d1d81ba7453d49bbc16250refs/tags/junio-gpg-pub d6602ec5194c87b0fc87103ca4d67251c76f233arefs/tags/v0.99 f25a265a342aed6041ab0cc484224d9ca54b6f41refs/tags/v0.99.1 c5db5456ae3b0873fc659c19fafdde22313cc441refs/tags/v0.99.2 7ceca275d047c90c0c7d5afb13ab97efdf51bd6erefs/tags/v0.99.3 b3e9704ecdf48869f635f0aa99ddfb513f885affrefs/tags/v0.99.4 > git-pull-script junio pu:temporary-proposed-updates [...] > echo .git/refs/heads/temporary-proposed-updates c506e5687b9257c6182950f245d58cf839abfae4 --snap-- So, the remote branch "pu" gets cross-pulled to the local branch "temporary-proposed-updates", i.e. to a local branch of a different name. Ciao, Dscho - 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
Re: Making note, in the repository, of push/pull relationships
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 BaldwinSystems 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
Re: Making note, in the repository, of push/pull relationships
On Tue, Aug 16, 2005 at 12:49:33AM +0200, Johannes Schindelin wrote: > Hi, > > On Mon, 15 Aug 2005, Carl Baldwin wrote: > > > Somewhere in the thread something was mentioned about maintaining > > : pairs in the git repository when pushes > > and pulls are performed. I think the argument was actually against > > keeping this information and ultimately against allowing pushes to a > > branch of a different name. > > I think the loudest voice was mine :-) > > Actually, I was not against *keeping* the information, but against > *pulling* in such strange ways. If "cross-pulling" is allowed, I am all > for keeping track of that. So, just a question. What, exactly, is meant by 'cross-pulling'? > In the meantime, I did not think about the issue at all :-) However, as is > often the case in an open discussion, I think I was wrong after all. There > may be cases you want that, and in the end, nobody forces me to use that > feature. > > Anyway, Junio decided to enhance the fetch mechanism to support the > cross-pulling (and also multi-pulling). > > Ciao, > Dscho > -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems 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
Re: Making note, in the repository, of push/pull relationships
Carl Baldwin <[EMAIL PROTECTED]> writes:
> Somewhere in the thread something was mentioned about maintaining
> : pairs in the git repository when pushes
> and pulls are performed. I think the argument was actually against
> keeping this information and ultimately against allowing pushes to a
> branch of a different name.
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.
One proposal which has not been pursued yet, due to lack of time
on my end if anything else, is to have a set of files that is an
extension of current $GIT_DIR/branches/* file (which can record
the URL and optionally one filename under refs/heads/ over there
to mean "which branch to pull from by default"). Instead, the
proposal introduces $GIT_DIR/remotes/* files, whose contents
would look like this:
$ 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
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
to mean "fetch from those three branches on the 'Pull:'
line, fast-forward local ko-master, ko-pu and ko-rc with
these heads".
Then I can see where my private heads and publicly visibile
ones stand to make sure things are in good order. E.g. I
can do "git show-branches ko ko-master rc rc-master".
(2) after doing work in my private repository, push to
master.kernel.org with:
$ git push ko
This does not happen to involve renaming push, because both
ends are owned and controlled by me, but you could put
renaming refspec on "Push:" line in the .git/remotes line
to make it rename.
Note that I am _not_ expecting for "git push/pull/fetch"
commands to dynamically update .git/remotes/ file whenever it
gets a new set of heads and renaming refspecs on the command
line. Explicit refspecs on the command line will just override
what is recorded in .git/remotes/* files instead. So:
$ git push ko pu:refs/heads/testing
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.
-
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
Re: Making note, in the repository, of push/pull relationships
Hi, On Mon, 15 Aug 2005, Carl Baldwin wrote: > Somewhere in the thread something was mentioned about maintaining > : pairs in the git repository when pushes > and pulls are performed. I think the argument was actually against > keeping this information and ultimately against allowing pushes to a > branch of a different name. I think the loudest voice was mine :-) Actually, I was not against *keeping* the information, but against *pulling* in such strange ways. If "cross-pulling" is allowed, I am all for keeping track of that. In the meantime, I did not think about the issue at all :-) However, as is often the case in an open discussion, I think I was wrong after all. There may be cases you want that, and in the end, nobody forces me to use that feature. Anyway, Junio decided to enhance the fetch mechanism to support the cross-pulling (and also multi-pulling). Ciao, Dscho - 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
Making note, in the repository, of push/pull relationships
(Sorry for the repost. The other one was an accident.) Over the week-end, I was thinking about the thread "Re: How is working on arbitrary remote heads supposed to work in Cogito". I wanted to weigh in an opinion that I've developed on it but thought it deserved a new thread. Somewhere in the thread something was mentioned about maintaining : pairs in the git repository when pushes and pulls are performed. I think the argument was actually against keeping this information and ultimately against allowing pushes to a branch of a different name. I wanted to weigh in with why it would be a good idea to make note of this information. The only thing that would be required of the plumbing is to specify how this information is kept and if a push or pull is performed directly with git then make note of the push/pull relationship. Everything else would be up to the porcelains. So, I envision a simple directed graph where nodes represent the branches (wether local or remote) and the edges represent push or pull relationships between branches. Git already stores the nodes. The edges, in theory, would spring into existence when a push or pull is performed between two branches for the first time. This graph will be extremely useful for manageing flow in a project. It could enable something as simple as a script that would walk the edges and tell which ones have fallen behind. It would also be possible to easily pull up a visual representation of the graph (with graphviz, maybe). This sort of thing might prove to be a valuable orientation tool for the developer or project manager. It could also enable some very powerful project flow management --- in a porcelain of course --- that would manage flow from an engineer's own sand-box through software engineering 'gates' such as integration, quality assurance, product maintenance and the documentation and sign-offs required to pass through each of these gates. It could also be used to aid in documenting and managing the, already existent, linux tree development flow in whatever way suits. This is a big return on investment. Little would be required of the plumbing to maintain these 'edges', just add to them when it performs a push/pull on an edge that hasn't already been recorded. Any changes or deletions could be handled by the user or by some porcelain. I think it is important, though, to specify how this information should be stored to maintain compatibility between porcelains while (hopefully) allowing for some degree of flexibility. I don't yet know where this line should be drawn. Carl -- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Carl BaldwinSystems 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
