Showing posts with label git. Show all posts
Showing posts with label git. Show all posts

Tuesday, August 29, 2023

How to fix Git repeatedly requesting user credentials?

 When you engage with a remote repository via HTTPS URLs through the command line, you'll inevitably encounter prompts for your GitHub username and password. This can be rather frustrating, wouldn't you agree?

Nevertheless, there are some notable advantages to using an HTTPS remote URL: it's considerably simpler to configure compared to SSH 😅, and it typically circumvents the restrictions imposed by stringent firewalls and proxies. However, it does come with the drawback of incessantly requesting your GitHub user credentials whenever you perform a repository pull or push 😞.

Fortunately, there's a way to rectify this predicament by configuring Git to handle your password for you. Here's the step-by-step solution:

1. Update the origin remote URL to use SSH instead of HTTPS:

   git remote set-url origin git@github.com:username/repo.git

   Or, for those who prefer an alternative approach:

2. Configure Git to store your username and password, effectively eliminating the need for manual entry:

   git config --global credential.helper store

3. If you want to take it a step further and cache your credentials for a session, you can use:

   git config --global credential.helper cache

4. Optionally, you can set a specific timeout for the credential cache to enhance security:

   git config --global credential.helper 'cache --timeout=600'

Voilà! You've successfully resolved the issue, and from this point onward, Git won't pester you for your credentials anymore. 😄

Thursday, June 29, 2023

How to Use Git LFS for Files Larger than 100MB on GitHub

How to Use Git LFS for Files Larger than 100MB on GitHub

If you're working on a GitHub repository and need to handle files larger than 100MB, Git LFS (Large File Storage) is the solution. Git LFS allows you to manage and version large files efficiently. In this guide, we'll walk you through the steps to use Git LFS for files exceeding 100MB on GitHub.

Step 1: Install Git LFS

To get started, you need to install Git LFS on your local machine. Open your terminal and run the following command:

sudo apt-get install git-lfs

Step 2: Navigate to Your Repository

Change your working directory to the location of your Git repository:

cd path_to_your_repo

Step 3: Initialize Git LFS

Before you can start using Git LFS for large files, you need to initialize it for your repository:

git lfs install

Step 4: Specify File Types for Git LFS

Tell Git LFS which file types you want to manage. For example, if you want to use Git LFS for files with the extensions .tflite and .apk, run the following commands:

git lfs track "*.tflite"
git lfs track "*.apk"

Step 5: Stage and Commit Your Changes

Now that Git LFS is set up for the specified file types, add your files to the staging area and commit them. Replace "added file above 100MB with lfs" with an appropriate commit message:

git add .
git commit -am "added file above 100MB with lfs"

Step 6: Push to GitHub

Finally, push your changes to your GitHub repository:

git push origin main

That's it! You've successfully configured Git LFS to manage files larger than 100MB in your GitHub repository. These steps will help you keep your repository organized and prevent large files from bloating your Git history.

Git LFS is a powerful tool for handling large files in Git, and it ensures that your repositories remain efficient and manageable. Now you can work with large assets in your projects on GitHub with ease.

Monday, February 6, 2023

Share common folder between two git repo

 One common approach is to use Git Submodules.

A Git submodule allows you to include a repository as a sub-folder within another repository. The submodule remains a separate repository, but changes made to it are committed and tracked in the parent repository.

To add a submodule to a Git repository, you would run the following commands:

$ git submodule add [url_of_the_submodule_repo] [path/to/submodule] $ git commit -m "Adding submodule [name_of_the_submodule]" $ git push

You can then clone the parent repository and initialize the submodule by running:

$ git clone [url_of_the_parent_repo] $ cd [parent_repo] $ git submodule init $ git submodule update

This way, both the parent and submodule repositories will have the latest version of the submodule code. However, changes made to the submodule code will need to be committed and pushed to the submodule repository and then committed and pushed in the parent repository to propagate to other users.

for more info:

https://phoenixnap.com/kb/git-clone-submodule

Thursday, August 8, 2013

Patch file in Linux

Patch takes a patch file patchfile containing a difference listing produced by the diff program and
applies those differences to one or more original files, producing patched versions.
Normally the patched versions are put in place of the originals.

Example to create patch file:
$ diff -urN alsa-utils-1.0.27.2-src-ori/build_core alsa-utils-1.0.27.2-src-patch/build_core
where,
alsa-utils-1.0.27.2-src-ori is original code,
alsa-utils-1.0.27.2-src-patch is chaned code.

The following usage is most commonly used:
$ patch -p1 < {/path/to/patch/file}

To apply a patch, one could run the following command in a shell:
$ patch < /path/to/file

Patches can be undone, or reversed, with the '-R' option:
$ patch -R < /path/to/file

Above 3 are basic usage read the man page of patch command for more information and usage:
% man patch

https://www.git-tower.com/learn/git/faq/change-author-name-email

Friday, July 5, 2013

Git Tutorial

Create a new repository
To create a new directory, open it and perform a
git init

Checkout a repository
To create a working copy of a local repository by running the command
git clone /path/to/repository

When using a remote server, your command will be
git clone username@host:/path/to/repository

Add & Commit
You can propose changes (add it to the Index) using
git add <filename>
git add *

This is the first step in basic git workflow. To actually commit these changes use
git commit -m "Commit message"

Now the file is committed to the HEAD, but not in your remote repository yet.  

Workflow
Your local repository consists of three "trees" maintained by git. the first one is your Working Directory which holds the actual files.
the second one is the Index which acts as a staging area and finally the HEAD which points to the last commit you've made.
        
     






Pushing changes
Your changes are now in the HEAD of your local working copy. To send those changes to your remote repository, execute
git push origin master

Change master to whatever branch you want to push your changes to.

If you have not cloned an existing repository and want to connect your repository to a remote server, you need to add it with
git remote add origin <server>

Now you are able to push your changes to the selected remote server

Branching
Branches are used to develop features isolated from each other. The master branch is the "default" branch when you create a repository. Use other branches for development and merge them back to the master branch upon completion.








Create a new branch named "feature_x" and switch to it using
git checkout -b feature_x

switch back to master
git checkout master

and delete the branch again
git branch -d feature_x

a branch is not available to others unless you push the branch to your remote repository
git push origin <branch>

Update & Merge
To update your local repository to the newest commit, execute
git pull

In your working directory to fetch and merge remote changes.
to merge another branch into your active branch (e.g. master), use
git merge <branch>

In both cases git tries to auto-merge changes. Unfortunately, this is not always possible and results in conflicts. You are responsible to merge those conflicts manually by editing the files shown by git. After changing, you need to mark them as merged with
git add <filename>

Before merging changes, you can also preview them by using
git diff <source_branch> <target_branch>

Tagging
git log    
git whatchanged -n 1
git log --stat
git diff HEAD^ HEAD
git show HEAD~2 HEAD~2
git remote -v //get remote link

Revert local changes
git clean -f -d
git reset --hard
git checkout -- HEAD

git checkout -- <filename>

git reset --hard HEAD~1
git reset --hard HEAD@{1}
HEAD~1 means "go to the commit before the commit that HEAD currently points at",
HEAD@{1} means "go to the commit that HEAD pointed at before it pointed at where it currently points at".
Detailed Here

If you instead want to drop all your local changes and commits, fetch the latest history from the server and point your local master branch at it like this
git fetch origin
git reset --hard origin/master
 
If you want to keep your work and just 'undo' that commit command (you caught before pushing to repo):
git reset --soft HEAD~1

Do not use the --hard flag unless you want to destroy your work in progress since the last commit.
 
To Remove remote commit changes:
To remove git commit after git push:
git reset --hard HEAD~1
git push -f

To switch among the commits
, use
"$ git reflog" and then using
"$ git checkout commit_id" jump to specific commit id back and forth

To merge branches
$ git fetch
$ git checkout a (you will switch to branch a)
$ git merge b (this will merge all changes from branch b into branch a)
$ git commit -a (this will commit your changes)
$ git push

To checkout remote branch
Before you can start working locally on a remote branch, you need to fetch it.
To fetch a branch, you simply need to:
$ git fetch origin
This will fetch all of the remote branches for you. With the remote branches in hand,
you now need to check out the branch you are interested in, giving you a local working copy
$git checkout -b test origin/test

To create remote branch
1. First, you create your branch locally
   git checkout -b your_branch
   e.g. git checkout -b master-devel-v8.0
2. Then push it to the remote server
   git push <remote-name> <branch-name>
   e.g. git push -u origin master-devel-v8.0

To delete a remote branch
git push origin --delete <branchName>
e.g. git push origin --delete master-devel-v8.0

To delete Local Branch
git branch -D <branchName>
e.g. git branch -D master-devel-v8.0

To create development branch from master
1. first checkout master
2. then checkout devel

To create development branch from master
If two people are working on same branch in git
1. First should commit and push his changes. Then
2. Second should commit his changes and pull first's changes from server and then push everything.

To rebase branch:
1. First checkout working branch
2. Then, rebase from master branch
e.g. git checkout mutex
       git rebase component-integration

To changes of a file in all commit:
git log -p -- path/to/file 

Useful Hints:
built-in git GUI
gitk

use colorful git output
git config color.ui true

show log on just one line per commit
git config format.pretty oneline

use interactive adding
git add -i


https://stackoverflow.com/questions/8801729/is-it-possible-to-have-different-git-config-for-different-projects

https://stackoverflow.com/questions/4523496/is-it-possible-to-pull-from-one-repo-and-push-to-other-one

http://gitref.org/creating
http://git-scm.com/book
http://rogerdudler.github.io/git-guide/
http://www.vogella.com/articles/Git/article.html
http://stackoverflow.com/questions/2745076/what-is-the-difference-between-git-commit-and-git-push
http://www.cyberciti.biz/faq/appy-patch-file-using-patch-command
https://remarkablemark.org/blog/2018/10/09/git-checkout-clean-reset/