[asdf-devel] Question about git
How are we supposed to be reasoning about the multiple git repositories out there? I have been pulling from the master/public one and then working locally. Fare works on his personal working copy. When I make a patch on mine, based on public, seems like I sometimes end up with patches that Fare can't apply cleanly to his. How are we supposed to handle this? Thanks, r
From: Robert Goldman <rpgoldman@sift.info>
How are we supposed to be reasoning about the multiple git repositories out there?
I have been pulling from the master/public one and then working locally.
Fare works on his personal working copy.
When I make a patch on mine, based on public, seems like I sometimes end up with patches that Fare can't apply cleanly to his.
How are we supposed to handle this?
Well, there's no magic allowing to automatically compose changes that were concurrently made in the same area -- you have to merge them manually. Why wouldn't you work off the top of the Fare's tree? regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On 1/27/10 Jan 27 -9:34 AM, Samium Gromoff wrote:
From: Robert Goldman <rpgoldman@sift.info>
How are we supposed to be reasoning about the multiple git repositories out there?
I have been pulling from the master/public one and then working locally.
Fare works on his personal working copy.
When I make a patch on mine, based on public, seems like I sometimes end up with patches that Fare can't apply cleanly to his.
How are we supposed to handle this?
Well, there's no magic allowing to automatically compose changes that were concurrently made in the same area -- you have to merge them manually.
Why wouldn't you work off the top of the Fare's tree?
I dunno. I guess I could. But what's the point of having the shared repo then? Why shouldn't we just have Fare's tree with one "released" and one "devel" branch? Or why shouldn't Fare work on the shared repo directly, but on a branch? What are we gaining, besides confusion, by having two repos? Thanks, r
From: Robert Goldman <rpgoldman@sift.info>
On 1/27/10 Jan 27 -9:34 AM, Samium Gromoff wrote:
From: Robert Goldman <rpgoldman@sift.info>
How are we supposed to be reasoning about the multiple git repositories out there?
I have been pulling from the master/public one and then working locally.
Fare works on his personal working copy.
When I make a patch on mine, based on public, seems like I sometimes end up with patches that Fare can't apply cleanly to his.
How are we supposed to handle this?
Well, there's no magic allowing to automatically compose changes that were concurrently made in the same area -- you have to merge them manually.
Why wouldn't you work off the top of the Fare's tree?
I dunno. I guess I could. But what's the point of having the shared repo then? Why shouldn't we just have Fare's tree with one "released" and one "devel" branch? Or why shouldn't Fare work on the shared repo directly, but on a branch? What are we gaining, besides confusion, by having two repos?
I guess it's just easier for him to commit to his tree, as well as it simplifies testing for others -- they just pull from a different repository, not having to care about switching the branch. Also, my suggestion was about economic sense: if you have a moving devel branch, which is likely to go upstream, it makes sense to begin making changes off that, rather than off something in the past -- you basically get merging for free. This doesn't have anything to do with one vs. two repositories -- rather, this is pertinent to any situation with two branches -- 'release' and 'devel'. regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On 1/27/10 Jan 27 -3:36 PM, Samium Gromoff wrote:
From: Robert Goldman <rpgoldman@sift.info>
On 1/27/10 Jan 27 -9:34 AM, Samium Gromoff wrote:
From: Robert Goldman <rpgoldman@sift.info>
How are we supposed to be reasoning about the multiple git repositories out there?
I have been pulling from the master/public one and then working locally.
Fare works on his personal working copy.
When I make a patch on mine, based on public, seems like I sometimes end up with patches that Fare can't apply cleanly to his.
How are we supposed to handle this?
Well, there's no magic allowing to automatically compose changes that were concurrently made in the same area -- you have to merge them manually.
Why wouldn't you work off the top of the Fare's tree?
I dunno. I guess I could. But what's the point of having the shared repo then? Why shouldn't we just have Fare's tree with one "released" and one "devel" branch? Or why shouldn't Fare work on the shared repo directly, but on a branch? What are we gaining, besides confusion, by having two repos?
I guess it's just easier for him to commit to his tree, as well as it simplifies testing for others -- they just pull from a different repository, not having to care about switching the branch.
I guess I still don't get it. So now I have to have either two or three remotes, right? The canonical public repo, Fare's public repo, and possibly my own public repo, if I want to publish my own current state. This seems like a Babel of states for me to track. What's the standard practice here? I bet there's a sort of standard operating procedure for doing this kind of thing, but I'm not sure what that procedure is. thanks, r
On 2010/01/27, at 22:47 , Robert Goldman wrote:
On 1/27/10 Jan 27 -3:36 PM, Samium Gromoff wrote:
From: Robert Goldman <rpgoldman@sift.info>
On 1/27/10 Jan 27 -9:34 AM, Samium Gromoff wrote:
From: Robert Goldman <rpgoldman@sift.info>
How are we supposed to be reasoning about the multiple git repositories out there?
I have been pulling from the master/public one and then working locally.
Fare works on his personal working copy.
When I make a patch on mine, based on public, seems like I sometimes end up with patches that Fare can't apply cleanly to his.
How are we supposed to handle this?
Well, there's no magic allowing to automatically compose changes that were concurrently made in the same area -- you have to merge them manually.
Why wouldn't you work off the top of the Fare's tree?
I dunno. I guess I could. But what's the point of having the shared repo then? Why shouldn't we just have Fare's tree with one "released" and one "devel" branch? Or why shouldn't Fare work on the shared repo directly, but on a branch? What are we gaining, besides confusion, by having two repos?
I guess it's just easier for him to commit to his tree, as well as it simplifies testing for others -- they just pull from a different repository, not having to care about switching the branch.
I guess I still don't get it. So now I have to have either two or three remotes, right? The canonical public repo, Fare's public repo, and possibly my own public repo, if I want to publish my own current state.
This seems like a Babel of states for me to track. What's the standard practice here?
I bet there's a sort of standard operating procedure for doing this kind of thing, but I'm not sure what that procedure is.
You can think of a repository as a sequence of patches. Having different repositories is having different sequences of patches. When you only have one repository, when you commit you have only one patch to merge, so it is usually trivial (ie. automatic) or easy to merge it in. When you have several patches to commit, then things become more complex. Notice that your successive patches are made against the sources patched by the previous ones. If during the merge with the repository these previous patches had to be modified, the subsequent patches may have to be too. So merging two repositories is more complex than working with only one, in the situations where the patches collide. Fortunately, in big software systems as we work on nowadays, it doesn't occur too often (ie. you may be working on the driver modules in one repository and in the kernel memory system in the other, and when you have to merge the two repositories, all the patches are disjoints). Of course, if you both are working on the same parts of ADSL, it's not a good idea to work off different repositories, or the merge task will be daunting. -- __Pascal Bourguignon__ http://www.informatimago.com
From: "Pascal J. Bourguignon" <pjb@informatimago.com>
You can think of a repository as a sequence of patches.
Here and throughout the message you confuse repositories and branches -- branches are sequences of patches, not repositories.
Having different repositories is having different sequences of patches.
When you only have one repository, when you commit you have only one patch to merge, so it is usually trivial (ie. automatic) or easy to merge it in.
When you have several patches to commit, then things become more complex. Notice that your successive patches are made against the sources patched by the previous ones. If during the merge with the repository these previous patches had to be modified, the subsequent patches may have to be too.
So merging two repositories is more complex than working with only one, in the situations where the patches collide.
Fortunately, in big software systems as we work on nowadays, it doesn't occur too often (ie. you may be working on the driver modules in one repository and in the kernel memory system in the other, and when you have to merge the two repositories, all the patches are disjoints).
Of course, if you both are working on the same parts of ADSL, it's not a good idea to work off different repositories, or the merge task will be daunting.
You still can work in different repositories (and, ergo, different branches), just sync the branches often, in both directions, and always work off the latest changes -- this is semantically equivalent to working on a single branch in a centralised repository. Of course this adds the two-way sync overhead. regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On 1/28/10 Jan 28 -6:53 AM, Pascal J. Bourguignon wrote:
On 2010/01/27, at 22:47 , Robert Goldman wrote:
On 1/27/10 Jan 27 -3:36 PM, Samium Gromoff wrote:
From: Robert Goldman <rpgoldman@sift.info>
On 1/27/10 Jan 27 -9:34 AM, Samium Gromoff wrote:
From: Robert Goldman <rpgoldman@sift.info>
How are we supposed to be reasoning about the multiple git repositories out there?
I have been pulling from the master/public one and then working locally.
Fare works on his personal working copy.
When I make a patch on mine, based on public, seems like I sometimes end up with patches that Fare can't apply cleanly to his.
How are we supposed to handle this?
Well, there's no magic allowing to automatically compose changes that were concurrently made in the same area -- you have to merge them manually.
Why wouldn't you work off the top of the Fare's tree?
I dunno. I guess I could. But what's the point of having the shared repo then? Why shouldn't we just have Fare's tree with one "released" and one "devel" branch? Or why shouldn't Fare work on the shared repo directly, but on a branch? What are we gaining, besides confusion, by having two repos?
I guess it's just easier for him to commit to his tree, as well as it simplifies testing for others -- they just pull from a different repository, not having to care about switching the branch.
I guess I still don't get it. So now I have to have either two or three remotes, right? The canonical public repo, Fare's public repo, and possibly my own public repo, if I want to publish my own current state.
This seems like a Babel of states for me to track. What's the standard practice here?
I bet there's a sort of standard operating procedure for doing this kind of thing, but I'm not sure what that procedure is.
You can think of a repository as a sequence of patches.
Having different repositories is having different sequences of patches.
When you only have one repository, when you commit you have only one patch to merge, so it is usually trivial (ie. automatic) or easy to merge it in.
When you have several patches to commit, then things become more complex. Notice that your successive patches are made against the sources patched by the previous ones. If during the merge with the repository these previous patches had to be modified, the subsequent patches may have to be too.
So merging two repositories is more complex than working with only one, in the situations where the patches collide.
Fortunately, in big software systems as we work on nowadays, it doesn't occur too often (ie. you may be working on the driver modules in one repository and in the kernel memory system in the other, and when you have to merge the two repositories, all the patches are disjoints).
Of course, if you both are working on the same parts of ADSL, it's not a good idea to work off different repositories, or the merge task will be daunting.
Currently, since ASDF lives pretty much in a single .lisp file, the merge task may be daunting. Suggestion: let's develop a proposed work method for people who want to develop for ASDF. It seems like this proposed work method should specify at least: 1. What repository do you pull from? 2. How do you provide fixes? Are you expected to provide your own public git repository (I would /not/ favor this alternative --- raises the bar too high) or are you supposed to use git-format-patch/git-email? 3. If we are to prepare patches, we should provide a recipe for preparing them (i.e., do /these/ git commands, including how to bring your repo into harmony with the designated public repo). 4. Should the public repository be modified to have a stable and a development branch? I sorta prefer the idea that we should have a stable and development branch on the main repo and prepare patches against the development branch, rather than having to synchronize myself with both the public repo and Fare's. 4.a. Note that I am not wedded to the public repo --- if we were to move to synchronizing against Fare's that would be fine with me. But I think there are two reasons to prefer moving Fare's development branch to the public repo, instead of syncing with Fare's: (1) stability --- ASDF development has been chaotic already and switching repositories seems like yet more confusion; (2) the public one permits access from multiple people in case of emergency as in, e.g., Fare gets abducted by aliens, or gets born again and will program only in Visual Basic. 5. We should provide an explanation of how to interact with both stable and development remotely. Cheers, r
Using a development branch on the public repo sounds alright to me. I started my repo before I had the commit bit on the public repo, which is what got me started historically. I didn't change my workflow just because I've been too lazy to learn how to do it so far. If someone will point me to a document that explains how to properly use branched development with git, I will gladly do it (as it seems to be the consensus that we should be using branches in the main public repo). [ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] There is joy in work. There is no happiness except in the realization that we have accomplished something. — Henry Ford 2010/1/28 Robert Goldman <rpgoldman@sift.info>:
On 1/28/10 Jan 28 -6:53 AM, Pascal J. Bourguignon wrote:
On 2010/01/27, at 22:47 , Robert Goldman wrote:
On 1/27/10 Jan 27 -3:36 PM, Samium Gromoff wrote:
From: Robert Goldman <rpgoldman@sift.info>
On 1/27/10 Jan 27 -9:34 AM, Samium Gromoff wrote:
From: Robert Goldman <rpgoldman@sift.info> > How are we supposed to be reasoning about the multiple git > repositories > out there? > > I have been pulling from the master/public one and then working > locally. > > Fare works on his personal working copy. > > When I make a patch on mine, based on public, seems like I > sometimes end > up with patches that Fare can't apply cleanly to his. > > How are we supposed to handle this?
Well, there's no magic allowing to automatically compose changes that were concurrently made in the same area -- you have to merge them manually.
Why wouldn't you work off the top of the Fare's tree?
I dunno. I guess I could. But what's the point of having the shared repo then? Why shouldn't we just have Fare's tree with one "released" and one "devel" branch? Or why shouldn't Fare work on the shared repo directly, but on a branch? What are we gaining, besides confusion, by having two repos?
I guess it's just easier for him to commit to his tree, as well as it simplifies testing for others -- they just pull from a different repository, not having to care about switching the branch.
I guess I still don't get it. So now I have to have either two or three remotes, right? The canonical public repo, Fare's public repo, and possibly my own public repo, if I want to publish my own current state.
This seems like a Babel of states for me to track. What's the standard practice here?
I bet there's a sort of standard operating procedure for doing this kind of thing, but I'm not sure what that procedure is.
You can think of a repository as a sequence of patches.
Having different repositories is having different sequences of patches.
When you only have one repository, when you commit you have only one patch to merge, so it is usually trivial (ie. automatic) or easy to merge it in.
When you have several patches to commit, then things become more complex. Notice that your successive patches are made against the sources patched by the previous ones. If during the merge with the repository these previous patches had to be modified, the subsequent patches may have to be too.
So merging two repositories is more complex than working with only one, in the situations where the patches collide.
Fortunately, in big software systems as we work on nowadays, it doesn't occur too often (ie. you may be working on the driver modules in one repository and in the kernel memory system in the other, and when you have to merge the two repositories, all the patches are disjoints).
Of course, if you both are working on the same parts of ADSL, it's not a good idea to work off different repositories, or the merge task will be daunting.
Currently, since ASDF lives pretty much in a single .lisp file, the merge task may be daunting.
Suggestion: let's develop a proposed work method for people who want to develop for ASDF. It seems like this proposed work method should specify at least:
1. What repository do you pull from?
2. How do you provide fixes? Are you expected to provide your own public git repository (I would /not/ favor this alternative --- raises the bar too high) or are you supposed to use git-format-patch/git-email?
3. If we are to prepare patches, we should provide a recipe for preparing them (i.e., do /these/ git commands, including how to bring your repo into harmony with the designated public repo).
4. Should the public repository be modified to have a stable and a development branch? I sorta prefer the idea that we should have a stable and development branch on the main repo and prepare patches against the development branch, rather than having to synchronize myself with both the public repo and Fare's.
4.a. Note that I am not wedded to the public repo --- if we were to move to synchronizing against Fare's that would be fine with me. But I think there are two reasons to prefer moving Fare's development branch to the public repo, instead of syncing with Fare's: (1) stability --- ASDF development has been chaotic already and switching repositories seems like yet more confusion; (2) the public one permits access from multiple people in case of emergency as in, e.g., Fare gets abducted by aliens, or gets born again and will program only in Visual Basic.
5. We should provide an explanation of how to interact with both stable and development remotely.
Cheers, r
On 1/28/10 Jan 28 -11:48 AM, Faré wrote:
Using a development branch on the public repo sounds alright to me. I started my repo before I had the commit bit on the public repo, which is what got me started historically. I didn't change my workflow just because I've been too lazy to learn how to do it so far.
If someone will point me to a document that explains how to properly use branched development with git, I will gladly do it (as it seems to be the consensus that we should be using branches in the main public repo).
The source I've been using so far is http://progit.org/book/, the apress book /Pro Git/. Specifically, there's the distributed Git chapter: http://progit.org/book/ch5-0.html There isn't a workflow in there that seems to perfectly reflect what we've been doing with ASDF, but maybe we can find one that works. Here's a single-user policy for git branches: http://www.newartisans.com/2009/10/branch-policies-with-git.html I'm not dead sure how to turn that into a distributed use case; maybe someone has a better source for that. I need to go wrestle with figuring out how to manage multiple remotes in my git repo.... Best, r
[ François-René ÐVB Rideau | Reflection&Cybernethics | http://fare.tunes.org ] There is joy in work. There is no happiness except in the realization that we have accomplished something. — Henry Ford
2010/1/28 Robert Goldman <rpgoldman@sift.info>:
On 1/28/10 Jan 28 -6:53 AM, Pascal J. Bourguignon wrote:
On 2010/01/27, at 22:47 , Robert Goldman wrote:
On 1/27/10 Jan 27 -3:36 PM, Samium Gromoff wrote:
From: Robert Goldman <rpgoldman@sift.info>
On 1/27/10 Jan 27 -9:34 AM, Samium Gromoff wrote: > From: Robert Goldman <rpgoldman@sift.info> >> How are we supposed to be reasoning about the multiple git >> repositories >> out there? >> >> I have been pulling from the master/public one and then working >> locally. >> >> Fare works on his personal working copy. >> >> When I make a patch on mine, based on public, seems like I >> sometimes end >> up with patches that Fare can't apply cleanly to his. >> >> How are we supposed to handle this? > > Well, there's no magic allowing to automatically compose changes that > were concurrently made in the same area -- you have to merge them > manually. > > Why wouldn't you work off the top of the Fare's tree?
I dunno. I guess I could. But what's the point of having the shared repo then? Why shouldn't we just have Fare's tree with one "released" and one "devel" branch? Or why shouldn't Fare work on the shared repo directly, but on a branch? What are we gaining, besides confusion, by having two repos?
I guess it's just easier for him to commit to his tree, as well as it simplifies testing for others -- they just pull from a different repository, not having to care about switching the branch.
I guess I still don't get it. So now I have to have either two or three remotes, right? The canonical public repo, Fare's public repo, and possibly my own public repo, if I want to publish my own current state.
This seems like a Babel of states for me to track. What's the standard practice here?
I bet there's a sort of standard operating procedure for doing this kind of thing, but I'm not sure what that procedure is.
You can think of a repository as a sequence of patches.
Having different repositories is having different sequences of patches.
When you only have one repository, when you commit you have only one patch to merge, so it is usually trivial (ie. automatic) or easy to merge it in.
When you have several patches to commit, then things become more complex. Notice that your successive patches are made against the sources patched by the previous ones. If during the merge with the repository these previous patches had to be modified, the subsequent patches may have to be too.
So merging two repositories is more complex than working with only one, in the situations where the patches collide.
Fortunately, in big software systems as we work on nowadays, it doesn't occur too often (ie. you may be working on the driver modules in one repository and in the kernel memory system in the other, and when you have to merge the two repositories, all the patches are disjoints).
Of course, if you both are working on the same parts of ADSL, it's not a good idea to work off different repositories, or the merge task will be daunting.
Currently, since ASDF lives pretty much in a single .lisp file, the merge task may be daunting.
Suggestion: let's develop a proposed work method for people who want to develop for ASDF. It seems like this proposed work method should specify at least:
1. What repository do you pull from?
2. How do you provide fixes? Are you expected to provide your own public git repository (I would /not/ favor this alternative --- raises the bar too high) or are you supposed to use git-format-patch/git-email?
3. If we are to prepare patches, we should provide a recipe for preparing them (i.e., do /these/ git commands, including how to bring your repo into harmony with the designated public repo).
4. Should the public repository be modified to have a stable and a development branch? I sorta prefer the idea that we should have a stable and development branch on the main repo and prepare patches against the development branch, rather than having to synchronize myself with both the public repo and Fare's.
4.a. Note that I am not wedded to the public repo --- if we were to move to synchronizing against Fare's that would be fine with me. But I think there are two reasons to prefer moving Fare's development branch to the public repo, instead of syncing with Fare's: (1) stability --- ASDF development has been chaotic already and switching repositories seems like yet more confusion; (2) the public one permits access from multiple people in case of emergency as in, e.g., Fare gets abducted by aliens, or gets born again and will program only in Visual Basic.
5. We should provide an explanation of how to interact with both stable and development remotely.
Cheers, r
Using a development branch on the public repo sounds alright to me. I started my repo before I had the commit bit on the public repo, which is what got me started historically. I didn't change my workflow just because I've been too lazy to learn how to do it so far.
If someone will point me to a document that explains how to properly use branched development with git, I will gladly do it (as it seems to be the consensus that we should be using branches in the main public repo).
The basic idea is simple: # git fetch <repo-name> # gets all the branches # git checkout -b <branch-name> <repo-name>/<branch-name> ## ## update # git fetch <repo-name> ## check what changed, then fast-forward onto it # gitk # git rebase <repo-name>/<branch-name> ## do some work, the commit to that branch # git push <repo-name> <branch-name> Depending on your work flow, you may not need to specify <repo-name> or <branch-name> in some of the commands above. You may also want to specify --track or drop the -b during the checkout. As always, learn/practice on a couple local repos (safe) before messing up a public one (embarrassing). FWIW, its been my experience that tracking another repository isn't much harder than using different branches in a single repository. ## separate repos # git clone <asdf url> # git remote add fahree <Faré's url> # git fetch # git fetch fahree # git checkout -b fahree fahree/master ... ## branches in single repo # git clone <asdf url> # git fetch # git checkout -b fahree fahree/master All the differences are in initialization and fetching, so the above example shows the maximum change in workload. In particular, merge issues are identical in either case; as with any version-control system, people need to coordinate which branch/repo they are working on. Of note, if RPG and I were sending merge requests rather than individual patches, Faré wouldn't be seeing as many conflicts. Instead, git would be using history to better auto-resolve things. To me, a more interesting question is whether people might find a site like github or gitorious to be helpful. Such sites have systems for making and auto-tracking forks, submitting merge requests, administering commit bits, etc. Github is more individual-oriented; Gitorious has a more team-oriented focus. Theoretically, gitorious could even be installed on cl.net. - Daniel
From: dherring@tentpost.com
To me, a more interesting question is whether people might find a site like github or gitorious to be helpful. Such sites have systems for making and auto-tracking forks, submitting merge requests, administering commit bits, etc. Github is more individual-oriented; Gitorious has a more team-oriented focus. Theoretically, gitorious could even be installed on cl.net.
To me, such a thing definitely screams of potential. We need as much integration as we can get. Now, the question is, who would feel like participating in definition and maintenance of such a structure.. regards, Samium Gromoff -- _deepfire-at-feelingofgreen.ru O< ascii ribbon campaign - stop html mail - www.asciiribbon.org
On 1/30/10 Jan 30 -7:08 PM, Samium Gromoff wrote:
From: dherring@tentpost.com
To me, a more interesting question is whether people might find a site like github or gitorious to be helpful. Such sites have systems for making and auto-tracking forks, submitting merge requests, administering commit bits, etc. Github is more individual-oriented; Gitorious has a more team-oriented focus. Theoretically, gitorious could even be installed on cl.net.
To me, such a thing definitely screams of potential.
We need as much integration as we can get.
Now, the question is, who would feel like participating in definition and maintenance of such a structure..
Um, with all due respect, I'd prefer not. The switch to git has already sucked a lot of cycles away from development for me. Maybe CVS sucked, but it didn't take any of my time to learn it (sunk cost), and it did all I needed to have done. I'd really prefer that we /simplify/ the process of developing ASDF so that I can spend more time on that and less time fighting what's supposed to be a tool. It seems like you all are saying that the solution is to add /more/ git, more forking, more administration. All of the items in that email "Such sites have systems for making and auto-tracking forks, submitting merge requests, administering commit bits, etc." all seem to be opportunities to have systems that will help make our lives more complicated, not easier. Isn't all this forking wild overkill for ASDF? OK, if you're developing the linux kernel and drivers, yes, you might have a very long-lived branch to develop or restructure a file system or something. But ASDF is really, essentially, a single file. You can't have a long-lived fork in a single file without horrible problems merging. I don't care how great your version control system is, down at the bottom, what you've got is diff, and diff is not that great a tool. Similarly, given the size of the ASDF developer community, is it really worth it to invest in a tool that will administer the commit bit? Is there any chance we'd recoup the tool investment in labor savings? As far as I can tell, a development model where you pull the head, start a local branch, fix something on your local branch, submit the patch to Fare, and then kill your branch, is all anyone is going to need or want. [Well, I suppose if you're responsible for a lisp implementation, you might want a persistent branch to keep specific add-ons, but even that doesn't work terribly well in a one-file system.] Until we know exactly what we'll get --- and not what we'll get with respect to cool features, but what we'll get with respect to features we might actually use in ASDF development and maintenance --- I think we need to keep a very careful eye on the cost/benefit tradeoffs here. Best, r
participants (5)
-
dherring＠tentpost.com -
Faré -
Pascal J. Bourguignon -
Robert Goldman -
Samium Gromoff