Ετήσια αρχεία: 2017


How to add untracked files to a git patch

Recently, we had to create a git patch for the deployment of a 3rd party repository in our code.
Some of the changes we had to apply using the patch mechanism was the creation of a few new files.
We did not want to have an external script to copy the new files to the appropriate locations, so we had to include those new files in the git patch somehow.
The git diff command (with the parameter -p or --patch) that generates the patch, it ignored the untracked files and so they did not appear in the patch.
To make the untracked files visible to the git diff command, we staged them (using git add) and then used the following command to create the patch:


git diff --patch --staged;

git diff [--options] --cached [<commit>] [--] [<path>...]
git diff [--options] --staged [<commit>] [--] [<path>...]
Adding the parameter --staged or --cached allows you to view the changes you staged for the next commit relative to the named <commit>. Typically you would want comparison with the latest commit, so if you do not give <commit>, it defaults to HEAD. If HEAD does not exist (e.g. unborned branches) and <commit> is not given, it shows all staged changes. --staged is a synonym of --cached.
From: man git-diff

In the end our commands to create the patch with the new files and apply it on a new clone of the 3rd party repository was as follows:


#In the folder of the modified repository, where the new files are staged
git diff -p --staged > ~/new.file.patch.diff;
#In the folder of the new clone of the repository, where the new files need to be created
git apply ~/new.file.patch.diff;


Ignore all edits to a file that is committed in git

Recently, we were working on a project that had committed in the source code a configuration file. That configuration file had hard-coded the production system values, so we had to modify them to the development system values before using it.

To avoid committing the configuration file with the development parameters by accident, we instructed git to ignore any changes that were made to it using the following command.


git update-index --assume-unchanged <file>;

By doing so, git assumed that the file was always unchanged and it never showed up in the git status results nor was staged when git add . was used etc.

After we were done with development (and whenever we needed to pull the branch for changes or checkout another branch) we removed the file from the list of ignored files using the following command.


git update-index --no-assume-unchanged <file>;

Using this command, git would start again to monitor changes to the file and merge it or update it or push it when needed as it would normally do for any file not included in the .gitignore file. The best part of this trick is that you do not have to update the .gitignore file to achieve the task of ignoring a file.

More information

git update-index modifies the index or directory cache. Each file mentioned is updated into the index and any unmerged or needs updating state is cleared.

--[no-]assume-unchanged When these flags are specified, the object names recorded for the paths are not updated. Instead, these options set and unset the “assume unchanged” bit for the paths. When the “assume unchanged” bit is on, Git stops checking the working tree files for possible modifications, so you need to manually unset the bit to tell Git when you change the working tree file. This is sometimes helpful when working with a big project on a filesystem that has very slow lstat(2) system call (e.g. cifs).

This option can be also used as a coarse file-level mechanism to ignore uncommitted changes in tracked files (akin to what .gitignore does for untracked files). Git will fail (gracefully) in case it needs to modify this file in the index e.g. when merging in a commit; thus, in case the assumed-untracked file is changed upstream, you will need to handle the situation manually.

From: man git-update-index

Bonus

In case you are wondering on how to see which files are currently ignored in your local repository copy by the git update-index --assume-unchanged <file>; command, you can use the following code:


git ls-files -v | grep -e '^[[:lower:]]';

git ls-files -v will print out all objects that git knows and the -v parameter will print all flags associated with them. The files that are ignored because of the
git update-index --assume-unchanged <file>; command will be printed each one on a different line that starts with a lower case character. So, to get all files that are ignored by the git update-index --assume-unchanged <file>; command, we need to grep the results of git ls-files -v for lines that start with a lower case.

git-ls-files shows information about files in the index and the working tree.
It merges the file listing in the directory cache index with the actual working directory list, and shows different combinations of the two.

-v Similar to -t (below), but use lowercase letters for files that are marked as assume unchanged (see git-update-index(1)).

-t This feature is semi-deprecated. For scripting purpose, git-status(1)–porcelain and git-diff-files(1)–name-status are almost always superior alternatives, and users should look at git-status(1)–short or git-diff(1)–name-status for more user-friendly alternatives.
This option identifies the file status with the following tags (followed by a space) at the start of each line:

An additional interesting parameter for git ls-files is
-i, --ignored Shows only ignored files in the output. When showing files in the index, it prints only those matched by an exclude pattern. When showing “other” files, it shows only those matched by an exclude pattern.

--exclude-standard Add the standard Git exclusions: .git/info/exclude, .gitignore in each directory, and the user’s global exclusion file.
From: man git-ls-files

Examples for git ls-files -i, –ignored and –exclude-standard


# Show files in the index that are ignored because of patterns in .gitignore
git ls-files --ignored --exclude-from=.gitignore;
# Show other (i.e. untracked) files that are ignored because of patterns in .gitignore
git ls-files --ignored --other --exclude-from=.gitignore;
# Show files in the index that are ignored because of patterns in any of the standard git exclusions.
git ls-files --ignored --exclude-standard;
# Show other (i.e. untracked) files that are ignored because of patterns in any of the standard git exclusions.
git ls-files --ignored --exclude-standard --other;


Alternative to sched_yield()

In case sched_yield() does not seem to work for you or it is not available, you can try calling usleep(0) as a workaround.

int sched_yield(void); from (#include <sched.h>) causes the calling thread to relinquish the CPU. The thread is moved to the end of the queue for its static priority and a new thread gets to run.
From: man 3 sched_yield

int usleep(useconds_t usec); from (#include <unistd.h>) suspends execution of the calling thread for (at least) usec microseconds. The sleep may be lengthened slightly by any system activity or by the time spent processing the call or by the granularity of system timers.
From: man 3 usleep

Notes

  • Do not use sleep(0) as a workaround as in some older versions of glibc it will not have any effect at all! In those older versions there is a check if the input parameter is set to 0 and if it is then it will do nothing at all. Specifically the code is as follows:
    if (seconds == 0)
     return 0;

    If you want to review the code changes in sleep.c or see how usleep.c is code, download this archive: [download id=”3897″]
    It contains all versions of sleep.c up to today and the latest version of usleep.c.

  • If the calling thread is the only thread in the highest priority list at that time, it will continue to run after a call to sched_yield().
  • Strategic calls to sched_yield() can improve performance by giving other threads or processes a chance to run when (heavily) contended resources (e.g., mutexes) have been released by the caller. Avoid calling sched_yield() unnecessarily or inappropriately (e.g., when resources needed by other schedulable threads are still held by the caller), since doing so will result in unnecessary context switches, which will degrade system performance.

Login to ‘CytaVoda WiFi’ with no password using your SIM card 1

Using Android devices that carry Cytamobile-Vodafone SIM cards with active RED and BLACK plans, you can connect to the CytaVoda WiFi using SIM authentication instead of using a password.

To do so

  • from the Wi-Fi manager of your cell phone click to connect on the CytaVoda WiFi network
  • at the new window click on the drop-down named EAP method
  • and select the option SIM
  • finally click on the Connect button.

The system will validate you and no further steps needed.

You will notice that your Wi-Fi manager will show a slightly different window than the usual when you click to connect on the network. This is normal as the network offers multiple authentication methods and it is giving you the option to choose which one to use. Of course, we do not know the password and the purpose of this post is to demonstrate the SIM authentication method.

The CytaVoda WiFi has a drawback, it does not offer unlimited data to the users.
Depending on what your SIM plan is, you will have a different monthly data allowance which is renewed every 1st of the month.

The data allowance limits that were applied at the time this post was written, were the following:

  • 200MB for: RED 1
  • 500MB for: RED 2
  • 1GB (1024MB) for: RED 3
  • 2GB (2048MB) for: RED 4 / RED Family / RED Plus / BLACK

You can check the amount of CytaVoda WiFi data that you consumed and the remaining data at the page http://miu.cyta.com.cy.