Re: [git-users] Feature Request

[Pankaj Azad]

I keep bare repo in pen drive and view the contents or history using gitk or 
git extensions. Have no issues with that. The problem here is to keep is 
encrypted and be able to see on any pc by giving password. That's why I 
proposed encryption of git objects.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Feature Request

[Gergely Polonkai]

Hello,

Why not keeping a non-bare repo on the USB drive instead? But there are two
drawbacks here.

The first one is obvious: it will take much more space, as something is
always checked out.

The second one is a bit more subtle: you can push to a non-bare repo, but
you canʼt push to its checked out branch directly. Eg. if you checkout
master on the USB drive, you canʼt do git push us-drive master. As a
workaround, you have to git checkout another-branch (on the USB drive), git
push usb-drive master (on the PC), and git checkout master (on the USB
drive again).

Best,
Gergely

On Wed, Jan 24, 2018, 23:10 Pankaj Azad  wrote:

> I have a very specific scenario in mind which could be irrelevant to most
> git users but let me spell it out.
> I work on 2 machines not connected via LAN etc. I keep my work synced
> between them by having a bare repo in usb drive and using push,pull/fetch
> mechanism of git. I also want to be able to read my repo in usb drive on
> any other pc. I have explored many existing script/hooks based
> solutions but none met my expectations. So I made a feature request. I
> realize that majority of users might not find it useful but there could be
> a few users like me who would. Moreover if work starts in this direction
> then over a period, after undergoing multiple refinements it could shape
> into a useful feature.
> PS: I have thought about having the usb drive encrypted and in fact am
> currently using that. But then I want to have some unencrypted part in
> that. Creating and maintaining partitions in pen drive comes with its own
> problems when used across different operating systems
>
> --
> You received this message because you are subscribed to the Google Groups
> "Git for human beings" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to git-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Feature Request

[Pankaj Azad]

I have a very specific scenario in mind which could be irrelevant to most git 
users but let me spell it out.
I work on 2 machines not connected via LAN etc. I keep my work synced between 
them by having a bare repo in usb drive and using push,pull/fetch mechanism of 
git. I also want to be able to read my repo in usb drive on any other pc. I 
have explored many existing script/hooks based
solutions but none met my expectations. So I made a feature request. I realize 
that majority of users might not find it useful but there could be a few users 
like me who would. Moreover if work starts in this direction then over a 
period, after undergoing multiple refinements it could shape into a useful 
feature.
PS: I have thought about having the usb drive encrypted and in fact am 
currently using that. But then I want to have some unencrypted part in that. 
Creating and maintaining partitions in pen drive comes with its own problems 
when used across different operating systems

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Feature Request

[Pankaj Azad]

I have a very specific scenario in mind which could be irrelevant to most git 
users but let me spell it out.
I work on 2 machines not connected via LAN etc. I keep my work synced between 
them by having a bare repo in usb drive and using push,pull/fetch mechanism of 
git. I also want to be able to read my repo in usb drive on any other pc. I 
have explored many existing script/hooks based
solutions but none met my expectations. So I made a feature request. I realize 
that majority of users might not find it useful but there could be a few users 
like me who would. Moreover if work starts in this direction then over a 
period, after undergoing multiple refinements it could shape into a useful 
feature.
PS: I have thought about having the usb drive encrypted and in fact am 
currently using that. But then I want to have some unencrypted part in that and 
creating and having partitions in one drive comes with its own problems when 
used across different operating systems.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Feature Request

[Pankaj Azad]

I have a very specific scenario in mind which could be irrelevant to most git 
users but let me spell it out.
I work on 2 machines not connected via LAN etc. I keep my work synced between 
them by having a bare repo in usb drive and using push,pull/fetch mechanism of 
git. I also want to be able to read my repo in usb drive on any other pc. I 
have explored many existing script/hooks based
solutions but none met my expectations. So I made a feature request. I realize 
that majority of users might not find it useful but there could be a few users 
like me who would. Moreover if work starts in this direction then over a 
period, after undergoing multiple refinements it could shape into a useful 
feature.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] How to tag

[Konstantin Khomoutov]

On Tue, Jan 23, 2018 at 08:52:43PM +0100, Cecil Westerhof wrote:

> I just learned tcl and already made a package for it. I made a GitHub
> repository for it. Personally I like to keep all the tcl stuff in one
> repository. But there will (at a certain point) several packages and
> different scripts. What is a good way to tag a the master releases?
> 
> When upgrading a package: just the package name and the version?
> And what if I update a bunch of scripts?

This question appears to be more philosophical rather than technical.

As one example, you could look at the Tcl's stdlib, which is, while not
formally a part of Tcl, still considered to be "the standard" set of
packages.  It's released (and tagged) as a whole, when several updates
to its packages accumulate.  Secufity fixes, as usually, might warrant
special releases on their own.  Note, still, that each individual
package in the stdlib has its own version which gets incremented when
the code of that package changes.  AFAIK, such updates are not tagged
individually.  Still, some distributions (namely, ActiveTcl's "Teapot")
have each package from the stdlib packaged and available separately from
the rest of them.

If the set of packages you intend to manage is really loosely coupled,
and releasing them as a whole makes little sense, then having
per-package tags might indeed have sense but please note that in Git,
you tag commits¹, that is snapshots of the contents of the whole
repository, so your tag "foopkg-v1.0.0" would still tag the whole
repository. This will probably warrant explaining in the readme file.


¹ Well, technically you can tag anything; in particular, you can tag
  the tree object representing a particular directory—say, containing
  the code of a single package—as recorded in a particular commit.
  But I doubt the Github's web interface will be of any help there, and
  using such tags by the end user would be quite cumbersome as you can't
  checkout the target tree of such a tag using `git checkout`.

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [git-users] Feature Request

[Konstantin Khomoutov]

On Wed, Jan 24, 2018 at 09:50:27AM +1100, Timothy Rice wrote:

>> It's probably easier to let the encryption be at file system level and let
>> the hard drive handle it - maybe.
> 
> The problem with this is that it doesn't require collaborators to also use
> encryption. It also assumes that at least one of fuse and dm-crypt are
> enabled in the kernel (assuming Linux).
[...]
> So, although I don't want to discount the technical challenges that could
> be involved in providing an encryption layer for Git, I personally would be
> quite interested in whether it might be possible.
[...]

I think that encryption can be implemented with stock Git with a
wrapper.  (And I have heard of at least one commercial implementation of
this approach — IronGit™ [1]; note that I'm not affilicated with that
product/company in any way.)

One possible approach would be using the so-called clean/smudge filters
which could be set up for all types of files in a way that smudge
filters decrypt and clean filters encrypt.

But considering the whole picture hints at more general problems. I'd
list these:

 - Ideally different developers must have their own private keys so that
   they can be revoken when needed w/o affecting the rest of the team.
   The repository should not require total reencryption when this
   happens. Something akin to [2]. I'm not that versed in cryptography
   to tell whether it's possible with the contemporary algorithms.

   The same applies to digital signing (encryption w/o signing is
   not too interesting anyway).

 - The PKI part should be supported to a certain extent.

 - The set of algorithms used should somehow be future-proof (that is,
   be eligible for gradual upgrading, when needed).


Having said that, I don't *clearly* see the point of encrypting Git
repositories:

 - Shared (rendez-vouz) repositories can be hosted on properly contained
   premises and be allowed access only via trusted means (SSH with
   personal keys and/or HTTPS with personal certs being validated on the
   server side).

 - A local clone a developer makes will still have the work tree in
   order to be useful.  That is, such a repo would consist of an
   encrypted object store and one plain text snapshot of that in the
   work tree.  In order to secure this, you'd have to use
   filesystem-level or block device-level encryption, but once you start
   using it the necessity of encrypting the repository's object store
   becomes questionable.

1. https://atcipher.com/irongit/
2. https://www.schneier.com/blog/archives/2012/08/shared_lock.html

-- 
You received this message because you are subscribed to the Google Groups "Git 
for human beings" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to git-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.