If you are using Git as your version control system, it can be very helpful in generating the changeset between releases.
First step is to find the last commit where you started the new (or the next) release that you want the changeset for. It can be easily achieved by something like this:
git log --pretty=format:"%h - %an, %ar : %s" | grep "RELEASE: X.X.X"
Then you just do:
git log --pretty=format:"%h - %an, %ar : %s" b9c28fc..
The formatting options can be altered of course. You can find many more options in the "Pretty formats" section in the git log man pages
Initial checkout (to ~/branchtest folder) since it was not specified
apollo:~max$ git clone git@bitbucket.org:inteist/branchtest.git
Let's create a file named "master.txt"
apollo:~max$ echo This is master branch > master.txt
Now let's add the file to track changes
apollo:branchtest max$ git add .
apollo:branchtest max$ git status
# On branch master
#
# Initial commit
#
# Changes to be committed:
# (use "git rm --cached ..." to unstage)
#
# new file: master.txt
Now let's push the file to the master branch (until now there were no refs). The "-u" switch adds upstream tracking
apollo:branchtest max$ git push -u origin master
Now let's create a new branch and name it "new". The "-b" switch makes us immediately switch to the "new" branch
apollo:branchtest max$ git checkout -b new
Switched to a new branch 'new'
Make sure we are on the "new" branch. Indeed we are.
apollo:branchtest max$ git status
# On branch new
nothing to commit (working directory clean)
Let's add a file "new.txt"
apollo:branchtest max$ echo New addition > new.txt
It's on the file system.
apollo:branchtest max$ ls
master.txt new.txt
But is untracked by Git just yet
apollo:branchtest max$ git status
# On branch new
# Untracked files:
# (use "git add ..." to include in what will be committed)
#
# new.txt
nothing added to commit but untracked files present (use "git add" to track)
Let's add the file to be tracked
apollo:branchtest max$ git add .
apollo:branchtest max$ git commit -m "Adding the new file while on the new branch"
[new 67f764e] Adding the new file while on the new branch
1 file changed, 1 insertion(+)
create mode 100644 new.txt
Let's switch back to "master" branch. The "new.txt" is not there. It is tracked under the new branch.
apollo:branchtest max$ git checkout master
Switched to branch 'master'
apollo:branchtest max$ ls
master.txt
Let's switch back to the "new" branch
apollo:branchtest max$ git checkout new
Switched to branch 'new'
apollo:branchtest max$ ls
master.txt new.txt
Now with the "master" branch pushed and the the "new" branch created locally but not pushed to the central repository, let's clone the repository to a different folder.
apollo:max$ git clone git@bitbucket.org:inteist/branchtest.git branchtestNEW
Cloning into 'branchtestNEW'...
remote: Counting objects: 3, done.
remote: Total 3 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (3/3), done.
We checked out the "master" branch, which has the "master.txt" as expected
$ cd branchtestNEW/
$ ls
master.txt
Let's see if the "new" branch is present:
apollo:branchtestNEW max$ git checkout new
error: pathspec 'new' did not match any file(s) known to git.
Nop, it is not, of course, since we did not push it yet.
Now let's push the the "new" local branch to the remote repository. Just to make a case, I will name it "newremote" on the remote.
This is not required. If the second parameter is omitted, then the local and remote names are the same.
We are going to have the "-u" switch so it is tracked in the upstream
apollo:branchtest max$ git push -u origin new:newremote
Counting objects: 4, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (2/2), done.
Writing objects: 100% (3/3), 305 bytes, done.
Total 3 (delta 0), reused 0 (delta 0)
remote: bb/acl: inteist is allowed. accepted payload.
To ssh://git@bitbucket.org/inteist/branchtest.git
* [new branch] new -> newremote
Branch new set up to track remote branch newremote from origin.
Let's clone the repository to yet another folder.
apollo:~ max$ git clone git@bitbucket.org:inteist/branchtest.git branchtestNEWREMOTE
Cloning into 'branchtestNEWREMOTE'...
remote: Counting objects: 6, done.
remote: Compressing objects: 100% (3/3), done.
remote: Total 6 (delta 0), reused 0 (delta 0)
Receiving objects: 100% (6/6), done.
Let's see if there is the "new" branch now.
apollo:~ max$ cd branchtestNEWREMOTE/
apollo:branchtestNEWREMOTE max$ git checkout new
error: pathspec 'new' did not match any file(s) known to git.
Surprise? No. There is no "new" branch of course because we named it "newremote" on the remote and this is how it was checked out.
Was it?
apollo:branchtestNEWREMOTE max$ git checkout newremote
Branch newremote set up to track remote branch newremote from origin.
Switched to a new branch 'newremote'
Yes, it was :)
Let's see what's there:
apollo:branchtestNEWREMOTE max$ ls
master.txt new.txt
And what about the "master" branch?
apollo:branchtestNEWREMOTE max$ git checkout master
Switched to branch 'master'
apollo:branchtestNEWREMOTE max$ ls
master.txt
Surely enough there is only what was tracked under the "master" branch
It's fairly easy to determine whether there is an app that is registered to handle
market://
requests.
In most cases this will be enough and you can just use the "canHandleMarketURI()" but if you want absolutely make sure that the com.android.vending package is present on the device and is registered to handle the
market://
URIs, then you can simply use "hasGooglePlayMarket()" method.
This method seems to work very well for me.
Enjoy and let me know in the comments if you think this can be further improved.
If you just did a commit and you then realized that something is wrong and you need to amend that commit to include your change, then you do:
$ git add .
$ git commit --amend
that’s all. Git will pick up all your changes that you want to the commit and add them to the last commit.
If you need to change/amend a text comment for one of previous commits, it's possible and fairly simple actually. Git allows to do that.
First, you need to issue a rebase command in interactive mode for any number of previous commits. For example:
$ git rebase -i HEAD~5
the above command will let you work with 5 previous commits. You can do various changes for the commits as Git does not have the SVN approach of set in stone commits. But if you just want to change the commit message for one of the commits, it's very simple.
After you issues the rebase in interactive mode command, a default configured editor should open with the list of commits that you specified in the command. If it's ~5 then last 5 commits will be there.
Just change the "pick" to "reword" at the commit you want to update and and then save the file and a new editor window should pop with the old commit message letting you change it to the right one. Change it and save and you should be all set.
***Note that the commits appear in a reverse chronological order in the list so if you have commits with the same message be careful. But of course you can always check yourself with the commit hash.
Note that if you just want to edit the last commit message, it's easier to just fire
$ git commit --amend
What advice do you have for someone considering starting a business?
Do it, but be smart about it. Use your brain. Think about what make the most sense for you. Worry about every dollar you spend before (and even after) you’re profitable. Focus on the things that matter and don’t waste time endlessly redesigning your site or tinkering with new technologies. There’ll be plenty of time for that later.
If you connect your Android Galaxy Nexus or any other Android phone to your OS X computer and the Android File Transfer app is not opening automatically or even if you open it manually, you get a message saying that there is no device connected. You simply need to turn off USB debugging.
While your Android phone is in USB debugging mode (this may not apply to all the phones but it certainly applies to Galaxy Nexus), android file transfer does not recognize it. Once you turn off the USB debugging mode, android file transfer should start recognizing the device once again.
To be able easily read the Proguard obfuscated code, you can use the retrace script supplied with the Android SDK. In order not to provide the full path, you can add an alias. If you are using bash you can do it as follows:
alias retrace='~/ANDROID_SDK/tools/proguard/bin/retrace.sh'
If you are not using bash, then it's pretty similar. Then you just issue the retrace command.
Usage: java proguard.ReTrace [-verbose] <mapping_file> [<stacktrace_file>]