Re: [git-users] creating a new branch
what I was trying to say is: your repo contains the files inside administrator folder, so you can make a new folder called administrator inside your repo and move all the files in the repo inside that folder. Then the folder that contains your repo can be renamed to appointments and moved one level up to replace the old appointments folder. At the end you will have a repo that contains your administrator folder and all the old history will be there, plus the history of the last change. Also your file structure will be the same at the end. I'm saying do not make a new repo, just make the change you need, maybe this is not what you want at all. El lun, jul 20, 2015 12:39, Dimitris Papageorgiou escribió: > Why move the repo one folder up... > > It is already there...at C:\Apache24\htdocs\Appointments\Administrator\ > > I do not quite understand...but more importantly...*changing the dir > structure of my web project it is something I want to avoid..*.. > > Τη Δευτέρα, 20 Ιουλίου 2015 - 6:17:52 μ.μ. UTC+3, ο χρήστης Nelson Efrain > A. Cruz έγραψε: > >> Assuming that those are the only folders (and files), one solution could >> be: move all your files (git mv) inside a folder called >> "Administrator" (like C:\Apache24\htdocs\ >> Appointments\Administrator\Administrator) and then move the repo one >> folder up. >> >> I think this will be the easiest solution, of course there are other ways >> but they are much more complex. >> >> >> El lun., 20 de jul. de 2015 a la(s) 10:50 a. m., Dimitris Papageorgiou < >> foryo...@gmail.com> escribió: >> > I have git init a working directory...here is >>> it C:\Apache24\htdocs\Appointments\Administrator >>> >>> I now want to create git init another directory which sits *above *the >>> aforementionedC:\Apache24\htdocs\Appointments >>> >>> Soin essenceI want to disregard/delete the old >>> branch/repo(C:\Apache24\htdocs\Appointments\Administrator)...*but keep >>> the commits and transfer them to the new repo.* >>> >>> How am I going to do it? I hope I was clear. >>> >>> -- >>> 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+...@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. > -- 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
Why not try: git bundle --all MyRepo.bundle which will create a single file which has "zipped/Tar'd" the repo in git format, and you can then delete the old repo and re-import/clone from the bundle. The bundle knows nothing of the higher level directory structure, only the structure of the project from the top of the workdir downward, so you can re-clone (or pull from) the bundle to anywhere! All the best with the directory move. (don't forget the RTM (carefully) step;-) Philip - Original Message - From: Dimitris Papageorgiou To: git-users@googlegroups.com Sent: Monday, July 20, 2015 4:39 PM Subject: Re: [git-users] creating a new branch Why move the repo one folder up... It is already there...at C:\Apache24\htdocs\Appointments\Administrator\ I do not quite understand...but more importantly...changing the dir structure of my web project it is something I want to avoid Τη Δευτέρα, 20 Ιουλίου 2015 - 6:17:52 μ.μ. UTC+3, ο χρήστης Nelson Efrain A. Cruz έγραψε: Assuming that those are the only folders (and files), one solution could be: move all your files (git mv) inside a folder called "Administrator" (like C:\Apache24\htdocs\Appointments\Administrator\Administrator) and then move the repo one folder up. I think this will be the easiest solution, of course there are other ways but they are much more complex. El lun., 20 de jul. de 2015 a la(s) 10:50 a. m., Dimitris Papageorgiou escribió: I have git init a working directory...here is it C:\Apache24\htdocs\Appointments\Administrator I now want to create git init another directory which sits above the aforementionedC:\Apache24\htdocs\Appointments Soin essenceI want to disregard/delete the old branch/repo(C:\Apache24\htdocs\Appointments\Administrator)...but keep the commits and transfer them to the new repo. How am I going to do it? I hope I was clear. -- 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+...@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. -- 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
Why move the repo one folder up... It is already there...at C:\Apache24\htdocs\Appointments\Administrator\ I do not quite understand...but more importantly...*changing the dir structure of my web project it is something I want to avoid..*.. Τη Δευτέρα, 20 Ιουλίου 2015 - 6:17:52 μ.μ. UTC+3, ο χρήστης Nelson Efrain A. Cruz έγραψε: > > Assuming that those are the only folders (and files), one solution could > be: move all your files (git mv) inside a folder called > "Administrator" (like C:\Apache24\htdocs\ > Appointments\Administrator\Administrator) and then move the repo one > folder up. > > I think this will be the easiest solution, of course there are other ways > but they are much more complex. > > > El lun., 20 de jul. de 2015 a la(s) 10:50 a. m., Dimitris Papageorgiou < > foryo...@gmail.com > escribió: > >> I have git init a working directory...here is >> it C:\Apache24\htdocs\Appointments\Administrator >> >> I now want to create git init another directory which sits *above *the >> aforementionedC:\Apache24\htdocs\Appointments >> >> Soin essenceI want to disregard/delete the old >> branch/repo(C:\Apache24\htdocs\Appointments\Administrator)...*but keep >> the commits and transfer them to the new repo.* >> >> How am I going to do it? I hope I was clear. >> >> -- >> 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+...@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
Assuming that those are the only folders (and files), one solution could be: move all your files (git mv) inside a folder called "Administrator" (like C:\Apache24\htdocs\ Appointments\Administrator\Administrator) and then move the repo one folder up. I think this will be the easiest solution, of course there are other ways but they are much more complex. El lun., 20 de jul. de 2015 a la(s) 10:50 a. m., Dimitris Papageorgiou < foryou1...@gmail.com> escribió: > I have git init a working directory...here is > it C:\Apache24\htdocs\Appointments\Administrator > > I now want to create git init another directory which sits *above *the > aforementionedC:\Apache24\htdocs\Appointments > > Soin essenceI want to disregard/delete the old > branch/repo(C:\Apache24\htdocs\Appointments\Administrator)...*but keep > the commits and transfer them to the new repo.* > > How am I going to do it? I hope I was clear. > > -- > 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
On Mon, Apr 21, 2014 at 4:35 PM, Konstantin Khomoutov wrote: > On Mon, 21 Apr 2014 05:53:41 -0700 (PDT) > Simon Joseph Aquilina 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.
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 : > 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" > 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 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
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" 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 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
On Mon, 21 Apr 2014 05:53:41 -0700 (PDT) Simon Joseph Aquilina 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.) -- 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
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 > 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.
Re: [git-users] Creating a new branch
On Mon, 21 Apr 2014 02:55:50 -0700 (PDT) Simon Joseph Aquilina 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.
