Robert Muir wrote:
Right, I'm positive this (pull requests) is github :)
Well, as I said, I dont KNOW exactly where the border between git and
github is, but I have a very mature logical sence and a fair amount of
knowledge about information theory. The rest of the content in the mail
is based only on my logical sence. I would love to be proved wrong and
told that my logical sence played a trick on me :-)
My thoughts are that SVN is not dumb (always thinks the best about
others :-) ), it just hasnt got enough information to help merging in a
better way than what we have all experienced with SVN. If SVN is not
dumb, the only way you can be better is by having more information. And
I would really be mistaken if this is not the reason that git is able to
act in a smarter way when merging. It simply has more information than SVN!
So what kind of information does it have that SVN does not have? My
guess is, that it knows where code came from and how it developed
throughout the life of a hierarchy of branches/forks with a history
going all the way back to the original common ancestor of the branches.
If you have this kind of information I would imagine you can do smarter
merging, and most important you can maintain the detailed information
about where code came from and how it developed even on the target side
of the merge, so that you can also be smarter when that branch/fork has
to be merged somewhere else. So when I said in a prior mail "...else I
couldnt imagine how you get the advantages you get. Remember that when
using git you actually run a "repository" on every developers local
machines. When you commit, you commit only to you local "repository".
You need to "push" in order to have it "upstreamed" (as they call it)"
it was acutally an attempt to make an argument that "all the smartness
must be in git" - I understand it was a very unclear argument.
But the thing is that the local repository is NOT github - it is git. I
dont have github on my local machine :-) And it is information about the
commits I did to my local git repository that potentially can make the
entire process smarter. Without information from my local git repository
about how I changed the code, it is not possible (again only based on my
mature logical sence) for the receiving git-repository (eventually
github) to be smarter than SVN. Therefore, since the clever information
tracking needs to go on on my local machine, where only git (not github)
lives, I argue that the smart thing is in git and not in github.
Actually I couldnt imagine that a "pull requests" isnt just a convenient
alternative to sending a mail to the owners/committers of the target
git-fork asking them to downstream this and that commit from my source
git-fork. I know it is a lot to claim, based alone on logical sence, but
I trust my logical sence very much :-)
Below some thought about what kind of information you will need to be
smarter than SVN - again just completely on top of my own head (I really
dont know anything about git :-) ):
Imagine a file in a repository - content of file:
*abcd
efgh
ijkl
mnop
*
Now we fork (branch) into three forks - fork1, fork2 and fork3
On fork1 the content of the file is changed into
*abcd
1234
efgh
ijkl
mnop
*A line between original line #1 and #2 was inserted - a line with the
content "1234"
On fork2 the content of the file is changed into
*abcd
efxyz
ijkl
mnop
*The original line #2 was changed
Now you push the changes on fork1 into fork2. The net result on fork2
obviously is
*abcd
1234
efxyz
ijkl
mnop
* In the meanwhile on fork3 the content of the file has changed into
*abcd
efgh
ij
mnop
*The original line #3 was changed
Now you want to push the changes on fork2 (where some of it came from
fork1) into fork3
Basically you have the problem of merging the following two versions of
the file:
*abcd
1234
efxyz
ijkl
mnop
*and
*abcd
efgh
ij
mnop
*In SVN you have no other information than the content of the two
versions of the file about to be merged. With that amount of information
it is impossible to make a solid decission about the net result -->
merge conflict.
If you had information about the history of changes since the common
original "a line between original line #1 and #2 was inserted", "the
original line #2 was changed" and "the original line #3 was changed",
there would be no doubt that the correct net result must be
*abcd
1234
efxyz
ij
mnop
*No merge conflict! I believe the thing about git is that is has this
information and therefore that is can be smart.
So back to the my line of argument, that it has to be git and not github:
* The information needed to be smart in the final step has to be picked
up in the early steps
* The early steps are (potentially) going on outside github
* Therefore github cannot be "the smart one"
A very important thing for this to work is that everything is a fork. In
git a developer does not checkout a branch to do modifications on it. He
forks the branch to make his changes, and afterwards he pushes the
changes to the branch he forked from (his "upstream"). Those pushes are
explicit/built-in operations in git, and therefore git has a change to
pick up and maintain the necessary information, and keep track of it
transitively throughout a long chain of code-modifications. In SVN
merging is not a SVN-thing - only the commit is. I SVN when you merge
changes from branch1 into branch2, it just ends up in a commit on
branch2 - no information is maintained about fact that the changes in
this commit actually came from this and that change on branch1 (and that
those changes originally came from this and that changes on branchX and
branchY). For all of this to work everything needs to go on on separate
branches (forks) and a change to a branch only happens by pushes
(merges) from other branches (forks).
It is all about information - git has it, SVN doesnt. And my logical
sence tells me that is has to be git and not github!
:-) Now tell me that I am stupid :-)
