How does a GitHub repository have zero contributors with obvious commits? - github

I noticed that a GitHub repository has zero contributors with obvious commits. How is this possible?

The committer email is not associated with any GitHub account. By picking a random commit, add adding the .patch suffix you can see this:
https://github.com/atomiks/reddit-user-analyser/commit/508b9f745dcfd9117367fa88e982bb739ecac616.patch
From 508b9f745dcfd9117367fa88e982bb739ecac616 Mon Sep 17 00:00:00 2001
From: atomiks <na#gmail.com>
Date: Wed, 22 Feb 2017 08:47:53 +1100
Subject: [PATCH] separate comments and submissions timeframes
...
The na#gmail.com is probably not associated with any GitHub account.
You can create such a repository following these steps:
# Create the Git repo locally
$ mkdir foo
$ cd foo/
$ git init
Initialized empty Git repository in /.../foo/.git/
# Create some files
$ echo 'foo' > index.js
$ ls
index.js
# Create the commit, but pass an invalid email address
# or one you are sure that is not associated with *any*
# GitHub account
$ git add . -A
$ git commit -m 'Initial' . --author 'foo <fooooooo_or_invalid_email_address_which_is_not_on_github#bar.com>'
[master a34597b] Initial
Author: foo <fooooooo_or_invalid_email_address_which_is_not_on_github#bar.com>
Date: Wed May 31 13:51:19 2017 +0300
1 file changed, 1 insertion(+)
create mode 100644 index.js
# Add the GitHub url
$ git remote add origin git#github.com:IonicaBizau/tmp42.git
# Push the repo
$ git push --all
Counting objects: 3, done.
Writing objects: 100% (3/3), 271 bytes | 0 bytes/s, done.
Total 3 (delta 0), reused 0 (delta 0)
To github.com:IonicaBizau/tmp42.git
* [new branch] master -> master
Then on the Github repo page you will see:
Clicking on the commit url and adding the .patch suffix (to get the raw information):
From a34597b39da17eb77ab29f686a78b276a3c18376 Mon Sep 17 00:00:00 2001
From: foo <fooooooo_or_invalid_email_address_which_is_not_on_github#bar.com>
Date: Wed, 31 May 2017 13:51:19 +0300
Subject: [PATCH] Initial
---
index.js | 1 +
1 file changed, 1 insertion(+)
create mode 100644 index.js
diff --git a/index.js b/index.js
new file mode 100644
index 0000000..257cc56
--- /dev/null
+++ b/index.js
## -0,0 +1 ##
+foo

Related

git: list dangling tags

Context:
assume you have some rather tricky CI/CD workflow which relies on git tags
the feature branches are built and generate some short-lived tags to signify commits which yield the deployable artifacts
when the feature branch gets squash-merged, usually it's deleted, but the tags, unsurprisingly, survive
after, say, several months of development the tag listing predictably becomes hairy
Hence, the question:
how would I, using git command line and, optionally, basic bash tooling
list all the branches which have given tag reachable (the dual to that is git tag -l --merged ${BRANCH_COMMITTISH}, but I need not tags for the given branch but branches for a given tag)
list all the tags which have empty output from point 1 above (obviously this is doable with a for loop (given any terminating implementation for 1), but maybe there's some neat magical git one-liner)?
git log --simplify-by-decoration --tags --not --branches --remotes --pretty=%d
--simplify-by-decoration says only show the bare minimum needed to reveal the ancestry (usually you use this with --graph). --tags --not --branches --remotes says, well, what it says: list the tag history that's not in the branches or remotes history, i.e. tags unreachable from any branch or remote-tracking branch. --pretty=%d says just show the refs.
git branch --contains ${TAG}
https://git-scm.com/docs/git-branch#git-branch---containsltcommitgt.
Just to illustrate all solutions I've seen so far:
~$ git init dangling_tags
Initialized empty Git repository in ~/dangling_tags/.git/
$ cd dangling_tags/
~/dangling_tags$ touch a.txt && git add a.txt && git commit -m a
[master (root-commit) f1b1070] a
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 a.txt
~/dangling_tags$ git tag a
~/dangling_tags$ git checkout -b feature/add_some_tags
Switched to a new branch 'feature/add_some_tags'
~/dangling_tags$ touch b.txt && git add b.txt && git commit -m b
[feature/add_some_tags 1871cde] b
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b.txt
~/dangling_tags$ git tag b
~/dangling_tags$ touch c.txt && git add c.txt && git commit -m c
[feature/add_some_tags 26f6611] c
1 file changed, 0 insertions(+), 0 deletions(-)
create mode 100644 c.txt
~/dangling_tags$ git tag c
~/dangling_tags$ git checkout master
Switched to branch 'master'
~/dangling_tags$ git merge --squash feature/add_some_tags
Updating f1b1070..26f6611
Fast-forward
Squash commit -- not updating HEAD
b.txt | 0
c.txt | 0
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b.txt
create mode 100644 c.txt
~/dangling_tags$ git commit
[master 99b33ae] Squashed commit of the following:
2 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 b.txt
create mode 100644 c.txt
~/dangling_tags$ git branch --contains a
* master
~/dangling_tags$ git branch --contains b
feature/add_some_tags
~/dangling_tags$ git branch -D feature/add_some_tags
Deleted branch feature/add_some_tags (was 26f6611).
~/dangling_tags$ git tag
a
b
c
~/dangling_tags$ git branch --contains a
* master
~/dangling_tags$ git branch --contains b
~/dangling_tags$ for t in $(git tag); do if test "$(git branch --contains $t | wc -l)" == "0" ; then echo $t; fi done
b
c
~/dangling_tags$ git log --simplify-by-decoration --tags --not --branches --remotes --pretty=%d
(tag: c)
(tag: b)

Capistrano's /current folder always points to the same (non-existent) release

My capistrano release appears to be "sucked", since no matter how many cap production deploys I send, the /current folder is generated over and over again pointing to the same folder.
# Trying to open /current with FTP Sync
Command: CWD /public_html/storekey-demo/releases/20180813141339
Response: 550 /public_html/storekey-demo/releases/20180813141339: No such file or directory
Error: Failed to retrieve directory listing
Even after deleting the /current folder, the /releases folder, the /repo folder, the /temp folder, and the revisions.log file, and running capistrano again, the symlink is created pointing to the same folder. I think I've tried everything I can think of.
This is my deploy.rb file
lock "~> 3.11.0"
set :application, "storekey_demo" # don't use "-"
set :repo_url, "git#gitlab.com: xxxxxxxxxxx .git"
set :deploy_to, "/home/u0000000/public_html/storekey-demo"
set :tmp_dir, '/home/u0000000/public_html/tmp'
namespace :deploy do
desc "Build"
after :updated, :build do
on roles(:web) do
within release_path do
execute :composer, "install --no-dev --quiet --optimize-autoloader"
end
end
end
end
namespace :deploy do
desc "Copy Env"
after :finished, :copy do
on roles(:all) do
upload! "production.env", "#{current_path}/.env"
end
end
end
This is my deploy log, as you can see there are no errors
> cap production deploy
00:00 git:wrapper
01 mkdir -p /home/u000000000/public_html/tmp
✔ 01 u000000000#185.201.11.23 7.806s
Uploading /home/u000000000/public_html/tmp/git-ssh-storekey_demo-production-francisco.sh 100.0%
02 chmod 700 /home/u000000000/public_html/tmp/git-ssh-storekey_demo-production-francisco.sh
✔ 02 u000000000#185.201.11.23 0.445s
00:09 git:check
01 git ls-remote git#gitlab.com: xxxxxx .git HEAD
01 75bb7ded165efb968f00d29808b0673d7517aa41 HEAD
✔ 01 u000000000#185.201.11.23 1.438s
00:10 deploy:check:directories
01 mkdir -p /home/u000000000/public_html/storekey-demo/shared /home/u000000000/public_html/storekey-demo/releases
✔ 01 u000000000#185.201.11.23 0.399s
00:12 git:clone
The repository mirror is at /home/u000000000/public_html/storekey-demo/repo
00:12 git:update
01 git remote set-url origin git#gitlab.com: xxxxxxx .git
✔ 01 u000000000#185.201.11.23 0.465s
02 git remote update --prune
02 Fetching origin
✔ 02 u000000000#185.201.11.23 1.537s
00:15 git:create_release
01 mkdir -p /home/u000000000/public_html/storekey-demo/releases/20180813165948
✔ 01 u000000000#185.201.11.23 0.455s
02 git archive master | /usr/bin/env tar -x -f - -C /home/u000000000/public_html/storekey-demo/releases/20180813165948
✔ 02 u000000000#185.201.11.23 6.387s
00:23 deploy:set_current_revision
01 echo "75bb7ded165efb968f00d29808b0673d7517aa41" > REVISION
✔ 01 u000000000#185.201.11.23 0.443s
00:24 deploy:build
01 composer install --no-dev --quiet --optimize-autoloader
✔ 01 u000000000#185.201.11.23 6.045s
00:30 deploy:symlink:release
01 ln -s /home/u000000000/public_html/storekey-demo/releases/20180813165948 /home/u000000000/public_html/storekey-demo/releases/current
✔ 01 u000000000#185.201.11.23 25.267s
02 mv /home/u000000000/public_html/storekey-demo/releases/current /home/u000000000/public_html/storekey-demo
✔ 02 u000000000#185.201.11.23 0.421s
00:56 deploy:cleanup
Keeping 5 of 6 deployed releases on 185.201.11.23
01 rm -rf /home/u000000000/public_html/storekey-demo/releases/20180813164636
✔ 01 u000000000#185.201.11.23 0.543s
00:58 deploy:log_revision
01 echo "Branch master (at 75bb7ded165efb968f00d29808b0673d7517aa41) deployed as release 20180813165948 by francisco" >> /home/u000000000/publ…
✔ 01 u000000000#185.201.11.23 0.530s
00:59 deploy:copy
Uploading production.env 100.0%
It seems like the problem was in FileZilla itself, and not in capistrano.
I entered through the SSH console in my server and deleted the /current symlink, then created it again pointing to the last build, and run capistrano production deploy. The problem is fixed and changes are being deployed correctly, but FireZilla is still not recognizing the symlink correctly.

Mercurial - file history doesn't show the same change on different branches

We have had a production issue where a duplicate change was made on different branches (one of them by accident) and we didn't spot it because the Hg file history didn't show us the change on the second branch.
We have done some analysis and this is fairly easy to replicate (see simple example below). Is this is a feature or a bug?
Steps to replicate:
hg init Test
cd Test
hg branch "branch 1"
echo "file1" > test.txt
hg add
hg commit -m "Added test.txt - branch 1"
hg branch "branch 2"
echo "file2" > test.txt
hg commit -m "Updated test.txt - branch 2"
hg update "branch 1"
hg branch "branch 3"
echo "file2" > test.txt
hg commit -m "Updated test.txt - branch 3"
If we run
> hg log test.txt
Then we only get 2 changes shown in the file history - the change on branch 3 is missing.
changeset: 1:1754be7ba0aa
branch: branch 2
user: chrisgill
date: Tue Jun 06 14:30:13 2017 +0100
summary: Updated test.txt - branch 2
changeset: 0:b10c4fde7ba1
branch: branch 1
user: chrisgill
date: Tue Jun 06 14:30:13 2017 +0100
summary: Added test.txt - branch 1
But the history for the repository shows all 3 commits
> hg log
changeset: 2:f6f91ab357a6
branch: branch 3
tag: tip
parent: 0:b10c4fde7ba1
user: chrisgill
date: Tue Jun 06 14:30:14 2017 +0100
summary: Updated test.txt - branch 3
changeset: 1:1754be7ba0aa
branch: branch 2
user: chrisgill
date: Tue Jun 06 14:30:13 2017 +0100
summary: Updated test.txt - branch 2
changeset: 0:b10c4fde7ba1
branch: branch 1
user: chrisgill
date: Tue Jun 06 14:30:13 2017 +0100
summary: Added test.txt - branch 1
That is documented:
Note:
For performance reasons, 'hg log FILE' may omit duplicate changes
made on branches and will not show removals or mode changes. To see
all such changes, use the --removed switch.

How to make Mercurial detect changes made to the target of a symlink

I have a project version-controlled by the Mercurial (project main). The project references (uses) some files from another project (sub) by a symbolic link in the main pointing to a file in sub. The symbolic link is added to the main's repository.
The problem is that Mercurial doesn't detect changes made to the target file at sub, not marking the symlink as 'M' (modified).
The situation is shown in the following example:
Create, init and commit initial repos:
$ mkdir crap
$ cd crap
$ mkdir main sub
$ cd sub
$ nano sub.txt
$ hg init
$ hg add sub.txt
$ cd ../main/
$ nano main.txt
$ ln -s ../sub/sub.txt ./sub.txt
$ ls -la
total 24
drwxrwxr-x 2 ruslan ruslan 4096 Jan 15 12:51 .
drwxrwxr-x 4 ruslan ruslan 4096 Jan 15 12:48 ..
-rw-rw-r-- 1 ruslan ruslan 20 Jan 15 12:51 main.txt
lrwxrwxrwx 1 ruslan ruslan 14 Jan 15 12:51 sub.txt -> ../sub/sub.txt
$ hg init
$ hg add main.txt sub.txt
$ hg commit -m "First"
$ cd ../sub
$ hg commit -m "Sub First"
$ hg status ./sub -A
C sub/sub.txt
$ hg status ./main -A
C main/main.txt
C main/sub.txt
now modify and commit the target in sub:
$ nano ./sub/sub.txt
$ hg status ./sub -A
M sub/sub.txt
$ hg commit ./sub -m "Modified"
$ hg status ./sub -A
C sub/sub.txt
now status of the main shows that the symlink that references the target is not marked as 'M':
$ hg status ./main -A
C main/main.txt
C main/sub.txt
modifying the sub again without the commit shows 'M' in sub but not in main:
$ nano ./sub/sub.txt
$ hg status ./sub
M sub/sub.txt
$ hg status ./main -A
C main/main.txt
C main/sub.txt
How can I properly make Mercurial detect changes in symlinks' targets?
You can't. For security reasons, Mercurial never traverses symbolic links.
You can use a hard link instead by omitting -s parameter when creating with ln.
I recommend appending .hardlink to be explicit and modifying your ls to highlight hardlinks.
On a windows machine I have used same approach using
Link Shell Extension utility; I donated to the author and you should do the same :).

gitweb not seeing repository because it can't see the HEAD file?

I'm trying to get gitweb setup on a CentOS 6.2 server with git/gitweb 1.7.1 and httpd 2.2.15 installed.
gitweb's default project root (verified in the CGI script) is /var/lib/git, so I've created that and a bare git repository in there:
$ ls -laF /var/lib/git
total 12
drwxrwxr-x. 3 git git 4096 Feb 8 16:37 ./
drwxr-xr-x. 15 root root 4096 Feb 8 14:20 ../
drwxrwxr-x. 7 git git 4096 Feb 8 15:37 foo/
$ git init --bare --shared foo
Initialized empty shared Git repository in /var/lib/git/foo/
$ ls -lF foo
total 32
drwxrwsr-x. 2 git git 4096 Feb 8 17:16 branches/
-rw-rw-r--. 1 git git 126 Feb 8 17:16 config
-rw-rw-r--. 1 git git 73 Feb 8 17:16 description
-rw-rw-r--. 1 git git 23 Feb 8 17:16 HEAD
drwxrwsr-x. 2 git git 4096 Feb 8 17:16 hooks/
drwxrwsr-x. 2 git git 4096 Feb 8 17:16 info/
drwxrwsr-x. 4 git git 4096 Feb 8 17:16 objects/
drwxrwsr-x. 4 git git 4096 Feb 8 17:16 refs/
$ cat foo/HEAD
ref: refs/heads/master
However on viewing http://localhost/git/, I see "404 No projects found".
I've debugged through the script and can see that it's finding /var/lib/git/foo, but Perl's -e operator fails on /var/lib/git/foo/HEAD. At the same place in the file, a backticked call to ls shows that the file is visible there, but I cannot make Perl -e see the file.
Any idea what might be making this fail? This makes no sense to me.
EDIT: note that SELinux extensions on this CentOS box appear to be disabled:
$ sudo sestatus
SELinux status: disabled
EDIT: moving everything from /var/lib/git to /git hasn't helped. I've changed the apache user to have a real shell, logged in as that user, and verified that it has access to all the directories and files in question.
It was in fact SELinux. Even though SELinux reported it was disabled, it was somehow preventing access to some files for CGI scripts running under httpd. Enabling SELinux and setting it to permissive mode, it started working.
This seems highly non-intuitive and frustrates me, but at least it's working.
I'm still thinking it's an issue with permissions... but I could be wrong. Have you ensured that all of the parent directories leading up to your /var/lib/git directory are permission-accessible?
Someone else had a similar problem here and it might be worth trying a completely different directory... maybe even /opt.