Hey I am using bazaar for my code, I wanna show the history of changes to a specific file, instead of showing changes to the whole bazaar repo. How could I do it?
bzr blame <filename> will show you which lines were introduced with which changes:
$ bzr blame Makefile
548 steve-b | #
| #
861 steve-b | OVERRIDE_TARBALL=yes
548 steve-b |
| include common/Make.rules
|
| DIRS=parser \
| profiles \
| utils \
| changehat/libapparmor \
| changehat/mod_apparmor \
| changehat/pam_apparmor \
| tests
If you just want the commit messages, bzr log <filename> will show you:
$ bzr log Makefile
------------------------------------------------------------
revno: 1828
tags: apparmor_2.7.0-beta2
committer: John Johansen <john.johansen#canonical.com>
branch nick: apparmor
timestamp: Thu 2011-09-15 13:28:01 -0700
message:
Remove extra space insert at from of ${TAG_VERSION} when doing the ~ to -
substitution.
Signed-off-by: John Johansen <john.johansen#canonical.com>
------------------------------------------------------------
revno: 1734
committer: Steve Beattie <sbeattie#ubuntu.com>
branch nick: apparmor
timestamp: Thu 2011-06-02 18:54:56 -0700
message:
This patch adjusts the tag make target to use a separate version with
'~' replaced by '-'. This is needed for mirroring to git as git can't
handle '~'s embedded in tag or branch names.
Tested by setting up a separate tag_version target like so:
tag_version:
echo ${TAG_VERSION}
...
bzr log is the key.
Purpose: Show historical log for a branch or subset of a branch.
Usage: bzr log [FILE...]
If you use a gui (TortoiseBzr of BzrExplorer), select the file and clic on log command.
Related
I'm setting up continuous deployment with github actions which I want to run every time a tag is created.
However I only want to deploy if there has not been a major bump (Using semver for versions) since the last tag.
I have only been able so far to find actions/examples that get the current tag, not the one before. like (https://github.com/WyriHaximus/github-action-get-previous-tag)
How would I do this?
Edit: (thanks for the tip on git fetch -a) I managed to get it working with git tag and cut
- name: Get major of current tag and previous tag
id: vars
run: |
git fetch -a
echo ::set-output name=current_major::$(git tag --sort "-committerdate" | cut -d$'\n' -f1 | cut -d. -f1)
echo ::set-output name=previous_major::$(git tag --sort "-committerdate" | cut -d$'\n' -f2 | cut -d. -f1)
I checked out a project from an internal GitLab server using Eclipse, then I pulled all the changes. When I view the history from Eclipse. (Team > show in history), it displays the full history of the project.
Now I go to the relevant project from the terminal.
/home/workspace/ProjectX/
I am trying to get the differences between 2 dates with the following command:
git diff --name-only master#{2015-10-10}..master#{2015-11-10} > /home/results/ProjectX/Changes.txt
It wont display any result for that. It displays:
warning: Log for 'master' only goes back to Tue, 10 Nov 2015.
How can I get all the differences in that date range?
In addition to that, how does Eclipse request its history from the remote server. If we can run the same command from the terminal, that should work.
Git parses dates like master#{2015-10-10} using your reflog, which doesn't appear to go back as far as you're searching. But, you can find commits for that date range anyway with rev-list:
git rev-list --since='2015-10-10' --until='2015-11-10' master
You want the files changes between the most recent and the oldest commit in that list, which we can get using head and tail. I'd like to use -n1 and --reverse, but --reverse applies after -n, so we can't.
first=$(git rev-list --since='2015-10-10' --until='2015-11-10' master | tail -1)
last=$(git rev-list --since='2015-10-10' --until='2015-11-10' master | head -1)
git diff --name-only $first..$last
Setting variables and duplicating the rev-list feels clumsy, but the pipe-y version I can come up with is sort of worse. It picks the first and last commits, converts the newline to a space using tr, replaces the new space with .. using sed, then passes the pair off to git diff.
git rev-list --since='2015-10-10' --until='2015-11-10' master | \
(head -n1 && tail -n1) | \
tr '\n' ' ' | \
sed 's/ /../' | \
xargs git diff --name-only
I want to add a hook that logs something to the effect of "Hey, I'm about to deploy such-and-such commit." Something like:
before "deploy:update_code" do
logger.info "Deploying #{revision}"
end
Except "revision" in this context seems to yield a ref name (i.e. "master") rather than a commit ID. What construct can I use to get the sha1?
To get the ref, you'll need to shell out to Git:
Here's an example from one of my own projects, where master is fully up-to-date and pushed, and my clean_architecture branch isn't.
~/api git:(clean_architecture) $ git show-ref master
349dabbffec0713ac0fc70cf991dbaff6412ad2b refs/heads/master
349dabbffec0713ac0fc70cf991dbaff6412ad2b refs/remotes/origin/master
~/api git:(clean_architecture) $ git show-ref clean_architecture
14afae560ace128a13336ca01ff2391b678fadaf refs/heads/clean_architecture
bc78906ad0b2814dbc6225b2e14155b66eedffd0 refs/remotes/origin/clean_architecture
Taking that on-board, I'd suggest something like the following to grab the remotely pushed ref hash (as that's the only one the Capistrano 3 can see, Capistrano will do a check like this internally, but you can't access the ref, and will complain if these two values differ, anyway)
First, on the command line:
$ git show-ref clean_architecture | tail -1 | cut -f1 -d ' '
bc78906ad0b2814dbc6225b2e14155b66eedffd0
$ git show-ref clean_architecture | tail -1 | awk '{print $1}'
bc78906ad0b2814dbc6225b2e14155b66eedffd0
(there's about a million ways to do this on linux)
Secondly in Ruby:
$ irb --simple-prompt
>> `git show-ref #{fetch(:branch)}`
=> "349dabbffec0713ac0fc70cf991dbaff6412ad2b refs/heads/master\n349dabbffec0713ac0fc70cf991dbaff6412ad2b refs/remotes/origin/master\n"
Which let's us know we can split this up really easily in Ruby land, and not need cut or awk:
$ irb --simple-prompt
>> `git show-ref #{fetch(:branch)}`.split.first
That should be pretty close, and pretty-portable (where as cut and awk, and splitting that up in the shell with pipes, etc is quite *nix specific and unlikely to work well on Windows)
Drop that in your before task, and you should be set.
I've finished working on a feature branch feature-x. I want to merge results back to the default branch and close feature-x in order to get rid of it in the output of hg branches.
I came up with the following scenario, but it has some issues:
$ hg up default
$ hg merge feature-x
$ hg ci -m merge
$ hg up feature-x
$ hg ci -m 'Closed branch feature-x' --close-branch
So the feature-x branch (changests 40-41) is closed, but there is one new head, the closing branch changeset 44, that will be listed in hg heads every time:
$ hg log ...
o 44 Closed branch feature-x
|
| # 43 merge
|/|
| o 42 Changeset C
| |
o | 41 Changeset 2
| |
o | 40 Changeset 1
|/
o 39 Changeset B
|
o 38 Changeset A
|
Update: It appears that since version 1.5 Mercurial doesn't show heads of closed branches in the output of hg heads anymore.
Is it possible to close a merged branch without leaving one more head? Is there more correct way to close a feature branch?
Related questions:
Is there a downside to this Mercurial workflow: named branch "dead" head?
One way is to just leave merged feature branches open (and inactive):
$ hg up default
$ hg merge feature-x
$ hg ci -m merge
$ hg heads
(1 head)
$ hg branches
default 43:...
feature-x 41:...
(2 branches)
$ hg branches -a
default 43:...
(1 branch)
Another way is to close a feature branch before merging using an extra commit:
$ hg up feature-x
$ hg ci -m 'Closed branch feature-x' --close-branch
$ hg up default
$ hg merge feature-x
$ hg ci -m merge
$ hg heads
(1 head)
$ hg branches
default 43:...
(1 branch)
The first one is simpler, but it leaves an open branch. The second one leaves no open heads/branches, but it requires one more auxiliary commit. One may combine the last actual commit to the feature branch with this extra commit using --close-branch, but one should know in advance which commit will be the last one.
Update: Since Mercurial 1.5 you can close the branch at any time so it will not appear in both hg branches and hg heads anymore. The only thing that could possibly annoy you is that technically the revision graph will still have one more revision without childen.
Update 2: Since Mercurial 1.8 bookmarks have become a core feature of Mercurial. Bookmarks are more convenient for branching than named branches. See also this question:
Mercurial branching and bookmarks
imho there are two cases for branches that were forgot to close
Case 1:
branch was not merged into default
in this case I update to the branch and do another commit with --close-branch, unfortunatly this elects the branch to become the new tip and hence before pushing it to other clones I make sure that the real tip receives some more changes and others don't get confused about that strange tip.
hg up myBranch
hg commit --close-branch
Case 2:
branch was merged into default
This case is not that much different from case 1 and it can be solved by reproducing the steps for case 1 and two additional ones.
in this case I update to the branch changeset, do another commit with --close-branch and merge the new changeset that became the tip into default. the last operation creates a new tip that is in the default branch - HOORAY!
hg up myBranch
hg commit --close-branch
hg up default
hg merge myBranch
Hope this helps future readers.
EDIT ouch, too late... I know read your comment stating that you want to keep the feature-x changeset around, so the cloning approach here doesn't work.
I'll still let the answer here for it may help others.
If you want to completely get rid of "feature X", because, for example, it didn't work, you can clone. This is one of the method explained in the article and it does work, and it talks specifically about heads.
As far as I understand you have this and want to get rid of the "feature-x" head once and for all:
# changeset: 7:00a7f69c8335
|\ tag: tip
| | parent: 4:31b6f976956b
| | parent: 2:0a834fa43688
| | summary: merge
| |
| | o changeset: 5:013a3e954cfd
| |/ summary: Closed branch feature-x
| |
| o changeset: 4:31b6f976956b
| | summary: Changeset2
| |
| o changeset: 3:5cb34be9e777
| | parent: 1:1cc843e7f4b5
| | summary: Changeset 1
| |
o | changeset: 2:0a834fa43688
|/ summary: Changeset C
|
o changeset: 1:1cc843e7f4b5
| summary: Changeset B
|
o changeset: 0:a9afb25eaede
summary: Changeset A
So you do this:
hg clone . ../cleanedrepo --rev 7
And you'll have the following, and you'll see that feature-x is indeed gone:
# changeset: 5:00a7f69c8335
|\ tag: tip
| | parent: 4:31b6f976956b
| | parent: 2:0a834fa43688
| | summary: merge
| |
| o changeset: 4:31b6f976956b
| | summary: Changeset2
| |
| o changeset: 3:5cb34be9e777
| | parent: 1:1cc843e7f4b5
| | summary: Changeset 1
| |
o | changeset: 2:0a834fa43688
|/ summary: Changeset C
|
o changeset: 1:1cc843e7f4b5
| summary: Changeset B
|
o changeset: 0:a9afb25eaede
summary: Changeset A
I may have misunderstood what you wanted but please don't mod down, I took time reproducing your use case : )
It is strange, that no one yet has suggested the most robust way of closing a feature branches...
You can just combine merge commit with --close-branch flag (i.e. commit modified files and close the branch simultaneously):
hg up feature-x
hg merge default
hg ci -m "Merge feature-x and close branch" --close-branch
hg branch default -f
So, that is all. No one extra head on revgraph. No extra commit.
I have a legacy CVS repository which shall be migrated to Perforce.
For each module, I need to identify what branches exist in that module.
I just want a list of branch names, no tags.
It must be a command line tool, for scripting reasons.
For example (assuming there is a cvs-list-branches.sh script):
$ ./cvs-list-branches.sh module1
HEAD
dev_foobar
Release_1_2
Release_1_3
$
As a quick hack:) The same stands true for rlog.
cvs log -h | awk -F"[.:]" '/^\t/&&$(NF-1)==0{print $1}' | sort -u
Improved version as per bdevay, hiding irrelevant output and left-aligning the result:
cvs log -h 2>&1 | awk -F"[.:]" '/^\t/&&$(NF-1)==0{print $1}' | awk '{print $1}' | sort -u
You could simply parse log output of cvs log -h. For each file there will be a section named Symbolic names :. All tags listed there that have a revision number that contains a zero as the last but one digit are branches. E.g.:
$ cvs log -h
Rcs file : '/cvsroot/Module/File.pas,v'
Working file : 'File.pas'
Head revision : 1.1
Branch revision :
Locks : strict
Access :
Symbolic names :
1.1 : 'Release-1-0'
1.1.2.4 : 'Release-1-1'
1.1.0.2 : 'Maintenance-BRANCH'
Keyword substitution : 'kv'
Total revisions : 5
Selected revisions : 0
Description :
===============================================
In this example Maintenance-BRANCH is clearly a branch because its revision number is listed as 1.1.0.2. This is also sometimes called a magic branch revision number.
This will bring up tags too, but tags and branches are basically the same in CVS.
$cvs.exe rlog -h -l -b module1
I have a small collection of "handy" korn shell functions one of which fetches tags for a given file. I've made a quick attempt to adapt it to do what you want. It simply does some seding/greping of the (r)log output and lists versions which have ".0." in them (which indicates that it's a branch tag):
get_branch_tags()
{
typeset FILE_PATH=$1
TEMP_TAGS_INFO=/tmp/cvsinfo$$
/usr/local/bin/cvs rlog $FILE_PATH 1>${TEMP_TAGS_INFO} 2>/dev/null
TEMPTAGS=`sed -n '/symbolic names:/,/keyword substitution:/p' ${TEMP_TAGS_INFO} | grep "\.0\." | cut -d: -f1 | awk '{print $1}'`
TAGS=`echo $TEMPTAGS | tr ' ' '/'`
echo ${TAGS:-NONE}
rm -Rf $TEMP_TAGS_INFO 2>/dev/null 1>&2
}
with Wincvs (Gui client for windows) this is trivial, a right click will give you any branches and tags the files have.
Trough a shell you may use cvs log -h -l module.
Check for the very first file created and committed in the repository. Open the file in server which will list all the Tags and Branches together