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.
Related
I have a workflow like this, where myFile.js is updating one file
- name: Custom action
run: yarn myFile.js
- name: Commit diff
run: |
git add .
git status
git commit -m "Updating file"
git status
git push -u origin origin/${{ github.head_ref }}
Here is the output (successful)
git add .
git status
git commit -m "Updating file"
git status
git push -u origin origin/Feature/custom-patch
git status
shell: /usr/bin/bash -e {0}
env:
NODE_OPTIONS: --max_old_space_size=4096
HEAD detached at pull/95/merge
Changes to be committed:
(use "git restore --staged <file>..." to unstage)
modified: src/123.json
[detached HEAD 9c7a0fd55] Updating file
1 file changed, 2 insertions(+), 2 deletions(-)
HEAD detached from pull/95/merge
nothing to commit, working tree clean
To https://github.com/company/myRepo
35ae5b522..755d05e91 origin/Feature/custom-patch -> origin/Feature/custom-patch
HEAD detached from pull/95/merge
nothing to commit, working tree clean
You need to tell the checkout action to fetch the whole state of commits and tell it specifically to checkout the branch.
Otherwise by default it just checks out the single last commit (which is called a detached HEAD).
- uses: actions/checkout#v2
with:
fetch-depth: 0
ref: ${{ github.event.pull_request.head.ref }}
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)
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.
I have edited some files in the repo and now it looks like the following:
history1 --> history2 --> ... --> master
\
\
my commit 1 --> my commit 2
But actually 'my commit 2' should not be on top of 'my commit 1', that's a mistake... How do I only rebase 'my commit 2' to master in mercury?
history1 --> history2 --> ... --> master
\ \
\ \
my commit 1 my commit 2
I am asking how to do this in Mercurial not git.
Make sure you have the rebase extension enabled in your hgrc file. Then:
$ hg rebase -r <commit ID of my commit 2> -d master
See "hg help rebase" for more details.
From a different post:
You can cherry-pick XX to master.
git checkout master
git cherry-pick <commit ID of XX>
And remove the last commit from the feature branch with git reset.
git checkout Feature-branch
git reset --hard HEAD^
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