I once saw (can't remember where) a lint check in a file that looked something like:
"If this file is modified, I will complain if files /somehwere/a and /somehwere/b aren't modified in the same commit".
Do you know of any linter capable of handling something like this? Maybe not a linter but something that can be integrated to a github repo?
If you have a CI system set up for your repository, you can run a command like the following, which will exit nonzero if there's a problem commit, and zero if all commits are fine (with $BASE and $HEAD set appropriately):
git rev-list $BASE..$HEAD | \
xargs -L1 sh -c 'lines=$(git show --name-only $0 | grep -e somewhere/a -e somewhere/b | wc -l); \
test $lines -ne 1 || { echo "bad commit $0"; false; }'
Any suitable CI system can test this by running a shell script and failing if it exits nonzero.
Related
I'd like to create a zsh widget to perform common tasks of a version control systems with a single button. E.g. pressing F1 should call "svn status", if the current directory is part of a Subversion checkout. If it is in a git repository, it should call "git status -s".
Now, creating the widget is no big deal. But how do I determine which VCS is in the current directory?
I know about vcs_info and I use a lot. But I couldn't find any way to retrieve the most basic information, it provides. Any ideas?
What about testing the existence of the specific meta data directories?
if test -d CVS; then
# CVS
elif test -d .hg; then
# Mercurial
elif test -d .git; then
# Git
elif test -d .svn; then
# Subversion
else
# unknown
fi
Thanks to all for comments. My solution now looks like this:
vcs-status() {
setopt no_autopushd
cmd=""
cur_dir=`pwd`
while [[ `pwd` != "/" ]]; do
if [[ -d .svn ]]; then
cmd="svn status^M"
break
elif [[ -d .git ]]; then
cmd="git status -s^M"
break
fi
cd ..
done
cd $cur_dir
if [[ -n $cmd ]]; then
zle -U $cmd
fi
setopt autopushd
}
zle -N vcs-status
bindkey "\eOP" vcs-status
Suggestions to cool zsh'ish improvements are welcome :-)
I also implemented the suggestion of Thomas, using svn info and git rev-parse. But then I noticed a problem: If I have an SVN working copy checked out somewhere inside a GIT working copy (yes, this is necessary occationally), or vice versa, I would only find the first one I'm checking. With the solution above, I find the "inner-most", which is what I want. In fact, this is a problem that also has been annoying me about vcs_info for a while.
I have looked at different ways of doing this using diff. The first option I tried is:
p4 diff -sa
Opened files that are different from the revision in the depot, or missing.
Initially I figured that this was a file with write permission bit set that did not exist in the depot. However, I have since learned p4 doesn't use mode bits to track opened/unopened states as I first thought.
Next I figured this option would work:
p4 diff -sl
Every unopened file, along with the status of 'same', 'diff' or 'missin' as compared to its revision in the depot.
This would be okay, except "unopened" is not inclusive of "untracked" files. Although, when I ran this, it produced something quite different that contradicts the documentation; it output pretty much everything that was tracked, but also output everything that wasn't tracked, but flagged them as 'same'. Maybe this means that it hasn't been added and doesn't exist in the depot, so the client is the same as the depot...? In my SVN biased opinion, a rather pointless option.
Then there is the 'opened' option. But this does exactly that. It lists all the files in the depot that have been opened on the client; so not the files modified on the client not yet added.
So is there an option I am missing somewhere, that will provide some valuable answer, like SVN and CVS are able to do with one simple command?
$ svn status
A added
M modified
R deleted
? untracked
L locked
C conflict
Or:
$ cvs -q up -Pd
Okay, looking around and playing with the 'add' command, it seems that a read-only add will output successful message if the file is not currently controlled:
$ p4 add -n -f somefile
//source/somefile#1 - opened for add
I applied this to the following command and pretty much get what I need:
$ find . -type f | while read f ; do p4 add -f -n "$f" | grep -e '- opened for add' >/dev/null && echo "A $f"; done
A ./somefile
Or if you're not bothered about local paths:
$ find . -type f | xargs -l1 p4 add -f -n | grep -e '- opened for add'
//source/somefile#1 - opened for add
Well, there exists "p4 status", which is very similar in both purpose and behavior to "svn status".
For more ideas, see: http://answers.perforce.com/articles/KB_Article/Working-Disconnected-From-The-Perforce-Server
When I check out a file with git checkout $commit $filename and I forget $commit but still remember $filename, how do I find out what $commit was?
First a non-git answer. Check your shell command history. Well, if you didn't use a shell with command history then you don't...
The git answer. You generally cannot find THE $commit. Generally the same contents might have been part of many commits and I don't think git keeps a log of what single file you have checked out (it keeps a log of previous values of HEAD)
Here is a brute force script git-find-by-contents. Call it with your $filename as parameter, and it will show you all commits where this file was included. As the name says
it searches by contents. So it will find files with any name, as long as the contents matches.
#! /bin/sh
tmpdir=/tmp/$(basename $0)
mkdir $tmpdir 2>/dev/null
rm $tmpdir/* 2>/dev/null
hash=$(git hash-object $1)
echo "finding $hash"
allrevs=$(git rev-list --all)
# well, nearly all revs, we could still check the log if we have
# dangling commits and we could include the index to be perfect...
for rev in $allrevs
do
git ls-tree --full-tree -r $rev >$tmpdir/$rev
done
cd $tmpdir
grep $hash *
rm -r $tmpdir
I would not be surprised if there is a more elegant way, but this has worked for me a couple of times in similar situations.
EDIT: a more techy version of the same problem appears here: Which commit has this blob?
I don't think you can. Git just loads that version of the file into the index and your working dir. There is no reference keeping track of what version it loaded
If this is something that you do often, you could write up a script that could do it using git diff --cached and march through all the commits that changed that file.
You can use
git log <filename>
to find out which commit you want to checkout
If you're lucky, you could maybe try a non-git way:
history | grep "git checkout.*filename"
Try this (untested ;):
$ for commit in $(git log --format=%h $filename); do
> if diff <(git show $commit:$filename) $filename >/dev/null; then
> echo $commit
> fi
> done
Simple and elegant:
$ git log -S"$(cat /path/to/file)"
Only works if the content is unique, then again that's the same for the hash-comparison answers that came before.
It also displays only the first version that matches, rather than all.
Here are the details of a script I polished up as the answer to a similar question, and here you can see it in action:
(source: adamspiers.org)
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
Let's say I checked in a changelist (in Perforce) with lots of files and I'd like to revert the entire changelist. Is there an easy way to "revert" the entire changelist in one fell swoop?
Currently I do something like this for each file in the changelist:
p4 sync //path/to/file#n (where "n" is the previous version of the file)
cp file file#n
p4 sync //path/to/file
p4 edit //path/to/file
cp file#n file
rm file#n
As you can imagine, this is quite cumbersome for a large changelist.
The posted answers provide correct answers, but note also that there is an actual menu option in P4V to do this for you now. It's in the latest 2008.2 Beta, and so should be officially released the the next week or three.
This link gives details.
It should be a lot simpler to use than the earlier answers, but I've not had the opportunity to try it myself yet.
Update This has now been fully released. See Perforce downloads.
This looks interesting. I haven't tried it personally.
The official answer from Perforce is at http://kb.perforce.com/UserTasks/ManagingFile..Changelists/RevertingSub..Changelists but the procedure is not all that much easier than the one you suggest. The script suggested by #ya23 looks better.
For some reason, the awk step does not work for me. I'm running from a Windows environment with emulated Unix command line tools. However, the following does work:
p4 describe -s [changelist_number] | grep // | sed "s/\.\.\. //" | sed "s/#.*//" | p4 -ztag -x - where | grep "... path " | sed "s/\.\.\. path //"
Here are possible locations to get Unix command line tools in a Windows environment:
http://sourceforge.net/projects/getgnuwin32/?source=typ_redirect
http://unxutils.sourceforge.net/
I have the same problem when I want to delete an entire changelist. so I use the following script (notice that it also deletes the changelist's shelve and the changelist itself. if you only want to revert, copy the relevant lines).
Also, make sure the sed applies to your version of p4.
#!/bin/bash
set -e
if [[ $# -ne 1 ]]; then
echo "usage: $(basename $0) changelist"
exit 1
fi
CHANGELIST=$1
#make sure changelist exist.
p4 describe -s $CHANGELIST > /dev/null # set -e will exit automatically if fails
p4 shelve -d -c $CHANGELIST 2> /dev/null || true # changelist can be shelveless
files_to_revert=$(p4 opened 2> /dev/null | grep "change $CHANGELIST" | sed "s/#.*//g")
if [[ -n "$files_to_revert" ]]; then
p4 revert $files_to_revert
fi
p4 change -d $CHANGELIST
The problem starts when you want to revert an entire changelist ( as a bulk ) that you've just submitted, and you need to start reverting files of #n-1 one by one fast ( because it's production ) ...
Wanted to support ya23's answer- the link of a Python script - it's really really easy to use ( and really easy to miss his comment )
You give it the revision you want to rollback, and it prepares everything automatically ( each file's #n-1 & merging and everything ) ... you just submit.