On Sat, Sep 13, 2008 at 9:06 PM, Miles Georgi [off-list ref] wrote:
I'll just answer by numbers, I hope it's not too inconvenient to have
to scroll between emails to see which point I'm talking about :/
In general, it's better to use inline quoting. It's okay if the
quotes get long, because long messages are manageable, but messages
that require you to look at *other* messages at the same time are just
a PITA. Luckily, however, I at least remember what we're talking
about :)
1. Oh, I'm not really aware of what "cvs export" does. I assumed it
meant something very similar to "svn export" Running "ext export URL"
on a project manage by subversion with all the subprojects managed by
subversion simply runs "svn export URL" followed by an "svn export"
for each subproject, hence the name. Calling it "shallow" makes sense
for git since I'm using --depth 1, but since "svn export" doesn't
create the .svn directories necessary to make it a working directory,
I don't really know if I would call that shallow. For git's
implementation of export, I was thinking of just doing a clone and
then deleting .git/ which also wouldn't be shallow.
Aha, sorry. In that case, it does do exactly what cvs export and svn
export do, so I take it back. I would never use it (because I always
deploy my .git directories along with the app itself... free
backups!). But the name is correct.
3. I am also bothered by the inconsistency of the meaning of [main]
and [git/svn] along with everything you pointed out.
Question? Is it okay to have "/" characters in the ini section name?
Yes. In general, a section name can have anything except a ] in it,
and a key can have anything but an = in it. (Well, obviously we
should expect that there are no CR, LF, or NUL characters either.)
If you want to do it exactly like git, you would name your sections like
[ext "libs/my/plugin"]
instead of my earlier suggestion of
[libs/my/plugin]
This would be compatible with git-config. Also, this method means
that the [main] section could never be confused with a particular ext
section.
I wonder if it would be okay to just put the repository
as the section name. That way scm and path could be excluded for
situations where the defaults are sufficient. Although I guess this
would have the implication of changing a projects repository
(something that happens way more frequently than changing the path
it's installed to) some what messy since it's being identified by its
repository.
I think you answered your own question there :) Personally, it feels
natural to me to index a submodule by its local path, and have the URL
be an attribute of that submodule, rather than the other way around.
This makes sense since every local path can only have one submodule on
it, while in insane situations, you can imagine having exactly the
same repo (perhaps different revisions or branches?) cloned into two
different locations.
But yeah, if this feature makes somebody nervous, they can just always
explicitly give the path (which they'll have to do if it's not a rails
app.) It also detects that it's a rails app so it will complain if
you leave the path off in a non-rails app. It won't try to put
something in vendor/plugins of a non-rails app just because a path is
missing.
Okay, if it's not in rails mode, I guess it won't cause problems... as
long as the rails auto-detection is extremely reliable and can be
turned off somehow.
5. Yeah that's a good idea. I could create a command that adds an
existing subproject to the .externals and updates the ignore properly.
To get this effect at the moment, one would manually add the
subproject to .externals and run "ext update_ignore" I personally
don't usually find myself doing this though. I almost always want the
subproject to be added to the project. I need to make an "ext
uninstall" for backing out if you don't like it. I personally would
rather manually remove the item from .externals than have to issue two
commands to install it. But your idea of a save command is very
powerful, especially with the branch switching ideas you have in #8
below.
Right, it wouldn't matter which way you did it, but the other options
below fit really nicely into a 'git save' operation.
Also, I personally think it's more elegant to not have to do "undo"
operations as a normal part of your workflow. Checkout work work work
save seems nicer to me than Checkout uninstall work work work.
[nested submodules]
6. Hey that's a pretty interesting idea! I hadn't even thought about
that as I have not yet personally encountered that use case. I've
been hoping that rails plugins could have their own vendor/plugins
directory because if they did I would also use something like that all
the time. This is definitely something that should be implemented at
some point.
Well, like I said, I'm doing it right now in one of my projects :)
But it doesn't have to be a high priority.
7. Agreed (for the most part.) I almost never want to do this for my
own projects as I almost always want the branch tip no matter what.
I'd rather run tests and discover that something has broke before
deploying than have to go to all my projects and advance the commit
manually.
Ouch, I would never want to do it that way! If my app has been
deployed for three months and someone reports a minor bug, I just want
to fix that one bug and redeploy safely and immediately. I certainly
don't want to risk breaking everything by upgrading a bunch of
unrelated modules.
the way I
currently have been handling this is by having my own rails repository
at git://github.com/azimux/rails.git that I occaisionally will merge
rails/rails.git with and run tests for my larger applications. If I
like how it behaves I push the merged tip back out to azimux/rails.git
which is what all my projects reference in their .externals file.
This sounds like a convoluted way of just doing what I suggested. :)
Oh, that reminds me of another feature that would be awesome:
*alternate* repository URLs. In your example above, let's say you've
made some rails customizations, anyone cloning your project will have
to get your version. But one day, the rails developers merge in your
changes, so now their primary repo (probably with more bandwidth,
uptime, etc) will work again. If the ext lists *all* the repositories
you might need, ext can just git fetch from all of them, then checkout
the commit in question, and it will always work.
And I would definitely not
have it disconnected from a branch if it can be avoided. I guess it
would checkout a specific commit but be on a branch, and then if the
developer needed to edit the subproject, they would realize it was
non-fastforward when they pushed and then do a rebase against the
current tip? I'm not 100% sure how this workflow would normally occur
as I've not yet had to rebase anything, and when I was using
git-submodule, I would always checkout a branch tip if I had to edit
the subproject and then would do a git add submodule/path to point at
the new commit when I was done.
It can be simpler than that. Essentially, what you do is:
git fetch origin
git checkout COMMITID
git branch -D BRANCHNAME
git checkout -b BRANCHNAME
The first checkout puts you on a disconnected HEAD temporarily, just
in case you were previously on a branch called BRANCHNAME, which would
have prevented the "delete branch" operation from working. Then we
delete the branch, and recreate it at the new location (COMMITID).
With that in place, git will know how to do everything else
automatically, but it's up to the user. You can pull/merge the latest
changes from another branch, or rebase, etc.
Note that as a safety measure, you probably want to refuse to actually
do the above if either of:
a) The git filesystem or index shows uncommitted files
b) The current git commit != the commit ext thinks is checked out right now.
9. I wasn't planning on having any sort of commit/push-type features
since the workflows of the SCMs are different when it comes to
commiting/pushing. For example, if it's a subversion project it needs
to do an "svn commit" requiring a log message. And sometimes I really
only want to push a subset of the subprojects that I've modified.
I think it would be really cool if ext could just figure this out.
For example, it's easy to tell that in svn, your changes have to be
committed (ie. no dirty tree) and in git, the upstream repo needs to
contain your commitid (it's been pushed).
If you only want to push a subset of projects, that's fine, but you
can do it in the individual subdirs by hand anyhow. On the other
hand, I'd say you *don't* want to ever push the parent repo without
first pushing all your changes, particularly if you have the commitid
encoded in the .externals file, or you'll produce an un-checkout-able
repository.
Maybe what I could do is have "ext status" also see if a subproject
could be pushed and issue a warning like "<subproject> has commits
that are missing from <remote name>. Did you forget to push?" This
would be unnecessary for subversion managed subprojects as if it's up
to date, then it's pushed and vice versa, but for git it would be very
helpful for when the status is empty due to commits being performed,
but is not yet pushed out to it's origin.
Yes, that would be almost as good.
I don't know if I would
like it automatically doing the pushing though, but it could be
doable, maybe with a command with the name "git" in it to specify it's
scm specific, like "ext gitpush" or I could just have an "ext push"
that does nothing for svn/cvs projects.
I don't think it should do nothing for svn/cvs projects: it should
either help you commit, or abort with a helpful message if your repo
is dirty, or something like that.
Hope this helps.
Have fun,
Avery
Avery, and anybody else who might be interested:
I have released a new version of externals which uses the format
recommended by Avery.
That should make it easier to add new features, such as the ones
mentioned in Avery's email. I've switched some of my projects to it
and it seems to be working fine.
I've bumped the version to 0.1.0 to signify a more betaish stage :)
Miles
On Sat, Sep 13, 2008 at 9:21 PM, Avery Pennarun [off-list ref] wrote:
On Sat, Sep 13, 2008 at 9:06 PM, Miles Georgi [off-list ref] wrote:
quoted
I'll just answer by numbers, I hope it's not too inconvenient to have
to scroll between emails to see which point I'm talking about :/
In general, it's better to use inline quoting. It's okay if the
quotes get long, because long messages are manageable, but messages
that require you to look at *other* messages at the same time are just
a PITA. Luckily, however, I at least remember what we're talking
about :)
quoted
1. Oh, I'm not really aware of what "cvs export" does. I assumed it
meant something very similar to "svn export" Running "ext export URL"
on a project manage by subversion with all the subprojects managed by
subversion simply runs "svn export URL" followed by an "svn export"
for each subproject, hence the name. Calling it "shallow" makes sense
for git since I'm using --depth 1, but since "svn export" doesn't
create the .svn directories necessary to make it a working directory,
I don't really know if I would call that shallow. For git's
implementation of export, I was thinking of just doing a clone and
then deleting .git/ which also wouldn't be shallow.
Aha, sorry. In that case, it does do exactly what cvs export and svn
export do, so I take it back. I would never use it (because I always
deploy my .git directories along with the app itself... free
backups!). But the name is correct.
quoted
3. I am also bothered by the inconsistency of the meaning of [main]
and [git/svn] along with everything you pointed out.
Question? Is it okay to have "/" characters in the ini section name?
Yes. In general, a section name can have anything except a ] in it,
and a key can have anything but an = in it. (Well, obviously we
should expect that there are no CR, LF, or NUL characters either.)
If you want to do it exactly like git, you would name your sections like
[ext "libs/my/plugin"]
instead of my earlier suggestion of
[libs/my/plugin]
This would be compatible with git-config. Also, this method means
that the [main] section could never be confused with a particular ext
section.
quoted
I wonder if it would be okay to just put the repository
as the section name. That way scm and path could be excluded for
situations where the defaults are sufficient. Although I guess this
would have the implication of changing a projects repository
(something that happens way more frequently than changing the path
it's installed to) some what messy since it's being identified by its
repository.
I think you answered your own question there :) Personally, it feels
natural to me to index a submodule by its local path, and have the URL
be an attribute of that submodule, rather than the other way around.
This makes sense since every local path can only have one submodule on
it, while in insane situations, you can imagine having exactly the
same repo (perhaps different revisions or branches?) cloned into two
different locations.
quoted
But yeah, if this feature makes somebody nervous, they can just always
explicitly give the path (which they'll have to do if it's not a rails
app.) It also detects that it's a rails app so it will complain if
you leave the path off in a non-rails app. It won't try to put
something in vendor/plugins of a non-rails app just because a path is
missing.
Okay, if it's not in rails mode, I guess it won't cause problems... as
long as the rails auto-detection is extremely reliable and can be
turned off somehow.
quoted
5. Yeah that's a good idea. I could create a command that adds an
existing subproject to the .externals and updates the ignore properly.
To get this effect at the moment, one would manually add the
subproject to .externals and run "ext update_ignore" I personally
don't usually find myself doing this though. I almost always want the
subproject to be added to the project. I need to make an "ext
uninstall" for backing out if you don't like it. I personally would
rather manually remove the item from .externals than have to issue two
commands to install it. But your idea of a save command is very
powerful, especially with the branch switching ideas you have in #8
below.
Right, it wouldn't matter which way you did it, but the other options
below fit really nicely into a 'git save' operation.
Also, I personally think it's more elegant to not have to do "undo"
operations as a normal part of your workflow. Checkout work work work
save seems nicer to me than Checkout uninstall work work work.
[nested submodules]
quoted
6. Hey that's a pretty interesting idea! I hadn't even thought about
that as I have not yet personally encountered that use case. I've
been hoping that rails plugins could have their own vendor/plugins
directory because if they did I would also use something like that all
the time. This is definitely something that should be implemented at
some point.
Well, like I said, I'm doing it right now in one of my projects :)
But it doesn't have to be a high priority.
quoted
7. Agreed (for the most part.) I almost never want to do this for my
own projects as I almost always want the branch tip no matter what.
I'd rather run tests and discover that something has broke before
deploying than have to go to all my projects and advance the commit
manually.
Ouch, I would never want to do it that way! If my app has been
deployed for three months and someone reports a minor bug, I just want
to fix that one bug and redeploy safely and immediately. I certainly
don't want to risk breaking everything by upgrading a bunch of
unrelated modules.
quoted
the way I
currently have been handling this is by having my own rails repository
at git://github.com/azimux/rails.git that I occaisionally will merge
rails/rails.git with and run tests for my larger applications. If I
like how it behaves I push the merged tip back out to azimux/rails.git
which is what all my projects reference in their .externals file.
This sounds like a convoluted way of just doing what I suggested. :)
Oh, that reminds me of another feature that would be awesome:
*alternate* repository URLs. In your example above, let's say you've
made some rails customizations, anyone cloning your project will have
to get your version. But one day, the rails developers merge in your
changes, so now their primary repo (probably with more bandwidth,
uptime, etc) will work again. If the ext lists *all* the repositories
you might need, ext can just git fetch from all of them, then checkout
the commit in question, and it will always work.
quoted
And I would definitely not
have it disconnected from a branch if it can be avoided. I guess it
would checkout a specific commit but be on a branch, and then if the
developer needed to edit the subproject, they would realize it was
non-fastforward when they pushed and then do a rebase against the
current tip? I'm not 100% sure how this workflow would normally occur
as I've not yet had to rebase anything, and when I was using
git-submodule, I would always checkout a branch tip if I had to edit
the subproject and then would do a git add submodule/path to point at
the new commit when I was done.
It can be simpler than that. Essentially, what you do is:
git fetch origin
git checkout COMMITID
git branch -D BRANCHNAME
git checkout -b BRANCHNAME
The first checkout puts you on a disconnected HEAD temporarily, just
in case you were previously on a branch called BRANCHNAME, which would
have prevented the "delete branch" operation from working. Then we
delete the branch, and recreate it at the new location (COMMITID).
With that in place, git will know how to do everything else
automatically, but it's up to the user. You can pull/merge the latest
changes from another branch, or rebase, etc.
Note that as a safety measure, you probably want to refuse to actually
do the above if either of:
a) The git filesystem or index shows uncommitted files
b) The current git commit != the commit ext thinks is checked out right now.
quoted
9. I wasn't planning on having any sort of commit/push-type features
since the workflows of the SCMs are different when it comes to
commiting/pushing. For example, if it's a subversion project it needs
to do an "svn commit" requiring a log message. And sometimes I really
only want to push a subset of the subprojects that I've modified.
I think it would be really cool if ext could just figure this out.
For example, it's easy to tell that in svn, your changes have to be
committed (ie. no dirty tree) and in git, the upstream repo needs to
contain your commitid (it's been pushed).
If you only want to push a subset of projects, that's fine, but you
can do it in the individual subdirs by hand anyhow. On the other
hand, I'd say you *don't* want to ever push the parent repo without
first pushing all your changes, particularly if you have the commitid
encoded in the .externals file, or you'll produce an un-checkout-able
repository.
quoted
Maybe what I could do is have "ext status" also see if a subproject
could be pushed and issue a warning like "<subproject> has commits
that are missing from <remote name>. Did you forget to push?" This
would be unnecessary for subversion managed subprojects as if it's up
to date, then it's pushed and vice versa, but for git it would be very
helpful for when the status is empty due to commits being performed,
but is not yet pushed out to it's origin.
Yes, that would be almost as good.
quoted
I don't know if I would
like it automatically doing the pushing though, but it could be
doable, maybe with a command with the name "git" in it to specify it's
scm specific, like "ext gitpush" or I could just have an "ext push"
that does nothing for svn/cvs projects.
I don't think it should do nothing for svn/cvs projects: it should
either help you commit, or abort with a helpful message if your repo
is dirty, or something like that.
Hope this helps.
Have fun,
Avery