• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

Root Git & Github questions

dsmryder

Android Expert
May 28, 2011
2,418
502
NE Florida
When I make a change to my cm7, I just go into the file I want and change it. This brakes the repo sync. So, What I did is created two folders. One for me, one for repo. I see a lot of terms like checkout, commit, and the such. I am getting a growing understanding of how this is used.

What I would like, if it's not asking too much, is for people with the familiarity using github to coach me (and anybody else who reads this thread and asks questions) how to properly run this stuff so I won't have to do my dirty methods.

Thank you.






EDIT: Things that I have learned.
  • git pull
    This is used to get a branch from a remote repository. It's used by repo (as in repo sync) to keep your system up to date.
    Code:
    git pull (remote name) (branch name)
    [*]git push
    Basicly pull in reverse.
    [*]git remote
    Your link to the remote branch. I like using the "-v" argument as it shows the remotes. I use this to link me up with SSH[CODE]git remote set-url github git@github.com:MTDEV-CM7/frameworks.git
    as an exapmle. This isn't nessacery anymore as the "https" method works and is the prefered way.
  • git checkout
    This is used to switch between branches. I use the "-t" agument to track the remote branch and the "-b" argument to create a new branch while switching to it
  • git branch
    This is use to work with branches. I use the "-d" or "-D" to remove branches. and I use "-a" to view all, local and remote, branches.
  • git commit
    When you are done with your current work and are ready to push it to the remote. I use the double arguments "-am" ("a"is to add known files that have been changed and remove files that have been removed. And the "m" is to make the message)to quickly commit from the command line .
  • git stash
    For when you aren't ready to commit, like say you have run a test and don't know where you went wrong, and you want to put the work to the side.
 
When I make a change to my cm7, I just go into the file I want and change it. This brakes the repo sync. So, What I did is created two folders. One for me, one for repo. I see a lot of terms like checkout, commit, and the such. I am getting a growing understanding of how this is used.

What I would like, if it's not asking too much, is for people with the familiarity using github to coach me (and anybody else who reads this thread and asks questions) how to properly run this stuff so I won't have to do my dirty methods.

Thank you.

What I have is two folders, my repo synced in "android" and another folder called "github-merged". In "github-merged" I have basically done a git clone of all the repositories from my github via ssh. The next thing I do is setup an upstream to all the folders in "github-merged"

git remote add upstream https://github.com/CyanogenMod/xxxx.xxxx
git fetch upstream
git merge upstream/gingerbread

Code:
android_dalvik https://github.com/CyanogenMod/android_dalvik.git
android_external_iptables https://github.com/CyanogenMod/android_external_iptables.git
android_frameworks_base https://github.com/CyanogenMod/android_frameworks_base.git
android_hardware_libhardware_legacy https://github.com/CyanogenMod/android_hardware_libhardware_legacy.git
android_hardware_msm7k https://github.com/CyanogenMod/android_hardware_msm7k.git
android_system_core https://github.com/CyanogenMod/android_system_core.git
android_system_netd https://github.com/CyanogenMod/android_system_netd.git
android_packages_apps_Camera https://github.com/CyanogenMod/android_packages_apps_Camera.git

That allows me to keep all the folders synced with Cyanogen that I am not syncing from the android/default.xml. I will merge all the upstream's then copy the contents of each folder into another folder "g60-test". Here I will make edits to the code and run "git add ." if I add any new files followed by "git commit -a" which will launch gedit so I can comment on the commits. I will then copy the contents of those folders in g60-test to "android". I will then build CM7 test and make sure all the stuff works (phone, text, msm, bluetooth, camera, etc) after I feel everything is working I then push my commit's to github from the "g60-test" with "git push -u origin gingerbread" in each directory I have edited.

At that point I then delete all the contents of the "android" folder make sure not to delete .repo. Then I will run a "repo sync" to sync my new changes. Once I get ready to start work on the next revision of g60 I delete all the contents of "github-merged" and git clone my repo's and start the processes all over again.

I would be interested in how Mantera does it as I have only been doing this for a short while.
 
  • Like
Reactions: BSydz and dsmryder
Upvote 0
When I make a change to my cm7, I just go into the file I want and change it. This brakes the repo sync. So, What I did is created two folders. One for me, one for repo. I see a lot of terms like checkout, commit, and the such. I am getting a growing understanding of how this is used.

I don't really do anything special. It may or may not be "proper", but here it is:

I have a separate set of folders for cm7 and cm9 just because I happened to have started on cm7 then started on cm9 and didn't want to have to keep switching the branches in every folder when I wanted to switch between them. Also when I want to compare between the 2 branches, it was just easier for me if I had 2 copies instead of doing a git diff.

I just do a repo sync to pull down all of the non-tracked repos. Then I have a script that I run to go and fetch and merge all of the changes from upstream into my repos that I track--the ones that are in my github.

Your issues with the repo sync errors is that you have not committed your changes yet into git and so the repo sync will not pull down any changes until you do that for fear that any changes that come down will overwrite your changes. To get around that, you need to commit your changes locally before doing a repo sync.

Just in case somebody is confused, GIT is just a revision control system that keeps track of the history and different versions of your files as you make changes to them. GITHUB is a website where you can store copies of your files. They work in conjuction to keep a history of your files and different versions of your files on the GITHUB website.

So when you COMMIT a change to GIT, you are just telling GIT to save a snapshot of your files at that particular point in time. When you PUSH the commit to GITHUB then you are uploading your changed files into github along with the history of that change. You can't push your changes to github unless you own that particular repository or you are given permission to do that by the owner of that repository. So for example, you dsmryder can't push your changes into g60madman's github unless he gives you the proper credentials for his repos.

However, you can create your own copy of his repos by FORKING it from his site. You can then push your changes to your repos and then send him a pull request--meaning that you are asking him to pull your changes into his repos.

So again, what you need to do is the following:

1. Make a branch. "git branch gingerbread" to create a new branch named gingerbread.
2. Switch to the gingerbread branch: "git checkout gingerbread". Alternatively, a shortcut to steps 1 and 2 is to combine them into one command by typing "git checkout -b gingerbread" which will create the branch and switch you at the same time.
3. Make changes locally.
4. commit the changes locally. Use "git commit -a" or "git add" and then "git commit" and then type your commit message in the next screen. Or if you only have a short comment, you can do git commit -am "This is a short comment".

Once your changes are committed, you can then do a repo sync and it will not give you the errors that you see.

Of course, your changes are still not available for anyone else. So I'd recommend that you create your own repos on github so you can push your changes up so that you can share them with everyone else.

I don't use separate folders like g60 does. If needed for a certain repo, I just create a new branch to do my tests. When I'm done with the test, I just merge it into the main branch with the git merge command.

So for example, when I was testing some new changes in my kernel repo:

I created a new branch called test and switched to it.
#git checkout -b test

Next, I made whatever changes that I wanted. In this example, I patched my kernel up to version 2.6.32.59 and so my commit message was "Linux 2.6.32.59"
#git commit -am "Linux 2.6.32.59"

I run some tests to make sure it's ok. Then once satisfied that it's working, I can merge it back into my main ics branch. So first I have to switch back to the ics branch and then I can merge my test branch into the ics branch:
#git checkout ics
#git merge test


Now that I'm done with the test branch, I can delete it if I wanted to:
#git branch -D test

Note that you can use -D or -d, however, -d will not delete the branch if you have changes that you have not merged yet with the current branch that you are on. Using the -D (that's the capital letter D) will override that and delete the branch even if your changes have not been merged yet. So you can decide whichever one you want to use, just know the difference between them.

Here's some helpful sites that I've bookmarked for myself that I use:

Git Reference
github - GIT revert to previous commit... how? - Stack Overflow
git ready reflog, your safety net
Help.GitHub - Send pull requests
https://sites.google.com/a/android.com/opensource/download/using-repo
 
Upvote 0
Okay so its normal for repo sync to not pull in upstream changes from the repos I have forked myself? Because on my report I has several repos I has forked and I had made changes to rmthem and pushes them up to github, but everytime I would run repo sync, at the end of it it would tell me all my forked repos were not tracked upstream, and for some reason it would checkout all of them repos to no branch, which reverted them back to the state they were at when I forked them, and I would have to go into each report and checkout to gingerbread for each one. I'd that normal? Do I need to make a script that I can run to go in and pull in changes to each report and check me out to the gingerbread branch that I run after each repo sync?

Oh and to the OP, the way I manage my kernel report is just with one folder for my froyo kernel and one for my cm7 one in my home Linux folder. I could have used a different branch for cm7 but at the time I felt it was easier to use a seperate folder.

I usually will create a new branch whenever I get to change something drastic so I don't hose my repo and I try it out then if it works I make the changes in my main branch called master. I also have addes many remotes pointing to other kernel repos so that I can cherry-pick commits from them. I like making my commits clean and easy to understand what was changes. A good tip is to make one change them commit it then another and commit it and so on. On a cm7 repo, .gitignore files aren't as important but on a kernel repo, they are cruicial in keeping a clean repo free of any autogenerated files that are created during a build. They also help keep clean commits, ignoring any files that don't need to be includes in the repo. And clean commits help others pull in changes you made easily without having to go back in and clean up.

But it took my a while go learn how to use got effectivley, but it just takes time to get used to it!!
 
  • Like
Reactions: Chairshot215
Upvote 0
Okay so make a script that will cd to the repo directory, run git checkout gingerbread, then fetch the upstream changes? And have it do that for all my forked repos? Should I have it merge in the changes as well or do that manually?

Using the android_frameworks_base repo as an example: in my script icssync.sh I fetch changes from my cm remote:

Code:
echo cd ~/android/triumphics/frameworks/base
cd ~/android/triumphics/frameworks/base
git checkout ics
git fetch cm ics
git merge FETCH_HEAD

I do the echo command just to give me an idea of which repo that it is currently working on since it's sometimes hard to tell and also, I'd rather copy and paste than have to type out the whole cd command if I have to resolve some merge errors. I also only fetch the branch that I need so it's quicker and takes up less room for history for other branches that I don't care about.

I keep this script on my desktop so my command to run it is:

#sh ~/Desktop/icssync.sh 2>1 > ~/Desktop/update.txt

I like piping the results into a text file so I can browse the results at my leisure to see if there were any conflicts and also what was changed.

Then, I can copy and paste the cd command from the results and just do a git push origin to push the merges up to github.
 
Upvote 0
mantera, like I said, you're awesome!
This is what I've been looking for. Maybe tomorrow I can resetup my github and vomit up my changes. I think I can carry it from here, and I'm glad at least someone else could benifit. That's my favorite feature about these forums. You may not even have known you had the question, but you found your answer.
 
Upvote 0
You may want to change the thread title to something like "git and github questions" or something like that so if someone is searching, they may find this thread quicker since we're not really talking about programming in this thread.

My original intentions were to get organization ideas, like what you three have said with using folders or not.
 
Upvote 0
You mean like if your creating a new repo? Yeah create a repo on github, then move to the directory on your computer you want the repo to be and follow the github directions to turn that inti a gitgub repo.

I was hoping to go the other way around. Take a directory I have on my computer and push that up to github without creating it and going back and forth with git init. I know I messed up a couple of times because I can't sit there and work on it (family first). If I can reduce my steps, then i can improve accuracy.
 
Upvote 0
I was hoping to go the other way around. Take a directory I have on my computer and push that up to github without creating it and going back and forth with git init. I know I messed up a couple of times because I can't sit there and work on it (family first). If I can reduce my steps, then i can improve accuracy.

You just create a new blank repo on Github first. Then do the following on your computer:

Change to the directory that you want to turn into a git repository. Make sure that that there are no unnecessary files in the directory, for example, do a "make clean" before committing it to git. So assuming you are now in the directory, do the following:

Code:
#git init
#git add .
#git commit -m "Initial commit"
#git remote add origin <put in the url/address of the repo on github here>
#git push origin
 
Upvote 0
You just create a new blank repo on Github first. Then do the following on your computer:

Change to the directory that you want to turn into a git repository. Make sure that that there are no unnecessary files in the directory, for example, do a "make clean" before committing it to git. So assuming you are now in the directory, do the following:

Code:
#git init
#git add .
#git commit -m "Initial commit"
#git remote add origin <put in the url/address of the repo on github here>
#git push origin

Just to add to that, if you are say building for Gingerbread or ICS you may need to create a branch to tie to your android/default.xml

Code:
#git init
#git branch <new branch name>
#git checkout <new branch name>
#git add .
#git commit -m "Initial commit"

#git remote add origin <put in the url/address of the repo on github here>
#git push origin <new branch name>
 
  • Like
Reactions: dsmryder
Upvote 0
Just to add to that, if you are say building for Gingerbread or ICS you may need to create a branch to tie to your android/default.xml

Code:
#git init
#git branch <new branch name>
#git checkout <new branch name>
#git add .
#git commit -m "Initial commit"

#git remote add origin <put in the url/address of the repo on github here>
#git push origin <new branch name>

Technically, you don't "have" to since when you do a git init, it creates a branch called master by default. However, you're right; it's good practice to create a branch name that's descriptive.
 
  • Like
Reactions: dsmryder
Upvote 0
I can't push a file to github.
I have added the remote. I have commited the changes. I have made and switched to a new branch.
I get the following error.
Code:
daddy@ubuntu:~/cm7/device/motorola/triumph$ git push origin master
error: The requested URL returned error: 403 while accessing https://github.com/dsmryder/android_device_motorola_triumph/info/refs

fatal: HTTP request failed
Is this me or github's side. I'm going to try to change the remote to git@github to see what will happen
 
Upvote 0
I can't push a file to github.
I have added the remote. I have commited the changes. I have made and switched to a new branch.
I get the following error.
Code:
daddy@ubuntu:~/cm7/device/motorola/triumph$ git push origin master
error: The requested URL returned error: 403 while accessing https://github.com/dsmryder/android_device_motorola_triumph/info/refs

fatal: HTTP request failed
Is this me or github's side. I'm going to try to change the remote to git@github to see what will happen

Did you go a git clone from your github make change and try to push back up? If you did, you need to upload to the right branch

# git push -u origin gingerbread
 
Upvote 0

BEST TECH IN 2023

We've been tracking upcoming products and ranking the best tech since 2007. Thanks for trusting our opinion: we get rewarded through affiliate links that earn us a commission and we invite you to learn more about us.

Smartphones