I'm working in a multi-repo environment. Is it possible to get the currently active/working branch on each repo using android repo tool?
eg: say I have repos called repo1, repo2, repo3 and their respective active/working branches be branch1, branch2, branch3. I want to a result like the following.
repo1 | branch1
repo2 | branch2
repo3 | branch3
Thanks
"repo branch" pops up with all the branches highlighting current branches.
Related
I have multiple branches which are branched off the master (each in a separate subdirectory).
Branch1: new development, not yet completely finished
Branch2: hotfix for a problem, but still under test
Branch3: mess around branch, which I will not restore
Before testing of the hotfix is finished I would like to have the code already available in Branch1, so I can continue developing with the fix in place.
(But since my experience with git is not that much I first started to play around with merge in a 3rd branch, especially created to mess around in, before I mess up either Branch1 or Branch2)
In my 3rd branch I first tried the following:
git merge feature/Branch1
but this gave the following error:
fatal: 'feature/Branch1' does not point to a commit
I next did a commit -a in my Branch1 and tried again, but it keeps giving the same error.
What am I doing wrong? What should I do to merge the code from - in this case - Branch1 with Branch3?
First, checkout to your Branch3:
git checkout Branch3
Then merge the Branch1:
git merge Branch1
And if you want the updated commits of Branch1 on Branch2, you are probaly looking for git rebase
git checkout Branch2
git rebase Branch1
This will update your Branch2 with the latest updates of Branch1.
git checkout [branchYouWantToReceiveBranch] //checkout branch to receive branch
git merge [branchYouWantToMergeIntoBranch]
You can use these commands:
git checkout <the branch you want to merge into>
git merge <the branch you want contents from>
To merge one branch into another, such as merging "feature_x" branch into "master"* branch:
git checkout master
git merge feature_x
* Note that the original branch name is now commonly main instead of master. Choose the correct name based on your situation.
This page is the first result for several search engines when looking for "git merge one branch into another". However, the original question is more specific and special case than the title would suggest.
It is also more complex than both the subject and the search expression. As such, this is a minimal but explanatory answer for the benefit of most visitors.
Just in case you arrived here because you copied a branch name from Github, note that a remote branch is not automatically also a local branch, so a merge will not work and give the "not something we can merge" error.
In that case, you have two options:
git checkout [branchYouWantToMergeInto]
git merge origin/[branchYouWantToMerge]
or
# this creates a local branch
git checkout [branchYouWantToMerge]
git checkout [branchYouWantToMergeInto]
git merge [branchYouWantToMerge]
A slightly more long winded approach, but it works none-the-less:
In branch 3:
git fetch origin Branch1
git merge --no-ff origin/Branch1
At this point merge conflicts may occur, save all changes made to files containing merge conflicts
git add -A
git commit -m "Merge"
git push
DONE
I am working on project, in which a branch say feature/test is used by N number of developers. All developers currently commit their changes and push to same branch.
Now i want to find all files on which i have worked in branch feature/test.
Thanks in advance.
git log --stat --name-only --author="your_name" --pretty=format:"" --branches=your_branch|sort -u
Source - old question
Last week I created a Github repo and forgot to select a license for the repo. Now there are already 3 large commits.
I have asked the 3 contributors if it is ok if I delete the repo and then create it again with the same name and this time selecting the license when creating the repo, and they were fine with that.
Question
Is there a way I can get the commits into the new repo (this time the first commit is the LICENSE file) and still keep the commit meta info?
Is there a way I have get the commits into new repo (this time the first commit is the LICENSE file) and still keep the commit meta info?
Yes, by adding a remote and cherry-picking the commits on top of your first commit.
# add the old repo as a remote repository
git remote add oldrepo https://github.com/path/to/oldrepo
# get the old repo commits
git remote update
# examine the whole tree
git log --all --oneline --graph --decorate
# copy (cherry-pick) the commits from the old repo into your new local one
git cherry-pick sha-of-commit-one
git cherry-pick sha-of-commit-two
git cherry-pick sha-of-commit-three
# check your local repo is correct
git log
# send your new tree (repo state) to github
git push origin master
# remove the now-unneeded reference to oldrepo
git remote remove oldrepo
The rest of this answer is if you still want to add the LICENSE to your previous repo.
Yes. You can place your LICENSE commit as the first commit by rebasing.
Rebasing is gits way of rearranging commit order while keeping all the commit authors and commit dates intact.
When working on a shared repo, it's generally discouraged unless your entire team is git-fluent. For those that aren't, they can just clone a fresh copy of the repository.
Here's how you get your LICENSE commit as the first commit.
1. Update and rebase your local copy
Check out your project and place the LICENSE file in a commit ON TOP of your current 3 commit stack.
#create LICENSE file, edit, add content, save
git add LICENSE
git commit -m 'Initial commit'
Then do an interactive rebase on the master branch to REARRANGE the commits.
git rebase -i --root
It will open an editor. Move the bottom line (your "Initial commit" commit, the most recent commit) to the top of the file. Then save and quit the editor.
As soon as you exit the editor, git will write the commits in the order you just specified.
You now have your local copy of the repository updated. do:
git log
to verify.
2. Force push your new repo state to github
Now that your copy is updated, you have to force push it to github.
git push -f origin master
This will tell github to move the master branch to its new location.
You should only force push in rare occasions like this where everybody working with it is aware of the pending change, else it will confuse your collaborators.
3. Synchronize collaborators to github
Lastly, all the collaborators will have to synchronize to this repository.
First they must have clean repositories as the following command can be destructive if there are unsaved changes.
# make sure there are no unsaved changes
git status
# pull the latest version from github
git fetch
# move their master branch pointer to the one you published to github.
git reset --hard origin/master
That's it. Everybody should be in sync now.
I had a similar problem where I forgot to fork a repo to my github and added several commits before I realized my mistake.
I found a pretty simple solution.
First remove the remote to the original repo
git remote remove origin
Second add a remote to the new fork on my github
git remote add origin <my repo URL>
Then I pushed to origin master and all of my commits showed up on my github.
I used the following approach:
Clone the source repo to a folder like /c/SrcRepo
Clone the destination repo to a folder like /c/DstRepo and switch to the destination branch
In the root folder of the destination repo run the command:
git pull /c/SrcRepo srcBranch --allow-unrelated-histories
No necessary to create an additional remote reference
Based on #Moocowmoo's answer but trying to streamline it bit more
What this does differently is tries to avoid conflicts as much as possible, just assuming that the remote is correct.
It doesn't however handle deleted files well, so there is still a manual element.
# assuming you are already on the branch you want to be
git remote add oldrepo https://github.com/path/to/oldrepo
git fetch oldrepo
# take all or subset of changes from a branch
git cherry-pick --strategy recursive --strategy-option theirs oldestCommitHash^..latestCommitHash
# or take all changes included in a specific merge commit (easiest)
git cherry-pick --strategy recursive --strategy-option theirs mergeCommitHash^..mergeCommitHash
# handling deleted files/unhandled conflicts
# just keep repeating this section
git mergetool
# either c/m or d based on if you want to keep or delete the files
git cherry-pick --continue
Destination Git = UrlD (existing content doesn't matter)
SourceGit = UrlS
git clone UrlS
git remote add origin2 UrlD
git push -f origin2 master
Now the Destination will have the same data as Source(You can also use origin instead of origin2)
you can try this, it's easy and straightforward. This will push all commits before (and including) the hash you use as <last-commit-hash-from-old-repo> to the other repo:
git clone https://github.com/path/to/new-repo.git new-repo
cd new-repo
git remote add old https://github.com/path/to/old-repo.git
git remote update
git merge --allow-unrelated-histories <last-commit-hash-from-old-repo>
git push origin main
if anyone needs to push all commits from a repo to another as a single commit (like I needed), you can simply add --squash to the merge command like this:
git clone https://github.com/path/to/new-repo.git new-repo
cd new-repo
git remote add old https://github.com/path/to/old-repo.git
git remote update
git merge --squash --allow-unrelated-histories <last-commit-hash-from-old-repo>
git push origin main
In my case I needed to find out differences between the old and new repos. So in the new repo added the old one.
git remote add old https://gitlab.site.az/old-blog.git
Fetch all remotes
git fetch --all
Find different commits
git log --graph --oneline --pretty=format:"%h%x09%an%x09%ad%x09%s" --abbrev-commit --date=relative develop..old/develop
Get commits you selected
git cherry-pick SHA1 SHA2 SHA4
I am using the Linux kernel in an embedded project. When I started, I used git to clone from kernel.org what was then the current stable release, 3.14.2. As new 3.14 kernels were released, I was able to upgrade to them by using git rebase . For example, I upgraded to 3.14.10 by using
git checkout linux-3.14.y
git pull
git checkout myproject
git rebase v3.14.10
However, if I try to upgrade to the 3.15 series by using
git checkout linux-3.15.y
git pull
git checkout myproject
git rebase v3.15.3
or
git merge v3.15.3
I get git merge conflicts on files that I have never touched.
Is there a recommended way to upgrade from 3.14.10 to 3.15.3?
Here is what is happening. Let's say the starting commit graph looks something like this:
-------------------------------------- myproject
/
/
-----------/---------------------------------o------ linux-3.14.y
/ C v3.14.10
/ B
----/---------------------------\-------------------------- master
A \
\
--------------------o--- linux-3.15.y
v3.15.3
I don't know that it exactly looks like this, but it illustrates the issue.
When rebasing, git searches back in history for the first commit that is part of both the current branch and the "upstream" branch specified. It collects all these commits for the rebase operation.
When the "upstream" specified is the one from which the current branch was originally created, the collected commits include only my own commits on the current branch, so there are no conflicts.
When the "upstream" specified is not the one from which the current branch was originally created, which is the case for the "git rebase v3.15.3", the collected commits include ones that are not my own commits. In the example, the point of convergence is commit A, and the rebase operation would include everything from point A to myproject. The ones between point A and point C are probably inappropriate for the desired operation.
Instead, what is needed is to continue to use linux-3.14.y as the "upstream" branch for the purpose of identifying which commits to rebase, but to specify a separate commit onto which to rebase these commits. That is what the "--onto" switch is for. So the required operation to port myproject to the v3.15.y kernel is
git checkout myproject
git rebase linux-3.14.y --onto v3.15.3
I am running etckeeper on two different machines, boxA and boxB. The OS, etckeeper repository and all, on boxB was copied from boxA back in January. In order to apply some setup changes made on boxA to boxB, I added the repository on boxA as a remote repository on boxB with the intention of doing some cherry picking, eg:
git remote add boxA ssh://boxA/etc
git fetch boxA
git cherry-pick xxxx # never got this far
The problem is that the most recent commits are not available on boxA, only commits up until late February. So far I have tried:
doing git show with one of the missing commit numbers - this is definitely not a problem with git log just not showing all the commits.
copying the full /etc on boxA to boxB and adding/fetching it via its path - this is definitely not an issue somehow introduced by ssh (to complicate things I was using a script via the GIT_SSH environment variable to avoid creating a root login).
git fsck on both repositories (no problems found).
running the following command on copied version of both repositories (after doing a git remote remove boxA on boxB and before readding):
git -c gc.reflogExpire=0 -c gc.reflogExpireUnreachable=0 \
-c gc.rerereresolved=0 -c gc.rerereunresolved=0 -c gc.pruneExpire=now gc \
--aggressive
How can I get git fetch to retrieve all of the commits?
So the problem here turned out to be that there was a detached head in the repository on boxA after an incomplete fix of a botched rebase. When this happens the output of git branch is as follows:
# git branch
* (no branch)
master
The fix was simply to create a branch on boxA and then merge it:
git branch temp
git checkout master
git merge temp
git branch -d temp
After that all the commits on branch master (or at least what I thought was branch master) were available after doing another git fetch.