Re: [git-users] Creating a new branch
Another common practise for release naming is the usage of tags. In my projects, for example, I have several tags like v1.0.0, v2.4.2 and such. On 21 Apr 2014 14:53, Simon Joseph Aquilina saquilina...@gmail.com wrote: Hi Konstantin, Thanks for your reply. Reading your reply make me think that it is common practice to delete branches after development on these has finished (for example branches used only to solve a bug or add a feature). Is this so. I was planning to also have branches for releases. For example when I am at release 1.0 I create a branch and then I continue development on master. When I am ready for 2.0 release I create another branch and so on. Is this common practice? Or version mile stone should not be managed this way? On Monday, April 21, 2014 12:23:31 PM UTC+2, Konstantin Khomoutov wrote: On Mon, 21 Apr 2014 02:55:50 -0700 (PDT) Simon Joseph Aquilina saquil...@gmail.com wrote: I am new to git and I would like to know what are the best practices when creating a new branch. For example. If I get a request to do update website title from XYZ to ABC; then should I create a branch named; Update Title? Or I should prefix this as suggested here (http://stackoverflow.com/questions/273695/git-branch- naming-best-practices). Are there any official prefixes? Also I am concerned about the following; Let us say I create the branch named Update Title. Finish the change. Merge back with Master. I then get another request to change title from ABC to DEF. Can I create another branch Update Title. Will not this be confusing? In Git, a branch is merely a pointer to a commit. The crucial bit is pointer -- this means any commit might be pointed to by any number of branches at the same time, and that's why commits do not belong to any branch. Hence whatever meaning you put into a branch name is only in your head -- this does not affect commits reachable from that branch in any way. Moreover, once you merge a branch into another, and subsequently delete the merged branch, the commits made on it stay there forever while there's no more traces left of the deleted branch -- as if it had never existed. So, do whatever you want with your branches. Giving your branches names like Update Title is not a common practice but for purely technical reason: in Git, a branch is represented by a file on a filesystem, and using branch names with funny characters, spaces included might, in some situations, cause problems. So I'd name your branch update-title -- that is, no title casing, no spaces. Another popular approach is to put your bug tracker / ticketing system first: when you're given a task to update the site's title, open a bug for this first and get that bug's ID back, then simply encode the bug's title into the branch name, like bug-12345. This will give you unique branch names. When you merge you branch back to the integration branch you mention the bug's ID in the commit message and then close the bug in the tracker. Note that Git has certain means to attach metadata to your branches. Two of them that I know of are * `git branch --edit-description` which allows you to set a description of the purpose of that branch. This description is used by some other Git tools but you can print it back using the `git config` command: git config branch.bug-12345.description * `git notes` allows you to attach a note to any commit. Notes are not pushed by default (and supposedly the shouldn't be, unless everyone in the team agrees to do that as they were supposed to be used locally). -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Creating a new branch
Take a look (if you did not yet) at this two articles: 1- http://scottchacon.com/2011/08/31/github-flow.html 2- http://nvie.com/posts/a-successful-git-branching-model/ 2014-04-22 3:20 GMT-03:00 Gergely Polonkai gerg...@polonkai.eu: Another common practise for release naming is the usage of tags. In my projects, for example, I have several tags like v1.0.0, v2.4.2 and such. On 21 Apr 2014 14:53, Simon Joseph Aquilina saquilina...@gmail.com wrote: Hi Konstantin, Thanks for your reply. Reading your reply make me think that it is common practice to delete branches after development on these has finished (for example branches used only to solve a bug or add a feature). Is this so. I was planning to also have branches for releases. For example when I am at release 1.0 I create a branch and then I continue development on master. When I am ready for 2.0 release I create another branch and so on. Is this common practice? Or version mile stone should not be managed this way? On Monday, April 21, 2014 12:23:31 PM UTC+2, Konstantin Khomoutov wrote: On Mon, 21 Apr 2014 02:55:50 -0700 (PDT) Simon Joseph Aquilina saquil...@gmail.com wrote: I am new to git and I would like to know what are the best practices when creating a new branch. For example. If I get a request to do update website title from XYZ to ABC; then should I create a branch named; Update Title? Or I should prefix this as suggested here (http://stackoverflow.com/questions/273695/git-branch- naming-best-practices). Are there any official prefixes? Also I am concerned about the following; Let us say I create the branch named Update Title. Finish the change. Merge back with Master. I then get another request to change title from ABC to DEF. Can I create another branch Update Title. Will not this be confusing? In Git, a branch is merely a pointer to a commit. The crucial bit is pointer -- this means any commit might be pointed to by any number of branches at the same time, and that's why commits do not belong to any branch. Hence whatever meaning you put into a branch name is only in your head -- this does not affect commits reachable from that branch in any way. Moreover, once you merge a branch into another, and subsequently delete the merged branch, the commits made on it stay there forever while there's no more traces left of the deleted branch -- as if it had never existed. So, do whatever you want with your branches. Giving your branches names like Update Title is not a common practice but for purely technical reason: in Git, a branch is represented by a file on a filesystem, and using branch names with funny characters, spaces included might, in some situations, cause problems. So I'd name your branch update-title -- that is, no title casing, no spaces. Another popular approach is to put your bug tracker / ticketing system first: when you're given a task to update the site's title, open a bug for this first and get that bug's ID back, then simply encode the bug's title into the branch name, like bug-12345. This will give you unique branch names. When you merge you branch back to the integration branch you mention the bug's ID in the commit message and then close the bug in the tracker. Note that Git has certain means to attach metadata to your branches. Two of them that I know of are * `git branch --edit-description` which allows you to set a description of the purpose of that branch. This description is used by some other Git tools but you can print it back using the `git config` command: git config branch.bug-12345.description * `git notes` allows you to attach a note to any commit. Notes are not pushed by default (and supposedly the shouldn't be, unless everyone in the team agrees to do that as they were supposed to be used locally). -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- Nelson Efrain A. Cruz - https://plus.google.com/106845325502523605960/about Debes ser el cambio que esperas ver en el mundo -Mahatma Gandhi -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Creating a new branch
On Mon, Apr 21, 2014 at 4:35 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Mon, 21 Apr 2014 05:53:41 -0700 (PDT) Simon Joseph Aquilina saquilina...@gmail.com wrote: Thanks for your reply. Reading your reply make me think that it is common practice to delete branches after development on these has finished (for example branches used only to solve a bug or add a feature). Is this so. I was planning to also have branches for releases. For example when I am at release 1.0 I create a branch and then I continue development on master. When I am ready for 2.0 release I create another branch and so on. Is this common practice? Or version mile stone should not be managed this way? Yes, this is a common practice precisely because in Git, merging a branch preserves all commits done on it so there's no much sense to keep such a branch after merging. (Of course, if no further development on it is planned; otherwise it's perfectly fine to continue development and merge again after some time -- Git handles this situation just fine for before merge it locates the last common between the two sides of the merge and if it finds one it performs a three-way diff using all these tree commits so already committed textual data is not considered.) AFAIK there is also no record of what branch a commit was made on so once two branches are merged there is no telling which path is the result of which branch. I believe this is often touted as a flaw of Git. /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: mag...@therning.org jabber: mag...@therning.org twitter: magthe http://therning.org/magnus -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Why does git call me clever when I reword the last commit message?
Turns out that Git has Easter Eggs. You can check out this one that someone found on Stack Overflow, and give your own answer about it too: Why does git call me “clever” when I reword the last commit message?http://stackoverflow.com/questions/23215385/why-does-git-call-me-clever-when-i-reword-the-last-commit-message -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Re: git aws.push stopped working after OS upgrade to Ubuntu 14.04
I had the same problem with a Github enterprise server sitting behind a netscaler with a wildcard cert. I took the easy way out to compiling. I installed linuxbrew, set my paths and then did brew install git. Problem sidestepped (git works fine now). I'm not sure how the brew compile is different, but I expect it is. My guess would be openssl instead of gnutls. https://github.com/Homebrew/linuxbrew Hope that's helpful. -Chris On Friday, April 11, 2014 12:33:25 PM UTC-7, Thomas Ferris Nicolaisen wrote: On Thursday, April 3, 2014 4:22:11 PM UTC+2, John Kolen wrote: I've been successfully pushing my rails app to AWS electric beanstalk for several months. Earlier this week, I upgraded my dev box to Ubuntu 14.04. Now, 'git aws.push' fails when trying to push to AWS with the following error fatal: unable to access 'https://AKIA... 81...@git.elasticbeanstalk.us-east-1.amazonaws.com/v1/repos/6f63742d73746167696e67/commitid/6366...3734/environment/6f63...6e76/': gnutls_handshake() failed: Illegal parameter It's definitely the git operation that's failing as git push -v -f https://AKIA... 81...@git.elasticbeanstalk.us-east-1.amazonaws.com/v1/repos/6f63742d73746167696e67/commitid/6366...3734/environment/6f63...6e76/HEAD:refs/heads/master generates the error. Pushing to my repository on Github does not generate any errors. The error isn't deterministic: occasionally a 'Decrypt error' is thrown instead of the 'Illegal parameter' error. I'm hoping someone has run into this before and there just some configuration and/or recomplie that needs to take place. Thanks in advance! Are you pushing to your Github repository successfully over HTTPS or SSH? This looks like a related problem/solution: http://stackoverflow.com/questions/13524242/error-gnutls-handshake-failed-git-repository -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Git update for OS X Mavericks
I am trying to update Git on OS Mavericks but the download link on the site is not working. Do I need to uninstall Git from my local computer in order to be able to download the link? Is anyone with OS Mavericks able to download the Git installer? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [git-users] Git update for OS X Mavericks
Hi Ryan, From my experience, the fastest way to install Git is installing Xcode from the MAS. However, the best way to install it and keep it with the latest updates and don't depend on Apple on this, will be the way mentioned by Kfir: currently, the version packed with Xcode is 1.8.5.2, and the one from Homebrew is 1.9.2. Hope it helps. On Tue, Apr 22, 2014 at 8:03 PM, Kfir Shay kfir.s...@gmail.com wrote: brew install git done. On Tue, Apr 22, 2014 at 8:33 PM, Ryan Salmons rynsl...@gmail.com wrote: I am trying to update Git on OS Mavericks but the download link on the site is not working. Do I need to uninstall Git from my local computer in order to be able to download the link? Is anyone with OS Mavericks able to download the Git installer? -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout. -- *Juan Obando* | about.me/juanchopx2 -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[git-users] Re: git aws.push stopped working after OS upgrade to Ubuntu 14.04
Thanks, after a few hours of failing to compile pycurl to use openssl, I ended up using this sidestep too. I'm assuming Ubuntu defaults to gnutls for pycurl for licensing reasons? Am thinking it would be nice to have a python-pycurl-gnutls package and python-pycurl-openssl package available in the repositories as gnutls has been known to cause quite a few problems, apparently. On Wednesday, April 23, 2014 9:13:09 AM UTC+10, Christopher Stelma wrote: I had the same problem with a Github enterprise server sitting behind a netscaler with a wildcard cert. I took the easy way out to compiling. I installed linuxbrew, set my paths and then did brew install git. Problem sidestepped (git works fine now). I'm not sure how the brew compile is different, but I expect it is. My guess would be openssl instead of gnutls. https://github.com/Homebrew/linuxbrew Hope that's helpful. -Chris On Friday, April 11, 2014 12:33:25 PM UTC-7, Thomas Ferris Nicolaisen wrote: On Thursday, April 3, 2014 4:22:11 PM UTC+2, John Kolen wrote: I've been successfully pushing my rails app to AWS electric beanstalk for several months. Earlier this week, I upgraded my dev box to Ubuntu 14.04. Now, 'git aws.push' fails when trying to push to AWS with the following error fatal: unable to access 'https://AKIA... 81...@git.elasticbeanstalk.us-east-1.amazonaws.com/v1/repos/6f63742d73746167696e67/commitid/6366...3734/environment/6f63...6e76/': gnutls_handshake() failed: Illegal parameter It's definitely the git operation that's failing as git push -v -f https://AKIA... 81...@git.elasticbeanstalk.us-east-1.amazonaws.com/v1/repos/6f63742d73746167696e67/commitid/6366...3734/environment/6f63...6e76/HEAD:refs/heads/master generates the error. Pushing to my repository on Github does not generate any errors. The error isn't deterministic: occasionally a 'Decrypt error' is thrown instead of the 'Illegal parameter' error. I'm hoping someone has run into this before and there just some configuration and/or recomplie that needs to take place. Thanks in advance! Are you pushing to your Github repository successfully over HTTPS or SSH? This looks like a related problem/solution: http://stackoverflow.com/questions/13524242/error-gnutls-handshake-failed-git-repository -- You received this message because you are subscribed to the Google Groups Git for human beings group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
