{"thread":{"id":"25184","subject":"Really beginner on Version Control","startedAt":"2010-09-21T14:42:13Z","lastAt":"2010-09-24T21:25:50Z","messageCount":17,"participants":["FernandoBasso","Thomas Moulard","Andreas Ericsson","Jakub Narebski","Andrew Keller","Thomas Hochstein","Tor Arntsen","Dmitry Potapov","Enrico Weigelt","Eric Raible"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"151216","messageId":"1285080133451-5555023.post@n2.nabble.com","threadId":"25184","inReplyTo":null,"subject":"Really beginner on Version Control","fromName":"FernandoBasso","fromEmail":"fernandobasso.br@gmail.com","sentAt":"2010-09-21T14:42:13Z","receivedAt":"2010-09-21T14:42:13Z","isPatch":false,"sender":{"key":"fernandobasso.br@gmail.com","avatar":"https://gravatar.com/avatar/ec8132f27c0094bfa952b7260d6b490a2cc209c382ff1fb86cad0b3397daf902?d=mp&s=160"},"body":"\nI am really a beginner in. Bear with me please.\n\nWhy do we merge, say a testing branch into the master branch ? What is the\nuse of it ?\n\nWhen there is a conflict when merging branches (merging the testing into the\ncurrent branch), should I edit the 'current' branch or the 'testing' branch\n?\n\nShould both branches have exactly the same code so that they can be merged\nwithout conflicts ?\n\n\n-- \nView this message in context: http://git.661346.n2.nabble.com/Really-beginner-on-Version-Control-tp5555023p5555023.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"151219","messageId":"AANLkTimm=x37EiyGObfJ_gdU6OtGbdCCOEw0XjVDH_oQ@mail.gmail.com","threadId":"25184","inReplyTo":"1285080133451-5555023.post@n2.nabble.com","subject":"Re: Really beginner on Version Control","fromName":"Thomas Moulard","fromEmail":"thomas.moulard@gmail.com","sentAt":"2010-09-21T14:59:12Z","receivedAt":"2010-09-21T14:59:12Z","isPatch":false,"sender":{"key":"thomas.moulard@gmail.com","avatar":"https://gravatar.com/avatar/4396971c8087ce63f120744424ae346e88bf9bb537c3d7386f0751790890aa36?d=mp&s=160"},"body":"Hi!\n\nOn Tue, Sep 21, 2010 at 4:42 PM, FernandoBasso\n wrote:\n>\n> I am really a beginner in. Bear with me please.\n>\n> Why do we merge, say a testing branch into the master branch ? What is the\n> use of it ?\n\nUsusally, one develops a feature on a separate branch to avoid polluting\nthe \"master\" branch with non working or fragile commits and prevent other people\nfrom working.\n\nYou always merge a branch into the branch you *are* in.\nFor instance:\n# Switch to master branch.\n$ git checkout master\n\n# List the available branches.\n$ git branch\n* master\n my-new-feature\n\n# Merge the topic branch into master.\n$ git merge my-new-feature\n\nHere what I call a topic branch is what you call a \"testing\" branch.\n\n>\n> When there is a conflict when merging branches (merging the testing into the\n> current branch), should I edit the 'current' branch or the 'testing' branch\n> ?\n\nIf there is a conflict, in theory it means that *both* sides have\nchange a same location\nin a tracked file.\nUsually, it means that you have to take *both* contents and depending\non the context\nwrite manually the result.\n\nFor instance, one can fork master to create a topic branch, then\nchanges are made\nin the topic branch and in master. When you merge back your topic\nbranch you want\nto integrate your changes but also preserving the changes that have\nbeen made to master\nbetween the time the topic branch has been created and now.\n\n> Should both branches have exactly the same code so that they can be merged\n> without conflicts ?\n\nIn general, yes.\nPlease note that git can work around whitespace problems (whitespace\nversus tab and \\n versus \\r\\n).\n\nYou may also want to google \"git workflow\" to get a rough idea about\nhow to manage a project\nwith git and how to do more advanced stuff with topic branches.\n\nI hope it helps,\n-- \nThomas Moulard\n"},{"id":"151466","messageId":"20100921145922.GA14711@nibiru.local","threadId":"25184","inReplyTo":"1285080133451-5555023.post@n2.nabble.com","subject":"Re: Really beginner on Version Control","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2010-09-21T14:59:22Z","receivedAt":"2010-09-21T14:59:22Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* FernandoBasso wrote:\n\nHi,\n\n> Why do we merge, say a testing branch into the master branch ? \n> What is the use of it ?\n\nThat heavily depends on your workflows.\n\nI'm a big friend of topic-branches, which means that I'm alsways\nworking on one topic (eg. fixing one particular bug or developing\nsome feature) in it's own branch. When it's decided that the code\nis ready to go mainline, it will be merged into there (normally\nthe \"master\" branch).\n\nAnd I really advise rebasing the topic branch onto the mainline,\nwhich means, the changes that happened in the topic branch after\nthe forkoff, will be applied step by step ontop the mainline,\nso coming after those happend meanwhile in the mainline.\n(use the -ff option on merge if it should show up in history\nas merge instead of sequential additions - see \"fast forward\").\nThis can reduce the chance of conflicts dramatically and make\nthem easier to resolve.\n\n> When there is a conflict when merging branches (merging the\n> testing into the current branch), should I edit the 'current' \n> branch or the 'testing' branch ?\n\nYou can resolve the conflict within the merge (git will tell you\nthe conflicts and leave conflict markers in the source code - \nsee \"resolving conflicts\").\n\nAs said above, I always rebase the to-be-merged branch ontop\nthe destination and resolve conflicts there. After this there\ncan be no conficts as the rebased branch is now an direct\ndescendant of the merge target (so, fast-forward possible).\n\n> Should both branches have exactly the same code so that they \n> can be merged without conflicts ?\n\nObviously not - in this case you wouldn't even need a merge.\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone: +49 36207 519931 email: weigelt@metux.de\n mobile: +49 151 27565287 icq: 210169427 skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"},{"id":"151223","messageId":"4C98DFF7.2030801@op5.se","threadId":"25184","inReplyTo":"1285080133451-5555023.post@n2.nabble.com","subject":"Re: Really beginner on Version Control","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2010-09-21T16:40:23Z","receivedAt":"2010-09-21T16:40:23Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 09/21/2010 04:42 PM, FernandoBasso wrote:\n> \n> I am really a beginner in. Bear with me please.\n> \n> Why do we merge, say a testing branch into the master branch ? What is the\n> use of it ?\n> \n\nBecause the sum of the whole is greater than the parts. Most features in git\nfor example are developed on topic branches. This makes it possible to keep\nunfinished code separate from the production branch that people actually use.\n\n> When there is a conflict when merging branches (merging the testing into the\n> current branch), should I edit the 'current' branch or the 'testing' branch\n> ?\n> \n\nYou should edit the working tree, since that's where the conflict will be\nstaged. When you're done, commit the results and that will be a new commit\non the branch you're on.\n\n> Should both branches have exactly the same code so that they can be merged\n> without conflicts ?\n> \n\nBoth branches should most definitely not have exactly the same code. If they\ndid, there would be no point in merging them. The merge-result shouldn't\nhave the same code as any of the branches either, unless you actually want\nto throw one branch away, in which case you'd be far better off doing just\nthat.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"151261","messageId":"m3mxrak937.fsf@localhost.localdomain","threadId":"25184","inReplyTo":"1285080133451-5555023.post@n2.nabble.com","subject":"Re: Really beginner on Version Control","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2010-09-21T23:35:26Z","receivedAt":"2010-09-21T23:35:26Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"FernandoBasso writes:\n\n> I am really a beginner in. Bear with me please.\n> \n> Why do we merge, say a testing branch into the master branch ? What\n> is the use of it ?\n\nShort answer: to make it visible. Usually only a specific set of\nbranches is published.\n\nLong answer: the real question is why we should use topic branches.\nThe answer is to keep unfinished code separate and not visible untill\nit is finished and ready to be shown. \n\nYou create new [private] branch for developing a feature, 'testing' in\nyour example, develop code on it, and when code is ready you make it\nvisible by putting it on 'master' branch. One of possibilities is to\nmerge 'testing' branch into 'master'. Then people can use those\nchanges taking / fetching from a 'master' branch.\n \n> When there is a conflict when merging branches (merging the testing\n> into the current branch), should I edit the 'current' branch or the\n> 'testing' branch ?\n\nYou edit files in your working directory. You are on current\n('master') branch, and you are creating state of the new [merge]\ncommit.\n\nEdit files, add those files after resolving conflict, then run 'git\ncommit' which would notice that you were in conflicted merge and do\nthe right thing.\n\n> \n> Should both branches have exactly the same code so that they can be\n> merged without conflicts ?\n\nNo, if there is merge conflict you edit the files so they make sense,\nincorporating your changes made on 'testing' branch with the changes\nthat were made on 'master' branch since branching point (merge base)\nof 'testing' and 'master'.\n\nBranches would merge without conflict if:\n\n1. You did the changes on 'testing', while 'master' didn't move at all.\n This is so called \"fast-forward\" case and wouldn't even create merge\n conflict without --no-ff option.\n\n2. Changes on 'testing' and on 'master' (since merge base) touch\n different files. This is so called \"trivial\" merge (tree level\n merge to be more exact).\n\n3. Changes on 'testing' and on 'master' touch different areas of\n files, so that textual 3-way merge succeeds.\n\nHTH\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"151263","messageId":"1285114417273-5557145.post@n2.nabble.com","threadId":"25184","inReplyTo":"m3mxrak937.fsf@localhost.localdomain","subject":"Re: Really beginner on Version Control","fromName":"FernandoBasso","fromEmail":"fernandobasso.br@gmail.com","sentAt":"2010-09-22T00:13:37Z","receivedAt":"2010-09-22T00:13:37Z","isPatch":false,"sender":{"key":"fernandobasso.br@gmail.com","avatar":"https://gravatar.com/avatar/ec8132f27c0094bfa952b7260d6b490a2cc209c382ff1fb86cad0b3397daf902?d=mp&s=160"},"body":"\nI really appreciate your help. All of you. This is all starting to make sense\nto me thanks to you guys.\n\nNow, what are the possible ways that we can get to a conflict when merging\nbranches ? I'm doing some study tests, and some times I get conflicts, some\ntimes I don't. I couldn't really understand what causes them or not yet. \n\nFor instance, I have 'hello' in line 2 of site.php in the master branch. I\ngo to the testing branch, edit site.php, change 'hello' for 'world' at the\nsame line, commit and got back to master. I merge testing into master and I\nget no conflicts. Shouldn't it conflict ? (site.php in master also contains\nthe string 'world' in the place of 'hello' now).\n\n-- \nView this message in context: http://git.661346.n2.nabble.com/Really-beginner-on-Version-Control-tp5555023p5557145.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"151271","messageId":"1AF8A1BC-1E52-4385-A0FC-16A04B4724FF@kellerfarm.com","threadId":"25184","inReplyTo":"1285114417273-5557145.post@n2.nabble.com","subject":"Re: Really beginner on Version Control","fromName":"Andrew Keller","fromEmail":"andrew@kellerfarm.com","sentAt":"2010-09-22T03:52:19Z","receivedAt":"2010-09-22T03:52:19Z","isPatch":false,"sender":{"key":"andrew@kellerfarm.com","avatar":"https://avatars.githubusercontent.com/u/304204?v=4"},"body":"On Sep 21, 2010, at 8:13 PM, FernandoBasso wrote:\n\n> I really appreciate your help. All of you. This is all starting to make sense\n> to me thanks to you guys.\n> \n> Now, what are the possible ways that we can get to a conflict when merging\n> branches ? I'm doing some study tests, and some times I get conflicts, some\n> times I don't. I couldn't really understand what causes them or not yet. \n> \n> For instance, I have 'hello' in line 2 of site.php in the master branch. I\n> go to the testing branch, edit site.php, change 'hello' for 'world' at the\n> same line, commit and got back to master. I merge testing into master and I\n> get no conflicts. Shouldn't it conflict ? (site.php in master also contains\n> the string 'world' in the place of 'hello' now).\n\nIf I am understanding correctly, then this is an example of a fast-forward merge.\n\nIt sometimes helps to think of a series of commits as a series of changes, rather than a series of snapshots. A merge conflict will occur when you *modify* overlapping sections of the same file in each branch. The key word here is modify. When you ask git to merge testing into master, you are not asking git to look at the code and figure out which one is \"correct\". Instead, you are asking git to take the changes in testing, and the changes in master, each since they diverged, and create a new commit that incorporates both changes.\n\nThe only thing is, in your example, since master did not progress since testing diverged, git simply thinks of it as being \"behind\" testing, so you end up with a fast-forward merge, where master simply acquires the newer commits that testing has. You can think of it as a special case optimization. No need to make a merge commit if master is just behind and needs to be caught up.\n\nIf you would like to cause a merge conflict, then you should modify the same line of the same file in two different branches, and then try to merge the branches. This is similar to what you just did, except that both master and testing must progress individually before you merge.\n\n~ Andrew Keller\n"},{"id":"151279","messageId":"gcvg.1009220931.2922@thorondor.akallabeth.de","threadId":"25184","inReplyTo":"1285114417273-5557145.post@n2.nabble.com","subject":"Re: Really beginner on Version Control","fromName":"Thomas Hochstein","fromEmail":"thh@inter.net","sentAt":"2010-09-22T07:31:50Z","receivedAt":"2010-09-22T07:31:50Z","isPatch":false,"sender":{"key":"thh@inter.net","avatar":"https://avatars.githubusercontent.com/u/365129?v=4"},"body":"FernandoBasso schrieb:\n\n> For instance, I have 'hello' in line 2 of site.php in the master branch. I\n> go to the testing branch, edit site.php, change 'hello' for 'world' at the\n> same line, commit and got back to master. I merge testing into master and I\n> get no conflicts. Shouldn't it conflict ? \n\nNo.\n\nYou have changed \"hello\" to world in your testing branch. When you\nmerge your testing branch back to your master branch, git will apply\nall changes you made in testing to master. That's not a problem in\nthat case, as master was not changed since testing was branched from\nit.\n\nAnother example:\n\nYou create a testing branch from master. Now you'll go to your testing\nbranch, change \"hello\" to \"world\", commit, go back to your master\nbranch and change \"hello\" to \"all\" there (and commit). Now you'll get\na conflict when trying to merge your testing branch - git will try to\napply the change from testing (i.e. change \"hello\" to \"world\"), but\ncan't to that as \"hello\" was already changed to \"all\" in your master\nbranch. git doesn't know which of this conflicting [1] changes is the\nright one you'll want to keep, so you have to tell it.\n\nMerging a branch into master will make git try to apply all changes\nthat you made in this branch to the master branch. That's easy if\nmaster didn't change since you created your testing branch from it.\nIt's also easy if master _did_ change, but never at the same places as\nin testing. You'll only get a conflict if you change the same line(s)\nin master _and_ in testing.\n\nRegards,\n-thh\n\n[1] That's why it's called a conflict.\n"},{"id":"151290","messageId":"1285155943433-5558696.post@n2.nabble.com","threadId":"25184","inReplyTo":"1AF8A1BC-1E52-4385-A0FC-16A04B4724FF@kellerfarm.com","subject":"Re: Really beginner on Version Control","fromName":"FernandoBasso","fromEmail":"fernandobasso.br@gmail.com","sentAt":"2010-09-22T11:45:43Z","receivedAt":"2010-09-22T11:45:43Z","isPatch":false,"sender":{"key":"fernandobasso.br@gmail.com","avatar":"https://gravatar.com/avatar/ec8132f27c0094bfa952b7260d6b490a2cc209c382ff1fb86cad0b3397daf902?d=mp&s=160"},"body":"\n On 09/22/2010 12:52 AM, Andrew Keller wrote:\n> The only thing is, in your example, since master did not progress since\n> testing diverged, \n> git simply thinks of it as being \"behind\" testing...\n\n\n\nYou have used the word 'behind'. I think 'time' what is making me fail to\nunderstand git merging. It depends on which branch I have changed last. Not\nonly if I changed the same line in both branches. If I change (same line)\nthe master, commit. Change testing commit. Merge testing into master, they\nwill not conflict because master haven't changed since testing changed.\nMaster is \"behind\" testing.\n\n-- \nView this message in context: http://git.661346.n2.nabble.com/Really-beginner-on-Version-Control-tp5555023p5558696.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"151291","messageId":"1285156189754-5558706.post@n2.nabble.com","threadId":"25184","inReplyTo":"1285155943433-5558696.post@n2.nabble.com","subject":"Re: Really beginner on Version Control","fromName":"FernandoBasso","fromEmail":"fernandobasso.br@gmail.com","sentAt":"2010-09-22T11:49:49Z","receivedAt":"2010-09-22T11:49:49Z","isPatch":false,"sender":{"key":"fernandobasso.br@gmail.com","avatar":"https://gravatar.com/avatar/ec8132f27c0094bfa952b7260d6b490a2cc209c382ff1fb86cad0b3397daf902?d=mp&s=160"},"body":"\nOn 09/22/2010 04:35 AM, Thomas Hochstein [via git] wrote:\n>\n> You have changed \"hello\" to world in your testing branch. When you\n> merge your testing branch back to your master branch, git will apply\n> all changes you made in testing to master. That's not a problem in\n> that case, as master was not changed since testing was branched from\n> it.\n>\n\nOkay. So, If I have not changed master since I last edited testing, I can\nmerge testing into master without problem.\n\nI merge testing into master (without problems) and I change master and merge\ntesting into master again (without any further modification). Now, git\nthinks that the changes I've just made in master are more important than the\nold changes in testing ?\n\n-- \nView this message in context: http://git.661346.n2.nabble.com/Really-beginner-on-Version-Control-tp5555023p5558706.html\nSent from the git mailing list archive at Nabble.com.\n"},{"id":"151293","messageId":"AANLkTinDevPY63WDfPTWVsR2xDNCZOU=aPwzu9r-Zpi+@mail.gmail.com","threadId":"25184","inReplyTo":"1285156189754-5558706.post@n2.nabble.com","subject":"Re: Really beginner on Version Control","fromName":"Tor Arntsen","fromEmail":"tor@spacetec.no","sentAt":"2010-09-22T12:50:22Z","receivedAt":"2010-09-22T12:50:22Z","isPatch":false,"sender":{"key":"tor@spacetec.no","avatar":null},"body":"On Wed, Sep 22, 2010 at 13:49, FernandoBasso wrote:\n\n> I merge testing into master (without problems) and I change master and merge\n> testing into master again (without any further modification). Now, git\n> thinks that the changes I've just made in master are more important than the\n> old changes in testing ?\n\nThose old changes were already merged, so they won't get merged again.\nGit keeps track of which commits have been merged.\nIf master originally consists of commits A, B, C, then you branch and\nmake 'testing', then testing will start out with A, B, C. Then you\nadd D to testing. Now master is A, B, C as before, testing is A, B, C,\nD. Then you merge. Now master will be A, B, C, D too. Then you add E\nto master: A, B, C, D, E. If you try to merge testing to master again\nGit sees that testing contains nothing that's not in master already.\n\n(The letters stand for commits, i.e. changes you commited.)\n\n-Tor\n"},{"id":"151328","messageId":"AANLkTi=4qdjicBZs=yPWmAu5B+GePQeTpOr80PBi3+29@mail.gmail.com","threadId":"25184","inReplyTo":"1285080133451-5555023.post@n2.nabble.com","subject":"Re: Really beginner on Version Control","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-09-22T22:10:27Z","receivedAt":"2010-09-22T22:10:27Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Tue, Sep 21, 2010 at 6:42 PM, FernandoBasso\n wrote:\n>\n> Why do we merge, say a testing branch into the master branch ? What is the\n> use of it ?\n\nWe usually don't do that, because it goes against recommended git workflows\nhttp://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html\n\nWith Git, you typically merge your stable branch to to your main\ndevelopment branch or you merge some feature branch to master if you\nconsider it to be mature enough to be included in the next release.\n\n> When there is a conflict when merging branches (merging the testing into the\n> current branch), should I edit the 'current' branch or the 'testing' branch\n\nYou edit files in your working directory to resolve conflicts, after\nyou commit the result to your current branch.\n\n> Should both branches have exactly the same code so that they can be merged\n> without conflicts ?\n\nNo... There are different merging strategies, and Git is flexible enough\nto allow you to specify your own merging strategy for some files. The\ndefault merging strategy relies on the context to find if there is any\nconflict. It means that the same file has been edited around the same\nplace (around the same line), then it will generate a conflict.\n\nThere is one important thing to keep in mind when it comes to merges.\nMerge conflict are your friends and not your enemies. In other words,\nthey warn you about changes to some files that can contradict each\nother, so you need to use your brain to resolve them gracefully.\nUsually, they do pretty good job at that, but in some rare cases, merge\nwithout any merge conflict can produce unworkable code. So, after any\nnon-trivial merge, you should do testing. If testing reveals some\nproblem then you should correct them. Git allows you amend any last\ncommit (including the merge commit) using:\n\ngit commit --amend\n\nIf two branches are diverged a long time ago, it is very useful to look\nat history of those branches to find what changes caused the conflict.\nYou can do that using the following command:\n\ngitk --merge\n\nor if you are interested only in one particular file then:\n\ngitk --merge this-file\n\n\nDmitry\n"},{"id":"151329","messageId":"AANLkTin60S-6dtSmcYGqQTgBbpqXFLJWhJWfCWgpiA0E@mail.gmail.com","threadId":"25184","inReplyTo":"1285114417273-5557145.post@n2.nabble.com","subject":"Re: Really beginner on Version Control","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-09-22T22:13:18Z","receivedAt":"2010-09-22T22:13:18Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Sep 22, 2010 at 4:13 AM, FernandoBasso\n wrote:\n>\n> For instance, I have 'hello' in line 2 of site.php in the master branch. I\n> go to the  testing branch, edit site.php, change 'hello' for 'world' at the\n> same line, commit and got back to master. I merge testing into master and I\n> get no conflicts. Shouldn't it conflict ? (site.php in master also contains\n> the string 'world' in the place of 'hello' now).\n\nConflicts happen only if two branches have contradictory _changes_ to\nthe same line. If you merge some branch, it means you accept all changes\nfrom it. So, if one branch has no changes, and the other branch has some\nchanges then all changes from the other branch will be accepted without\nany conflict. The special case when there is no changes on your current\nbranch but only on the merged branch is often described as fast-forward\nmerge, because the result merge does not produce any new commit, but\nonly advance the current state to the state of the other branch.\n\n\nDmitry\n"},{"id":"151330","messageId":"AANLkTin27ny4f2rPZSRWDVj3gOF1oH0t17WmsKH8TYXz@mail.gmail.com","threadId":"25184","inReplyTo":"1285155943433-5558696.post@n2.nabble.com","subject":"Re: Really beginner on Version Control","fromName":"Dmitry Potapov","fromEmail":"dpotapov@gmail.com","sentAt":"2010-09-22T22:15:38Z","receivedAt":"2010-09-22T22:15:38Z","isPatch":false,"sender":{"key":"dpotapov@gmail.com","avatar":"https://avatars.githubusercontent.com/u/6568595?v=4"},"body":"On Wed, Sep 22, 2010 at 3:45 PM, FernandoBasso\n wrote:\n>\n>  On 09/22/2010 12:52 AM, Andrew Keller wrote:\n>> The only thing is, in your example, since master did not progress since\n>> testing diverged,\n>> git simply thinks of it as being \"behind\" testing...\n>\n>\n> You have used the word 'behind'. I think 'time' what is making me fail to\n> understand git merging. It depends on which branch I have changed last.\n\nNot really. Time is irrelevant, what matters is the common ancestor.\nPlease, run gitk and take a look at the history graph. I think it will make\nsome things obvious. They say one picture is worth a thousand words...\n\n\nDmitry\n"},{"id":"151533","messageId":"4C9CFCFF.8070102@nextest.com","threadId":"25184","inReplyTo":"20100921145922.GA14711@nibiru.local","subject":"Re: Re: Really beginner on Version Control","fromName":"Eric Raible","fromEmail":"raible@nextest.com","sentAt":"2010-09-24T19:33:19Z","receivedAt":"2010-09-24T19:33:19Z","isPatch":false,"sender":{"key":"raible@nextest.com","avatar":null},"body":"On 11:59 AM, Enrico Weigelt wrote:\n> * FernandoBasso wrote:\n> (use the -ff option on merge if it should show up in history\n> as merge instead of sequential additions - see \"fast forward\").\n\nDidn't you mean --no-ff?\n"},{"id":"151773","messageId":"20100924201839.GB29566@nibiru.local","threadId":"25184","inReplyTo":"4C9CFCFF.8070102@nextest.com","subject":"Re: Re: Really beginner on Version Control","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2010-09-24T20:18:39Z","receivedAt":"2010-09-24T20:18:39Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* Eric Raible wrote:\n> On 11:59 AM, Enrico Weigelt wrote:\n> > * FernandoBasso wrote:\n> > (use the -ff option on merge if it should show up in history\n> > as merge instead of sequential additions - see \"fast forward\").\n> \n> Didn't you mean --no-ff?\n\nYes, of course ;-o\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone: +49 36207 519931 email: weigelt@metux.de\n mobile: +49 151 27565287 icq: 210169427 skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"},{"id":"151551","messageId":"1285363550689-5568448.post@n2.nabble.com","threadId":"25184","inReplyTo":"4C9CFCFF.8070102@nextest.com","subject":"Re: Re: Really beginner on Version Control","fromName":"FernandoBasso","fromEmail":"fernandobasso.br@gmail.com","sentAt":"2010-09-24T21:25:50Z","receivedAt":"2010-09-24T21:25:50Z","isPatch":false,"sender":{"key":"fernandobasso.br@gmail.com","avatar":"https://gravatar.com/avatar/ec8132f27c0094bfa952b7260d6b490a2cc209c382ff1fb86cad0b3397daf902?d=mp&s=160"},"body":"\nWow! You guys really have the will to help. I know small talk is to be \navoided, but I wanted to let you know that I'm still following this thread\nwith great interest. You really helped me lot. I'm reading all the posts \neveryday trying to internalize the concepts. \n\nThank all you for your help. \n\n\n-- \nView this message in context: http://git.661346.n2.nabble.com/Really-beginner-on-Version-Control-tp5555023p5568448.html\nSent from the git mailing list archive at Nabble.com.\n"}]}