lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Per Steffensen <>
Subject Re: pro coding style
Date Sat, 01 Dec 2012 12:59:00 GMT
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:
Now we fork (branch) into three forks - fork1, fork2 and fork3
On fork1 the content of the file is changed into
*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
*The original line #2 was changed

Now you push the changes on fork1 into fork2. The net result on fork2 
obviously is

* In the meanwhile on fork3 the content of the file has changed into
*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:
*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
*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 :-)

View raw message