'publish' generates public access urls for files.

[rainwoodman]

This is only implemented in the S3 backend.

A way to link the stub file to its content would
ease integration into repo hosting systems, if that ever happens
in the future.

eg, adding an url at the end of the stub file?

Example usage:

yfeng1@edison02:~/mydesi> git fat publish *.ipynb
NotebookDemo.ipynb => https://imaginglss-git.s3.amazonaws.com/be0e701526c1b75b43df3c9fde4a7b02507d59af
test.ipynb => https://imaginglss-git.s3.amazonaws.com/da39a3ee5e6b4b0d3255bfef95601890afd80709

[zelonght]

@rainwoodman should this a feature of git-fat? If we want to publish files in S3 as public or private, it's feature of S3, we should not add all file function to git-fat, or else we may end of at more commands: publish/unpublish/remove/copy...

@dlin@willkelleher thoughts?

[dlin]

I wouldn't mind a command (something like ls-sha1) which lists all the filename->sha1 pairs (and possibly in the other direction). It should be pretty easy to write a shell script that consumes the sha1 and generates the desired output.

[rainwoodman]

My use case here is I have been committing some IPtyhon notebooks to the repository, that I would like to share with collaborators with a directly link that is directly copied from a console. I agree the publish command is more or less only for S3 and too speicallized. I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file, that is ready to be shared.

[zelonght]

Re: git-fat locate [-p] [filenames] -- your suggestion is merginggit-fat locate/ls-sha(1) suggested by both @dlin and @rainwoodman and the git publish you suggested @ rainwoodman@43c73ae (2)

I think (1) maybe a bit common for git-fat usage but (2) maybe not its initial usage. If you agree on this -- "...publish command is more or less only for S3 and too specialized") merging (1) and (2) won't solve.

[dlin]

I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file,
that is ready to be shared.

What if we steal a page from git log and have a --format parameter. We
can even default to url. I think that one other format that it would be
nice to have is json, which could be machine parsable.

[dlin]

If you agree on this -- "...publish command is more or less only for S3
and too specialized") merging (1) and (2) won't solve.

I think that technically, we can have "rsync" urls. We might even have
http urls. @willkelleher is thinking about having multiple backends being
active at the same time, in which case this command could actually probe
where that file is actually available.

[rainwoodman]

git fat ls --format
I like the idea.

[rainwoodman]

This is only implemented in the S3 backend.

A way to link the stub file to its content would
ease integration into repo hosting systems, if that ever happens
in the future.

eg, adding an url at the end of the stub file?

Example usage:

yfeng1@edison02:~/mydesi> git fat publish *.ipynb
NotebookDemo.ipynb => https://imaginglss-git.s3.amazonaws.com/be0e701526c1b75b43df3c9fde4a7b02507d59af
test.ipynb => https://imaginglss-git.s3.amazonaws.com/da39a3ee5e6b4b0d3255bfef95601890afd80709

[zelonght]

@rainwoodman should this a feature of git-fat? If we want to publish files in S3 as public or private, it's feature of S3, we should not add all file function to git-fat, or else we may end of at more commands: publish/unpublish/remove/copy...

@dlin@willkelleher thoughts?

[dlin]

I wouldn't mind a command (something like ls-sha1) which lists all the filename->sha1 pairs (and possibly in the other direction). It should be pretty easy to write a shell script that consumes the sha1 and generates the desired output.

[rainwoodman]

My use case here is I have been committing some IPtyhon notebooks to the repository, that I would like to share with collaborators with a directly link that is directly copied from a console. I agree the publish command is more or less only for S3 and too speicallized. I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file, that is ready to be shared.

[zelonght]

Re: git-fat locate [-p] [filenames] -- your suggestion is merginggit-fat locate/ls-sha(1) suggested by both @dlin and @rainwoodman and the git publish you suggested @ rainwoodman@43c73ae (2)

I think (1) maybe a bit common for git-fat usage but (2) maybe not its initial usage. If you agree on this -- "...publish command is more or less only for S3 and too specialized") merging (1) and (2) won't solve.

[dlin]

I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file,
that is ready to be shared.

What if we steal a page from git log and have a --format parameter. We
can even default to url. I think that one other format that it would be
nice to have is json, which could be machine parsable.

[dlin]

If you agree on this -- "...publish command is more or less only for S3
and too specialized") merging (1) and (2) won't solve.

I think that technically, we can have "rsync" urls. We might even have
http urls. @willkelleher is thinking about having multiple backends being
active at the same time, in which case this command could actually probe
where that file is actually available.

[rainwoodman]

git fat ls --format
I like the idea.

[rainwoodman]

This is only implemented in the S3 backend.

A way to link the stub file to its content would
ease integration into repo hosting systems, if that ever happens
in the future.

eg, adding an url at the end of the stub file?

Example usage:

yfeng1@edison02:~/mydesi> git fat publish *.ipynb
NotebookDemo.ipynb => https://imaginglss-git.s3.amazonaws.com/be0e701526c1b75b43df3c9fde4a7b02507d59af
test.ipynb => https://imaginglss-git.s3.amazonaws.com/da39a3ee5e6b4b0d3255bfef95601890afd80709

[zelonght]

@rainwoodman should this a feature of git-fat? If we want to publish files in S3 as public or private, it's feature of S3, we should not add all file function to git-fat, or else we may end of at more commands: publish/unpublish/remove/copy...

@dlin@willkelleher thoughts?

[dlin]

I wouldn't mind a command (something like ls-sha1) which lists all the filename->sha1 pairs (and possibly in the other direction). It should be pretty easy to write a shell script that consumes the sha1 and generates the desired output.

[rainwoodman]

My use case here is I have been committing some IPtyhon notebooks to the repository, that I would like to share with collaborators with a directly link that is directly copied from a console. I agree the publish command is more or less only for S3 and too speicallized. I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file, that is ready to be shared.

[zelonght]

Re: git-fat locate [-p] [filenames] -- your suggestion is merginggit-fat locate/ls-sha(1) suggested by both @dlin and @rainwoodman and the git publish you suggested @ rainwoodman@43c73ae (2)

I think (1) maybe a bit common for git-fat usage but (2) maybe not its initial usage. If you agree on this -- "...publish command is more or less only for S3 and too specialized") merging (1) and (2) won't solve.

[dlin]

I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file,
that is ready to be shared.

What if we steal a page from git log and have a --format parameter. We
can even default to url. I think that one other format that it would be
nice to have is json, which could be machine parsable.

[dlin]

If you agree on this -- "...publish command is more or less only for S3
and too specialized") merging (1) and (2) won't solve.

I think that technically, we can have "rsync" urls. We might even have
http urls. @willkelleher is thinking about having multiple backends being
active at the same time, in which case this command could actually probe
where that file is actually available.

[rainwoodman]

git fat ls --format
I like the idea.

[rainwoodman]

This is only implemented in the S3 backend.

A way to link the stub file to its content would
ease integration into repo hosting systems, if that ever happens
in the future.

eg, adding an url at the end of the stub file?

Example usage:

yfeng1@edison02:~/mydesi> git fat publish *.ipynb
NotebookDemo.ipynb => https://imaginglss-git.s3.amazonaws.com/be0e701526c1b75b43df3c9fde4a7b02507d59af
test.ipynb => https://imaginglss-git.s3.amazonaws.com/da39a3ee5e6b4b0d3255bfef95601890afd80709

[zelonght]

@rainwoodman should this a feature of git-fat? If we want to publish files in S3 as public or private, it's feature of S3, we should not add all file function to git-fat, or else we may end of at more commands: publish/unpublish/remove/copy...

@dlin@willkelleher thoughts?

[dlin]

I wouldn't mind a command (something like ls-sha1) which lists all the filename->sha1 pairs (and possibly in the other direction). It should be pretty easy to write a shell script that consumes the sha1 and generates the desired output.

[rainwoodman]

My use case here is I have been committing some IPtyhon notebooks to the repository, that I would like to share with collaborators with a directly link that is directly copied from a console. I agree the publish command is more or less only for S3 and too speicallized. I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file, that is ready to be shared.

[zelonght]

Re: git-fat locate [-p] [filenames] -- your suggestion is merginggit-fat locate/ls-sha(1) suggested by both @dlin and @rainwoodman and the git publish you suggested @ rainwoodman@43c73ae (2)

I think (1) maybe a bit common for git-fat usage but (2) maybe not its initial usage. If you agree on this -- "...publish command is more or less only for S3 and too specialized") merging (1) and (2) won't solve.

[dlin]

I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file,
that is ready to be shared.

What if we steal a page from git log and have a --format parameter. We
can even default to url. I think that one other format that it would be
nice to have is json, which could be machine parsable.

[dlin]

If you agree on this -- "...publish command is more or less only for S3
and too specialized") merging (1) and (2) won't solve.

I think that technically, we can have "rsync" urls. We might even have
http urls. @willkelleher is thinking about having multiple backends being
active at the same time, in which case this command could actually probe
where that file is actually available.

[rainwoodman]

git fat ls --format
I like the idea.

[rainwoodman]

This is only implemented in the S3 backend.

A way to link the stub file to its content would
ease integration into repo hosting systems, if that ever happens
in the future.

eg, adding an url at the end of the stub file?

Example usage:

yfeng1@edison02:~/mydesi> git fat publish *.ipynb
NotebookDemo.ipynb => https://imaginglss-git.s3.amazonaws.com/be0e701526c1b75b43df3c9fde4a7b02507d59af
test.ipynb => https://imaginglss-git.s3.amazonaws.com/da39a3ee5e6b4b0d3255bfef95601890afd80709

[zelonght]

@rainwoodman should this a feature of git-fat? If we want to publish files in S3 as public or private, it's feature of S3, we should not add all file function to git-fat, or else we may end of at more commands: publish/unpublish/remove/copy...

@dlin@willkelleher thoughts?

[dlin]

I wouldn't mind a command (something like ls-sha1) which lists all the filename->sha1 pairs (and possibly in the other direction). It should be pretty easy to write a shell script that consumes the sha1 and generates the desired output.

[rainwoodman]

My use case here is I have been committing some IPtyhon notebooks to the repository, that I would like to share with collaborators with a directly link that is directly copied from a console. I agree the publish command is more or less only for S3 and too speicallized. I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file, that is ready to be shared.

[zelonght]

Re: git-fat locate [-p] [filenames] -- your suggestion is merginggit-fat locate/ls-sha(1) suggested by both @dlin and @rainwoodman and the git publish you suggested @ rainwoodman@43c73ae (2)

I think (1) maybe a bit common for git-fat usage but (2) maybe not its initial usage. If you agree on this -- "...publish command is more or less only for S3 and too specialized") merging (1) and (2) won't solve.

[dlin]

I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file,
that is ready to be shared.

What if we steal a page from git log and have a --format parameter. We
can even default to url. I think that one other format that it would be
nice to have is json, which could be machine parsable.

[dlin]

If you agree on this -- "...publish command is more or less only for S3
and too specialized") merging (1) and (2) won't solve.

I think that technically, we can have "rsync" urls. We might even have
http urls. @willkelleher is thinking about having multiple backends being
active at the same time, in which case this command could actually probe
where that file is actually available.

[rainwoodman]

git fat ls --format
I like the idea.

[rainwoodman]

This is only implemented in the S3 backend.

A way to link the stub file to its content would
ease integration into repo hosting systems, if that ever happens
in the future.

eg, adding an url at the end of the stub file?

Example usage:

yfeng1@edison02:~/mydesi> git fat publish *.ipynb
NotebookDemo.ipynb => https://imaginglss-git.s3.amazonaws.com/be0e701526c1b75b43df3c9fde4a7b02507d59af
test.ipynb => https://imaginglss-git.s3.amazonaws.com/da39a3ee5e6b4b0d3255bfef95601890afd80709

[zelonght]

@rainwoodman should this a feature of git-fat? If we want to publish files in S3 as public or private, it's feature of S3, we should not add all file function to git-fat, or else we may end of at more commands: publish/unpublish/remove/copy...

@dlin@willkelleher thoughts?

[dlin]

I wouldn't mind a command (something like ls-sha1) which lists all the filename->sha1 pairs (and possibly in the other direction). It should be pretty easy to write a shell script that consumes the sha1 and generates the desired output.

[rainwoodman]

My use case here is I have been committing some IPtyhon notebooks to the repository, that I would like to share with collaborators with a directly link that is directly copied from a console. I agree the publish command is more or less only for S3 and too speicallized. I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file, that is ready to be shared.

[zelonght]

Re: git-fat locate [-p] [filenames] -- your suggestion is merginggit-fat locate/ls-sha(1) suggested by both @dlin and @rainwoodman and the git publish you suggested @ rainwoodman@43c73ae (2)

I think (1) maybe a bit common for git-fat usage but (2) maybe not its initial usage. If you agree on this -- "...publish command is more or less only for S3 and too specialized") merging (1) and (2) won't solve.

[dlin]

I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file,
that is ready to be shared.

What if we steal a page from git log and have a --format parameter. We
can even default to url. I think that one other format that it would be
nice to have is json, which could be machine parsable.

[dlin]

If you agree on this -- "...publish command is more or less only for S3
and too specialized") merging (1) and (2) won't solve.

I think that technically, we can have "rsync" urls. We might even have
http urls. @willkelleher is thinking about having multiple backends being
active at the same time, in which case this command could actually probe
where that file is actually available.

[rainwoodman]

git fat ls --format
I like the idea.

[rainwoodman]

This is only implemented in the S3 backend.

A way to link the stub file to its content would
ease integration into repo hosting systems, if that ever happens
in the future.

eg, adding an url at the end of the stub file?

Example usage:

yfeng1@edison02:~/mydesi> git fat publish *.ipynb
NotebookDemo.ipynb => https://imaginglss-git.s3.amazonaws.com/be0e701526c1b75b43df3c9fde4a7b02507d59af
test.ipynb => https://imaginglss-git.s3.amazonaws.com/da39a3ee5e6b4b0d3255bfef95601890afd80709

[zelonght]

@rainwoodman should this a feature of git-fat? If we want to publish files in S3 as public or private, it's feature of S3, we should not add all file function to git-fat, or else we may end of at more commands: publish/unpublish/remove/copy...

@dlin@willkelleher thoughts?

[dlin]

I wouldn't mind a command (something like ls-sha1) which lists all the filename->sha1 pairs (and possibly in the other direction). It should be pretty easy to write a shell script that consumes the sha1 and generates the desired output.

[rainwoodman]

My use case here is I have been committing some IPtyhon notebooks to the repository, that I would like to share with collaborators with a directly link that is directly copied from a console. I agree the publish command is more or less only for S3 and too speicallized. I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file, that is ready to be shared.

[zelonght]

Re: git-fat locate [-p] [filenames] -- your suggestion is merginggit-fat locate/ls-sha(1) suggested by both @dlin and @rainwoodman and the git publish you suggested @ rainwoodman@43c73ae (2)

I think (1) maybe a bit common for git-fat usage but (2) maybe not its initial usage. If you agree on this -- "...publish command is more or less only for S3 and too specialized") merging (1) and (2) won't solve.

[dlin]

I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file,
that is ready to be shared.

What if we steal a page from git log and have a --format parameter. We
can even default to url. I think that one other format that it would be
nice to have is json, which could be machine parsable.

[dlin]

If you agree on this -- "...publish command is more or less only for S3
and too specialized") merging (1) and (2) won't solve.

I think that technically, we can have "rsync" urls. We might even have
http urls. @willkelleher is thinking about having multiple backends being
active at the same time, in which case this command could actually probe
where that file is actually available.

[rainwoodman]

git fat ls --format
I like the idea.

[rainwoodman]

This is only implemented in the S3 backend.

A way to link the stub file to its content would
ease integration into repo hosting systems, if that ever happens
in the future.

eg, adding an url at the end of the stub file?

Example usage:

yfeng1@edison02:~/mydesi> git fat publish *.ipynb
NotebookDemo.ipynb => https://imaginglss-git.s3.amazonaws.com/be0e701526c1b75b43df3c9fde4a7b02507d59af
test.ipynb => https://imaginglss-git.s3.amazonaws.com/da39a3ee5e6b4b0d3255bfef95601890afd80709

[zelonght]

@rainwoodman should this a feature of git-fat? If we want to publish files in S3 as public or private, it's feature of S3, we should not add all file function to git-fat, or else we may end of at more commands: publish/unpublish/remove/copy...

@dlin@willkelleher thoughts?

[dlin]

I wouldn't mind a command (something like ls-sha1) which lists all the filename->sha1 pairs (and possibly in the other direction). It should be pretty easy to write a shell script that consumes the sha1 and generates the desired output.

[rainwoodman]

My use case here is I have been committing some IPtyhon notebooks to the repository, that I would like to share with collaborators with a directly link that is directly copied from a console. I agree the publish command is more or less only for S3 and too speicallized. I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file, that is ready to be shared.

[zelonght]

Re: git-fat locate [-p] [filenames] -- your suggestion is merginggit-fat locate/ls-sha(1) suggested by both @dlin and @rainwoodman and the git publish you suggested @ rainwoodman@43c73ae (2)

I think (1) maybe a bit common for git-fat usage but (2) maybe not its initial usage. If you agree on this -- "...publish command is more or less only for S3 and too specialized") merging (1) and (2) won't solve.

[dlin]

I propose

git-fat locate [-p] [filenames]

It would return the filename->sha1 pairs without '-p' parameter.
with '-p', it returns the filename-> rsync / s3 download link of the file,
that is ready to be shared.

What if we steal a page from git log and have a --format parameter. We
can even default to url. I think that one other format that it would be
nice to have is json, which could be machine parsable.

[dlin]

If you agree on this -- "...publish command is more or less only for S3
and too specialized") merging (1) and (2) won't solve.

I think that technically, we can have "rsync" urls. We might even have
http urls. @willkelleher is thinking about having multiple backends being
active at the same time, in which case this command could actually probe
where that file is actually available.

[rainwoodman]

git fat ls --format
I like the idea.