Re: [git-users] creating a new branch

2015-07-20 Thread Nelson Efrain A. Cruz
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 foryou1...@gmail.com
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

2015-07-20 Thread Philip Oakley
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 
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

2015-07-20 Thread 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 
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

2015-07-20 Thread Dimitris Papageorgiou
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 javascript: 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 javascript:.
 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

2014-04-22 Thread 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 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

2014-04-22 Thread Nelson Efrain A. Cruz
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

2014-04-22 Thread Magnus Therning
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.


Re: [git-users] Creating a new branch

2014-04-21 Thread Konstantin Khomoutov
On Mon, 21 Apr 2014 02:55:50 -0700 (PDT)
Simon Joseph Aquilina saquilina...@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.


Re: [git-users] Creating a new branch

2014-04-21 Thread Simon Joseph Aquilina
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 javascript: 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

2014-04-21 Thread Konstantin Khomoutov
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.)

-- 
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.