Re: [RFC/GSoC] Introduction

[Sidhant Sharma]

On Monday 14 March 2016 02:49 AM, Kevin Daudt wrote:
> On Mon, Mar 14, 2016 at 12:03:33AM +0530, Sidhant Sharma wrote:
>> Other than this, I also tried to expand the list of potentially destructive
>> commands and updated the list as follows (additions in brackets):
>>
>> * git rebase [ git pull --rebase ]
>> * git reset --hard
>> * git clean -f
>> * git gc --prune=now --aggressive
>> * git push -f [ git push  :, git push  + ]
>> * [ git branch -D ]
>>
>> Are these additions appropriate? What other commands should be included?
>>
> git checkout [ref]  is destructive too if it would overwrite an
> uncomitted change.
Thanks, I'll add that one too. Also, should git checkout --  be
added, since it'll discard all uncommitted changes?

Regards,
Sidhant Sharma

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/GSoC] Introduction

[Sidhant Sharma]

On Monday 14 March 2016 04:58 AM, Jacob Keller wrote:
> On Sun, Mar 13, 2016 at 11:33 AM, Sidhant Sharma  
> wrote:
>> Coincidentally, my approach too is a wrapper around git as you suggest.
>> The approach is simple and straight forward, but I wasn't sure if it would be
>> accepted on the list, mainly because it may not look consistent with the 
>> current
>> interface `git command [options]`. Perhaps a configuration like
>> `core.beginnerMode` [4] might be apt? By default, it can be false, making git
>> behave normally. When set, a safety-check can be run before the command is
>> executed to ensure it's not potentially destructive. Very much like a wrapper
>> but on the inside. There can be an option like `--no-beginner` to override
>> this configuration from the command-line. I was wondering if there should be
>> command-specific options as well, such as `beginner.allowForcePush`,
>> `beginner.allowRebase` etc. for a finer control over what commands git would 
>> warn
>> the user about. By default, all are set to false, and warning is shown when 
>> any
>> of them is encountered. Another configuration that may be considered is
>> `beginner.strict`, which when set would just print the warning and die, 
>> instead
>> of giving the user an option to continue (though I'm a little unsure whether
>> this one would be a good idea).
>> One thing that bothers me about this approach is that unlike the explicit 
>> 'ggit'
>> wrapper, an internal wrapper would add (unnecessary?) overhead for most 
>> commands,
>> thus impacting the performance. Will that be an issue?
>>
> If I recall correctly, a configuration setting was previously
> discussed but mostly discarded as a solution since any changes had
> better not impact any current scripts. Having to add "--no-beginner"
> for all of them seems unacceptable. Especially since many scripts may
> do potentially dangerous operations in a safe or useful way.
>
I agree that adding `--no-beginner` to all such commands wouldn't be right. In
that case, can we have the flag between git and the command? Such as
`git --no-beginner reset --hard`. If present, the flag can then be removed from
the argument list and the rest of the command executed as is without warning.
Would that a better option?


Thanks and regards,
Sidhant Sharma

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] git-p4: fix AsciiDoc formatting

[Junio C Hamano]

Lars Schneider  writes:

>> diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
>> index 738cfde..140fc12 100644
>> --- a/Documentation/git-p4.txt
>> +++ b/Documentation/git-p4.txt
>> @@ -528,7 +528,7 @@ git-p4.largeFileSystem::
>> git config   git-p4.largeFileSystem GitLFS
>> -
>> +
>> -[1] https://git-lfs.github.com/
>> +[1] https://git-lfs.github.com/
>> 
>> git-p4.largeFileExtensions::
>>  All files matching a file extension in the list will be processed
>> --
>> 2.5.1
>> 
>
> Is there any chance to get this in? The formatting error is quite obvious 
> here:
> https://git-scm.com/docs/git-p4
>
> (while looking at this website I also noticed wrong double quotes around 
> cp1252
> which I will fix with a subsequent patch)

I ignored this when I saw it first, primarily because I assumed that
anything related to git-p4 would get a review by somebody better
versed with git-p4 before I get to it; I forgot about the patch
after it was buried in the other messages without anything
happening.

Will take a look.

Thanks.

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Graph sloc tool for git repos

[Jeff King]

On Sun, Mar 13, 2016 at 10:35:45PM -0400, Jeff King wrote:

> Like (this is back on the "we resolved as master" version of my example,
> to illustrate how the merge is shown):
> 
>   $ git log --first-parent -m --numstat --oneline
>   4244c8a resolved
>   1   1   file
>   b9bbaf9 side
>   1   0   file
>   09037ef base
>   1   0   file

You'd probably want --reverse, of course, since the point is to build up
the count in the same order as time flows.

So this is the working version I came up with:

git log --reverse --first-parent -m --format=%ct --numstat |
perl -lne '
  if (/^\d+$/) {
  if (defined $time) {
  print "$time $total"
  }
  $time = $&;
  } elsif (/^(\d+)\s+(\d+)\s/) {
  $total += $1 - $2;
  }
  END {
# flush last entry
print "$time $total";
  }
'

For my git.git repo, the final line it produces is:

1457666843 789457

which should be the final sloc-count right now.  If I count the lines in
the lines in HEAD, it's close but not quite the same:

   $ git ls-tree -r HEAD |
 awk '{print $3}' |
 xargs -n1 git cat-file blob |
 wc -l
   790437

I'd guess that the difference comes from a few files which are treated
as binary (and thus get "-" in their numstat output, but happen to have
newlines which cause "wc" to increment its count).

-Peff
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Graph sloc tool for git repos

[Jeff King]

On Sat, Mar 12, 2016 at 07:00:26PM +0800, Kai Hendry wrote:

> I penned a script to plot SLOC of a git project using GNUplot & I
> thought the fastest way to count code fluctuations was via `git show
> --numstat`.
> 
> However that requires some awk counting of the lines:
> https://github.com/kaihendry/graphsloc/blob/5f31e388e9b655e1801f13885f4311d221663a19/collect-stats.sh#L32
> 
> Is there a better way I missed? I think there is bug since my graph was
> a factor of 10 out whilst graphing Linux:
> https://twitter.com/kaihendry/status/706627679924174848

I think you'll always need to post-process the --numstat output to count
up lines. But that's fairly minor.

The bigger problem, I think is in how you handle merges. Imagine I have
two branches, each of which touch the same code:

  git init
  echo base >file
  git add file
  git commit -m base

  echo master >>file
  git commit -am master

  git checkout -b side HEAD^
  echo side >>file
  git commit -am side

and now I merge them, resolving the conflict favor of one side:

  git merge master
  { echo base; echo master; } >file
  git commit -am resolved

What does --numstat say?

  $ git log --cc --oneline --numstat
  989c6f7 resolved
  1   1   file
  b9bbaf9 side
  1   0   file
  087b294 master
  1   0   file
  09037ef base
  1   0   file

If we add these up, it looks like 3 lines were added. But the end result
has only 2 lines! We double-counted the additions on the two branches,
even though one stomped on the other. And then the merge resolution
looks neutral (one line gone, one line added), even though it was where
we did the stomping.

To be honest, I am not sure _what_ the "--cc --numstat" is showing
there (I added --cc because that is used by "git show", which is what
your script uses). The actual "--cc" (and "-c") patches show nothing,
which is right. It kind of looks like we are just showing the diffstat
against the first parent. I'm not sure anyone ever designed what a
"combined" diffstat would look like.

Let's redo our merge and resolve in favor of "side":

  git reset --hard HEAD^
  git merge master
  { echo base; echo side; } >file
  git commit -am resolved

Now the numstat is blank. I think it _is_ just showing the first-parent
diffstat. So that means each merge is introducing errors into your
count, and you'll drift away from accurate.

Another, related problem, is that you are adding up numbers along
multiple simultaneous branches. So going back to my output above, at the
point we read the "master" commit, we might say that the total
sloc-count is 2.  That's correct. And then we read "side", and say there
are 3 lines. But that's not right. It doesn't build on master, so we
still have only 2 lines. So even _if_ we merged them and the end result
had 3 lines (or if we somehow accounted for the double-counting when
examining the merge), you'd have inaccuracies through your dataset.

Another way of thinking about it is that your graph wants to represent a
single linear history, with the sloc-count changing as time moves to the
right. But that's not what really happened; at any given time, there are
_several_ sloc-counts, depending on which branch you're following.

But that can also give us a clue about one solution[1].  For your
purposes, you don't care about hitting every commit. You just want a
bunch of linear samples of the form [timestamp, sloc] to feed to
gnuplot. We can use "--first-parent" to walk _a_ linear history and see
a strict progression. And then use "-m" to tell git to just show merges
as the diff against that first parent (i.e., summarizing everything that
happened along the side-branch we are not following).

Like (this is back on the "we resolved as master" version of my example,
to illustrate how the merge is shown):

  $ git log --first-parent -m --numstat --oneline
  4244c8a resolved
  1   1   file
  b9bbaf9 side
  1   0   file
  09037ef base
  1   0   file

And that count is right. We had one line in our base, one on the
"side" commit, and then the merge didn't change our sloc-count at all
(we dropped the "side" line in favor of "master").

Finally, I'll note one other thing in my examples above. Note that I
used a single "git log" invocation, whereas your script reads "rev-list"
output to start a series of N "git show" invocations. I'll bet that took
quite a long time to run on the kernel. :)  Doing it all in one git-log
means you avoid the process startup overhead, and I'd expect it to run
~50 times as fast (at least that was what I saw from a quick experiment
on a much smaller repo).

-Peff

[1] The other solution I thought of was to actually count the SLOC of
each tree at each commit, rather than worrying about diffs. You can
make it efficient by caching the SLOC of blob and tree sha1s, so
you don't count the same files over and over. That gives you
accurate SLOC-counts at any given point in time, but doesn't address
the multiple-branches 

Re: git-secret - store your private data inside a repository

[Robin H. Johnson]

Have you seen the much older pwstore tool?
https://github.com/formorer/pwstore

It does have some notable features missing from git-secret and similar
tools to this day.
- Whitelist of trusted keys to detect addition of unexpected keys.
- Specify what users/groups have access to any given file (via a header
  in each file, which implies that the file must be plaintext).

I've wondered if storing metadata about the objects in notes might
improve matters: 
- a clearsigned block with verifiable readable data (eg who in a team
  can access)
- an encrypted block with the inner key (nice side effect that this
  separates versioning of the wrapped inner key from the versioning of
  the object).

This also a nice property that when you revoke/remove an outer (user)
key, can know implicitly the old secrets they had access to (which
should probably be rotated, as you don't know if they have a copy of
them outside of the system).

Yes, I'm aware of other system's like Hashicorp's Vault, but do
appreciate the simplicity of git-secret, pass [1], pwstore [2] and other
simpler tools.

[1] https://www.passwordstore.org/
[2] https://github.com/formorer/pwstore
It's at least as old as the Git history indicates, possibly
older, I don't know if the Git history included a full conversion of
SVN history.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Infrastructure Lead, Foundation Trustee
E-Mail : robb...@gentoo.org
GnuPG FP   : 11ACBA4F 4778E3F6 E4EDF38E B27B944E 34884E85
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/GSoC] Introduction

[Jacob Keller]

On Sun, Mar 13, 2016 at 11:33 AM, Sidhant Sharma  wrote:
> Coincidentally, my approach too is a wrapper around git as you suggest.
> The approach is simple and straight forward, but I wasn't sure if it would be
> accepted on the list, mainly because it may not look consistent with the 
> current
> interface `git command [options]`. Perhaps a configuration like
> `core.beginnerMode` [4] might be apt? By default, it can be false, making git
> behave normally. When set, a safety-check can be run before the command is
> executed to ensure it's not potentially destructive. Very much like a wrapper
> but on the inside. There can be an option like `--no-beginner` to override
> this configuration from the command-line. I was wondering if there should be
> command-specific options as well, such as `beginner.allowForcePush`,
> `beginner.allowRebase` etc. for a finer control over what commands git would 
> warn
> the user about. By default, all are set to false, and warning is shown when 
> any
> of them is encountered. Another configuration that may be considered is
> `beginner.strict`, which when set would just print the warning and die, 
> instead
> of giving the user an option to continue (though I'm a little unsure whether
> this one would be a good idea).
> One thing that bothers me about this approach is that unlike the explicit 
> 'ggit'
> wrapper, an internal wrapper would add (unnecessary?) overhead for most 
> commands,
> thus impacting the performance. Will that be an issue?
>

If I recall correctly, a configuration setting was previously
discussed but mostly discarded as a solution since any changes had
better not impact any current scripts. Having to add "--no-beginner"
for all of them seems unacceptable. Especially since many scripts may
do potentially dangerous operations in a safe or useful way.

Thanks,
Jake
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/GSoC] Introduction

[Kevin Daudt]

On Mon, Mar 14, 2016 at 12:03:33AM +0530, Sidhant Sharma wrote:
> 
> 
> 
> Other than this, I also tried to expand the list of potentially destructive
> commands and updated the list as follows (additions in brackets):
> 
> * git rebase [ git pull --rebase ]
> * git reset --hard
> * git clean -f
> * git gc --prune=now --aggressive
> * git push -f [ git push  :, git push  + ]
> * [ git branch -D ]
> 
> Are these additions appropriate? What other commands should be included?
> 
> 

git checkout [ref]  is destructive too if it would overwrite an
uncomitted change.


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] commit: do not lose SQUASH_MSG contents

[Sven Strickroth]

When concluding a conflicted "git merge --squash", the command
failed to read SQUASH_MSG that was prepared by "git merge", and
showed only the "# Conflicts:" list of conflicted paths.

Place the contents from SQUASH_MSG at the beginning, just like we
show the commit log skeleton first when concluding a normal merge,
and then show the "# Conflicts:" list, to help the user write the
log message for the resulting commit.

Signed-off-by: Sven Strickroth 
---
 builtin/commit.c | 11 ++-
 1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/builtin/commit.c b/builtin/commit.c
index d054f84..d40b788 100644
--- a/builtin/commit.c
+++ b/builtin/commit.c
@@ -726,9 +726,18 @@ static int prepare_to_commit(const char *index_file, const 
char *prefix,
  , );
hook_arg1 = "message";
} else if (!stat(git_path_merge_msg(), )) {
+   /*
+* prepend SQUASH_MSG here if it exists and a
+* "merge --squash" was originally performed
+   */
+   if (!stat(git_path_squash_msg(), )) {
+   if (strbuf_read_file(, git_path_squash_msg(), 0) < 0)
+   die_errno(_("could not read SQUASH_MSG"));
+   hook_arg1 = "squash";
+   } else
+   hook_arg1 = "merge";
if (strbuf_read_file(, git_path_merge_msg(), 0) < 0)
die_errno(_("could not read MERGE_MSG"));
-   hook_arg1 = "merge";
} else if (!stat(git_path_squash_msg(), )) {
if (strbuf_read_file(, git_path_squash_msg(), 0) < 0)
die_errno(_("could not read SQUASH_MSG"));
-- 
Best regards,
 Sven Strickroth
 PGP key id F5A9D4C4 @ any key-server
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/GSoC] Introduction

[Sidhant Sharma]

On Sunday 13 March 2016 09:20 PM, Lars Schneider wrote:
> Hi Sidhant,
>
> thanks for your interest in the 'Git Beginner' mode topic. I completely 
> understand your motivation for the topic as your Git learning experience
> matches mine. However, please be aware that this is no easy project. The
> final implementation might be easy but it will require hard work to come 
> up with a design for the beginner mode that the list considers to accept.
> That being said, I am eager to learn about your ideas on the topic :-)
Hi,

I understand that this project will require much effort to find an acceptable
solution and I'm prepared for it. I'm very excited to take this one up :)

> Based on my previous discussions with Junio [3] I think on of the most 
> important aspects is to ensure that Git does not become harder to use.
> I thought a while about this requirement and I wonder if a wrapper called 
> 'ggit' (guarded Git) could be a solution. The wrapper would pass all 
> command line arguments to 'git' and check for potentially destructive 
> commands. If such a command is detected then the user would see a warning. 
> If the command is not destructive then 'ggit' would print a short instruction 
> how to "undo" it. The ordinary Git user would not be affected at all by the 
> wrapper. A novice Git user who is unsure about his/her command line
> usage could use `ggit` as a safety net.
>
> I am curious about your opinions on this kind of approach. I wonder if
> people would actually use such a wrapper.
Coincidentally, my approach too is a wrapper around git as you suggest.
The approach is simple and straight forward, but I wasn't sure if it would be
accepted on the list, mainly because it may not look consistent with the current
interface `git command [options]`. Perhaps a configuration like
`core.beginnerMode` [4] might be apt? By default, it can be false, making git
behave normally. When set, a safety-check can be run before the command is
executed to ensure it's not potentially destructive. Very much like a wrapper
but on the inside. There can be an option like `--no-beginner` to override
this configuration from the command-line. I was wondering if there should be
command-specific options as well, such as `beginner.allowForcePush`,
`beginner.allowRebase` etc. for a finer control over what commands git would 
warn
the user about. By default, all are set to false, and warning is shown when any
of them is encountered. Another configuration that may be considered is
`beginner.strict`, which when set would just print the warning and die, instead
of giving the user an option to continue (though I'm a little unsure whether
this one would be a good idea).
One thing that bothers me about this approach is that unlike the explicit 'ggit'
wrapper, an internal wrapper would add (unnecessary?) overhead for most 
commands,
thus impacting the performance. Will that be an issue?

Along with this, the idea of showing a short instruction for undoing commands
sounds very nice as it'll help beginners to understand and use git better.

I'm eager to know your opinions on this approach :)

Other than this, I also tried to expand the list of potentially destructive
commands and updated the list as follows (additions in brackets):

* git rebase [ git pull --rebase ]
* git reset --hard
* git clean -f
* git gc --prune=now --aggressive
* git push -f [ git push  :, git push  + ]
* [ git branch -D ]

Are these additions appropriate? What other commands should be included?


Thanks and regards,
Sidhant Sharma


[4]: http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286663
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v1] git-p4: fix AsciiDoc formatting

[Lars Schneider]

On 01 Mar 2016, at 12:05, larsxschnei...@gmail.com wrote:

> From: Lars Schneider 
> 
> Noticed-by: Eric Sunshine 
> Signed-off-by: Lars Schneider 
> ---
> Documentation/git-p4.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
> index 738cfde..140fc12 100644
> --- a/Documentation/git-p4.txt
> +++ b/Documentation/git-p4.txt
> @@ -528,7 +528,7 @@ git-p4.largeFileSystem::
> git config   git-p4.largeFileSystem GitLFS
> -
> +
> - [1] https://git-lfs.github.com/
> +[1] https://git-lfs.github.com/
> 
> git-p4.largeFileExtensions::
>   All files matching a file extension in the list will be processed
> --
> 2.5.1
> 

Is there any chance to get this in? The formatting error is quite obvious here:
https://git-scm.com/docs/git-p4

(while looking at this website I also noticed wrong double quotes around cp1252
which I will fix with a subsequent patch)

Thanks,
Lars--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2] git-p4: map a P4 user to Git author name and email address

[Lars Schneider]

On 02 Mar 2016, at 10:25, Lars Schneider  wrote:

> 
>> On 02 Mar 2016, at 06:06, Luke Diamand  wrote:
>> 
>> On 1 March 2016 at 19:15, Eric Sunshine  wrote:
>>> On Tue, Mar 1, 2016 at 5:49 AM,   wrote:
 Map a P4 user to a specific name and email address in Git with the
 "git-p4.mapUser" config. The config value must be a string adhering
 to the format "p4user = First Lastname ".
 
 Signed-off-by: Lars Schneider 
 ---
 diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
 +git-p4.mapUser::
 +   Map a P4 user to a name and email address in Git. Use a string
 +   with the following format to create a mapping:
 ++
 +-
 +git config --add git-p4.mapUser "p4user = First Last "
 +-
 ++
 +A mapping will override any user information from P4. Mappings for
 +multiple P4 user can be defined.
>>> 
>>> Sorry for not paying closer attention the first time, but this needs
>>> to be repeated for each P4 user you want to map, right? One can
>>> imagine this quickly becoming painful if you have a lot of users to
>>> map. Have you considered modeling this after git-svn where you can set
>>> an "authors" file (and name the corresponding option --authors-file)?
>> 
>> For most authors it should just use the existing Perforce user
>> information. This is (I assume) just for the occasional exception
>> where Perforce has the wrong email address.
> I agree this is an occasional exception. I use it for users that have been 
> deleted on the Perforce server.
> 
> @Eric: If a user wants to they could create a custom gitconfig and then use 
> the config "include" mechanism to achieve a "authors" file kind of approach.
> 

Is the patch uninteresting for git-p4 as it handles only an occasional
exception or did the patch get lost in the noise? :-)

Thanks,
Lars

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Greetings

[Mevrouw Estelle Amadieu]

Greetings,

I am Mrs Estelle Amadieu, I am 65 years old base in Cote d'Ivoire I write to 
relate to you of my intention to use my money 2.5 million dollars for charity 
work in your country. I was married to Late Chrestien Amadieu who was a 
contractor with the Government of Cote d'Ivoire before he died after few days 
in the hospital.I have been suffering from cancer I want to know if I can trust 
you to use these funds for charity/orphanage and 20% will be for you as 
compensation. Please contact me, so that I will give you more details.

Yours in the Lord,

Mrs Estelle Amadieu
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC/GSoC] Introduction

[Lars Schneider]

Hi Sidhant,

thanks for your interest in the 'Git Beginner' mode topic. I completely 
understand your motivation for the topic as your Git learning experience
matches mine. However, please be aware that this is no easy project. The
final implementation might be easy but it will require hard work to come 
up with a design for the beginner mode that the list considers to accept.
That being said, I am eager to learn about your ideas on the topic :-)

Based on my previous discussions with Junio [3] I think on of the most 
important aspects is to ensure that Git does not become harder to use.
I thought a while about this requirement and I wonder if a wrapper called 
'ggit' (guarded Git) could be a solution. The wrapper would pass all 
command line arguments to 'git' and check for potentially destructive 
commands. If such a command is detected then the user would see a warning. 
If the command is not destructive then 'ggit' would print a short instruction 
how to "undo" it. The ordinary Git user would not be affected at all by the 
wrapper. A novice Git user who is unsure about his/her command line
usage could use `ggit` as a safety net.

I am curious about your opinions on this kind of approach. I wonder if
people would actually use such a wrapper.

Thanks,
Lars

[3] http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286749



On 12 Mar 2016, at 07:59, Sidhant Sharma  wrote:

> Hi everyone!
> 
> I am Sidhant Sharma, from Delhi, India. I'm a third year Software Engineering
> student at Delhi Technological University. I am looking to contribute to
> Git via GSoC 2016. I have also worked on one of the microprojects [1]. I've
> been using git for nearly two years now, and continue to be surprised by the
> vast number of features this powerful DVCS possesses. I want to contribute to
> Git because it has become a daily-use tool for me and it feels exciting to
> be a part of the community that makes effective collaborative development
> possible.
> 
> I would like to work on the project titled 'Git Beginner mode', and have been
> reading up the discussions that took place regarding this [2]. The reason I 
> wish
> to take this project in particular is that when I initially started out with
> Git, and was still discovering how things really worked, I sometimes felt the
> need for some sort of safety-latch to keep me from making destructive and/or
> irreversible changes. So, this project gives me the opportunity to implement
> something on these lines for the future beginners. I believe a lot of 
> discussion
> on the idea is due. I'm reading up on the commands that were mentioned on the
> project page to better understand what the project entails, and trying to 
> design
> a solution for this, without making git harder to use or getting in the user's
> learning. I would really appreciate your comments, suggestions and critique on
> this.
> 
> Thanks and regards,
> Sidhant Sharma
> 
> [1]: http://thread.gmane.org/gmane.comp.version-control.git/288035
> [2]: 
> http://thread.gmane.org/gmane.comp.version-control.git/285893/focus=286613
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

git-secret - store your private data inside a repository

[Никита Соболев]

There’s a known problem in server configuration and deploying, when
you have to store your private data such as: database passwords,
application secret-keys, OAuth secret keys and so on, outside of the
git repository. Even if this repository is private, it is a security
risk to just publish them into the world wide web. What are the
drawbacks of storing them separately?

These files are not version controlled. Filenames change, locations
change, passwords change from time to time, some new information
appears, other is removed. And you can not tell for sure which version
of the configuration file was used with each commit.
When building the automated deployment system there will be one extra
step: download and place these secret-configuration files where they
need to be. So you have to maintain an extra secure server, where
everything is stored.
How does git-secret solve these problems?

git-secret encrypts files and stores them inside the git repository,
so you will have all the changes for every commit.
git-secret doesn’t require any other deploy operations rather than git
secret reveal, so it will automatically decrypt all the required
files.
What is git-secret?

git-secret is a bash tool to store your private data inside a git
repo. How’s that? Basically, it just encrypts, using gpg, the tracked
files with the public keys of all the users that you trust. So
everyone of them can decrypt these files using only their personal
secret key. Why deal with all this private-public keys stuff? Well, to
make it easier for everyone to manage access rights. There are no
passwords that change. When someone is out - just delete his public
key, reencrypt the files, and he won’t be able to decrypt secrets
anymore.

Find out more: https://sobolevn.github.io/git-secret/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Draft of Git Rev News edition 13

[Christian Couder]

Hi,

A draft of Git Rev News edition 13 is available here:

  https://github.com/git/git.github.io/blob/master/rev_news/drafts/edition-13.md

Everyone is welcome to contribute in any section either by editing the
above page on GitHub and sending a pull request, or by commenting on
this GitHub issue:

  https://github.com/git/git.github.io/issues/121

You can also reply to this email.

I tried to cc everyone who appears in this edition but maybe I missed
some people, sorry about that.

Thomas, Nicola and myself plan to publish this edition on Wednesday
the 16th of March.

Thanks,
Christian.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html