I regularly use the following git-log command:
git log --oneline --graph --decorate --all
The command is perfect for me, with one exception. I maintain a set of refs in refs/arch/ that I want to keep around ("arch" stands for "archive"), but I do not want to see them every time I look at my git log. I don't mind them showing up if they are an ancestor of an existing branch or tag, but I really do not want to see series of commits that would not otherwise show up in the git log but for the fact that they are in the commit history of a given refs/arch/* ref.
For example, in the image below, the left-hand side is an illustration of what I see currently when I run git log --oneline --graph --decorate --all. As you can see, the commit referred to by refs/arch/2 would not show up in the log if that ref didn't exist. (Assume there are no refs that are not shown in the left-hand side image.) Now, the right-hand side is an illustration of two alternative log graphs, either of which would be perfectly fine. I don't mind seeing anything matching refs/arch/* so long as it is in the commit history of a branch or tag. But, in the image below, I definitely do not want to see the commit referred to by refs/arch/2.
How can my git-log command be modified to suppress refs/arch/* in either of the senses depicted in the illustration?
What you want is:
git log --oneline --graph --decorate --exclude 'refs/arch/*' --all
The --exclude option is new in git 1.9.0.
From the git-log manual page:
--exclude=<glob-pattern>
Do not include refs matching <glob-pattern> that the next --all, --branches, --tags, --remotes, or --glob would otherwise consider. Repetitions of this option accumulate exclusion patterns up to the next --all, --branches, --tags, --remotes, or --glob option (other options or arguments do not clear accumlated patterns).
The patterns given should not begin with refs/heads, refs/tags, or refs/remotes when applied to --branches, --tags, or --remotes, respectively, and they must begin with refs/ when applied to --glob or --all. If a trailing /* is intended, it must be given explicitly.
If you are on some flavor of Ubuntu you can upgrade git from the Ubuntu Git Maintainers team ppa.
sudo add-apt-repository ppa:git-core/ppa
sudo apt-get update
sudo apt-get upgrade
Related
I want to move all the files with extension "gz", with his folder/subfolders of the dir "C:\GCPUpload\Additional" to a folder in the bucket "gs://BucketName/Additional/".
I need to keep the folder structure, in a way like this:
C:\GCPUpload\Additional\Example1.gz --> gs://BucketName/Additional/Example1.gz
C:\GCPUpload\Additional\Example2.gz --> gs://BucketName/Additional/Example2.gz
C:\GCPUpload\Additional\ExampleNot.txt --> (Ignore this file)
C:\GCPUpload\Additional\Subfolder2\Example3.gz --> gs://BucketName/Additional/Subfolder2/Example3.gz
C:\GCPUpload\Additional\Subfolder2\Example4.gz --> gs://BucketName/Additional/Subfolder2/Example4.gz
This is the command that I am using so far:
call gsutil mv -r -c "C:\GCPUpload\Additional\**\*.gz" "gs://BucketName/Additional/"
The trouble that I'm having is that all the files are being move to the root of the bucket (i.e gs://BucketName/Additional/) , and ignoring its original folder/subfolder
How should I write this? I've tried and googled, but can't find a way where this is working.
Thanks!!
The behavior you're seeing was implemented by gsutil to match the corresponding (older) behavior when you use a recursive wildcard (**) in the shell.
To do what you want you'll need to list all of the objects you want moved and create a shell script that individually runs gsutil mv commands that move them to the directories you want. You could probably use local editing tools to make that somewhat easier (like awk or sed).
I use wget as part of script to fetch a URL eg. "www.myremoteurl.com/subpage/index-X.run", but X is a integer that keeps incrementing/changing breaking the script as the resource will not have existed.
ok, then, it's easy!, as you imaged
#!/bin/sh
for i in {1..10}
do
wget www.someurl/someindex-$i.run &
done
this would loop from 1 to 10 and ignore any failure, should be handy for some normal cases
I am using Django translations for a project, and would like to ensure, on TravisCI, that translations are not left behind when changes are made to translatable strings.
This is a simplified snippet of my .travis.yml:
script:
- ...
- python manage.py makemessages -l ja --no-wrap --no-location
- git diff --exit-code
That recreates the PO files, and fails when the file changes. So far so good.
Unfortunately, django updates the POT-Creation-Date every time the script is run, and I can't see any flags to makemessages that would disable that, so even if there are no changes, the file changes on every run.
Am I on the right lines, or is there a better way to detect that there has been a change?
So, after makemessages diff will allways show at least 1 insert and 1 deletion, right?
git diff --numstat | awk '{if ($1>1 || $2>1) { exit 1 } else { exit 0 }}'
This script should exit with status=1 if there is more than 1 insert and 1 deletion in diff.
Git now has a nice way to ignore specific matches. The following line will fail if there is a diff, but exclude the problematic header:
git diff --ignore-matching-lines=POT-Creation-Date --exit-code
What's better, Django recently merged a change to stop this header from getting updated when there are no changes to the translations. It hasn't been released as of Django 4.0, so I expect it will arrive in Django 4.1.
See Django bug #6106 and the commit that fixes this issue.
Reading http://www.ember-cli.com/#pod-structure
Lets say I have a product resource. Which currently has the following directory structure:
app/controllers/products/base.js
app/controllers/products/edit.js
app/controllers/products/new.js
app/controllers/products/index.js
With pods all the logic in these files are put in a single file app/products/controller.js?
At the same time, my routes and templates for these resources currently look like:
app/routes/products/base.js
app/routes/products/edit.js
app/routes/products/new.js
app/routes/products/index.js
app/templates/products/-form.hbs
app/templates/products/edit.hbs
app/templates/products/index.hbs
app/templates/products/new.hbs
app/templates/products/show.hbs
How should this be converted to Pods?
You can use ember generate --pod --dry-run to help with that:
$ ember g -p -d route products/base
version: 0.1.6
The option '--dryRun' is not supported by the generate command. Run `ember generate --help` for a list of supported options.
installing
You specified the dry-run flag, so no changes will be written.
create app/products/base/route.js
create app/products/base/template.hbs
installing
You specified the dry-run flag, so no changes will be written.
create tests/unit/products/base/route-test.js
$
(I don't know why it complains yet it honours the option, might be a bug).
So you'd end up with a structure like:
app/controllers/products/base/route.js
app/controllers/products/edit/route.js
etc.
We are having problems in synchronizing our PO files with Pootle:
Lost translations
The first problem we encountered was that of lost translations. After doing an update_stores, some of our translations would be missing in Pootle. We have tried to remedy this with using the --keep option, but this had the adverse effect of not removing obsolete translations. We would like Pootle to hide obsolete translations, but not throw them away (the translation is obsolete, but still valid). Our current solution to this problem is to call sync_stores with the --overwrite option before calling make_messages
Wrong translations, not marked as fuzzy
When we add a new message id to the PO file, Pootle will sometimes translate the message (using a bad translations, probably found using fuzzy matching) without activating the fuzzy flag.
Our current work-flow for synchronizing Pootle and our PO files is:
(adding new messages to pootle)
1. call "pootle sync_stores --overwrite" to update local po files with pootle contents
2. call "python manage.py makemessages -a" to add new messages to the po files
3. call "pootle update_stores" to import the latest po files in pootle
4. call "pootle update_translation_projects" to refresh pootle views
(updating po files with pootle contents)
5. call "pootle sync_stores --overwrite" to update local po files with pootle contents
6. call "python manage.py compilemessages" to create the mo files
The above tricks have reduced the number of errors somewhat, but we are still experiencing the above mentioned problems. Have you found similar problems? Have you been able to solve them?