{"thread":{"id":"31499","subject":"How to update a cloned git repository","startedAt":"2012-09-11T10:49:01Z","lastAt":"2012-09-12T08:52:37Z","messageCount":14,"participants":["Joachim Schmitz","Matthieu Moy","Erik Faye-Lund","Sitaram Chamarty","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"198763","messageId":"k2n4v2$88t$1@ger.gmane.org","threadId":"31499","inReplyTo":null,"subject":"How to update a cloned git repository","fromName":"Joachim Schmitz","fromEmail":"jojo@schmitz-digital.de","sentAt":"2012-09-11T10:49:01Z","receivedAt":"2012-09-11T10:49:01Z","isPatch":false,"sender":{"key":"jojo@schmitz-digital.de","avatar":"https://avatars.githubusercontent.com/u/1786669?v=4"},"body":"Hi folks\n\nProbably a beginner's question...\n\nIf I did a\n    git clone git://guthub.com/git/git.git\nand worked on some own branches of pu\n    git checkout pu;git checkout -p mybranch;hack;hack;...;git commit -a -s\nhow to update my repository once the the one on github changed?\nA plain\n    git pull\nor\n    git fetch;git merge\nkeeps failing on my with lots of conflicts, none of which relate to any of \nthe changes I did (and hence wouldn't know how to resolve)\n\n\nBye, Jojo \n"},{"id":"198764","messageId":"vpq7gs0es4f.fsf@bauges.imag.fr","threadId":"31499","inReplyTo":"k2n4v2$88t$1@ger.gmane.org","subject":"Re: How to update a cloned git repository","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-09-11T11:06:08Z","receivedAt":"2012-09-11T11:06:08Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"Joachim Schmitz\" <jojo@schmitz-digital.de> writes:\n\n> Hi folks\n>\n> Probably a beginner's question...\n>\n> If I did a\n>    git clone git://guthub.com/git/git.git\n> and worked on some own branches of pu\n>    git checkout pu;git checkout -p mybranch;\n\nI guess you meant \"git checkout -b mybranch\" (not -p).\n\n> hack;hack;...;git commit -a -s\n>\n> how to update my repository once the the one on github changed? A\n> plain git pull or git fetch;git merge keeps failing on my with lots of\n> conflicts, none of which relate to any of the changes I did (and hence\n> wouldn't know how to resolve)\n\nShort answer: don't work on pu. Work on master unless you have a good\nreason not to.\n\nLonger answer: the pu branch in git.git is often re-written, hence the\ncommit on which you started hacking once existed in git.git's pu, but it\nprobably no longer is.\n\nYou cloned this:\n\n--A---B---C <-- origin/pu\n\nHacked to this\n\n         origin/pu\n          |\n          v\n--A---B---C---D---E <-- mybranch\n\nand the next fetch resulted in something like this:\n\n    B'---C'---D'---F <-- origin/pu\n   /\n--A---B---C---D---E <-- mybranch\n\nwhile you could have expected that if origin/pu had just been\nfast-forwarded with a new commit F:\n\n            F <-- origin/pu\n           /\n--A---B---C---D---E <-- mybranch\n\nAs a result, \"git merge\" computes a common ancestor very far backward in\nhistory. Instead of merging only your changes with new pu content, it\nmerges the old history of pu (plus your changes) with the new history of\npu, and you get spurious conflicts.\n\nThe solution is to rebase your changes (and only yours). My advice is to\nrebase them on master, like this (replace 42 by the number of commits\nyou want to rebase in HEAD~42):\n\n  git rebase HEAD~42 --onto origin/master\n\nOnce you did this, you can start using \"git pull\" (or \"git pull\n--rebase\") as usual.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"198765","messageId":"006f01cd900e$fce59a60$f6b0cf20$@schmitz-digital.de","threadId":"31499","inReplyTo":"vpq7gs0es4f.fsf@bauges.imag.fr","subject":"RE: How to update a cloned git repository","fromName":"Joachim Schmitz","fromEmail":"jojo@schmitz-digital.de","sentAt":"2012-09-11T11:17:09Z","receivedAt":"2012-09-11T11:17:09Z","isPatch":false,"sender":{"key":"jojo@schmitz-digital.de","avatar":"https://avatars.githubusercontent.com/u/1786669?v=4"},"body":"> From: Matthieu Moy [mailto:Matthieu.Moy@grenoble-inp.fr]\n> Sent: Tuesday, September 11, 2012 1:06 PM\n> To: Joachim Schmitz\n> Cc: git@vger.kernel.org\n> Subject: Re: How to update a cloned git repository\n> \n> \"Joachim Schmitz\" <jojo@schmitz-digital.de> writes:\n> \n> > Hi folks\n> >\n> > Probably a beginner's question...\n> >\n> > If I did a\n> >    git clone git://guthub.com/git/git.git\n> > and worked on some own branches of pu\n> >    git checkout pu;git checkout -p mybranch;\n> \n> I guess you meant \"git checkout -b mybranch\" (not -p).\n\nYes, of course...\n\n> > hack;hack;...;git commit -a -s\n> >\n> > how to update my repository once the the one on github changed? A\n> > plain git pull or git fetch;git merge keeps failing on my with lots of\n> > conflicts, none of which relate to any of the changes I did (and hence\n> > wouldn't know how to resolve)\n> \n> Short answer: don't work on pu. Work on master unless you have a good\n> reason not to.\n\nThere are some changes in pu, that I need as the basis, namely my setitimer patch and my 2nd mkdir patch, which haven't yet made it\ninto the master branch (and in the setitimer case not out of pu)\n\n> Longer answer: the pu branch in git.git is often re-written, hence the\n> commit on which you started hacking once existed in git.git's pu, but it\n> probably no longer is.\n> \n> You cloned this:\n> \n> --A---B---C <-- origin/pu\n> \n> Hacked to this\n> \n>          origin/pu\n>           |\n>           v\n> --A---B---C---D---E <-- mybranch\n> \n> and the next fetch resulted in something like this:\n> \n>     B'---C'---D'---F <-- origin/pu\n>    /\n> --A---B---C---D---E <-- mybranch\n> \n> while you could have expected that if origin/pu had just been\n> fast-forwarded with a new commit F:\n> \n>             F <-- origin/pu\n>            /\n> --A---B---C---D---E <-- mybranch\n> \n> As a result, \"git merge\" computes a common ancestor very far backward in\n> history. Instead of merging only your changes with new pu content, it\n> merges the old history of pu (plus your changes) with the new history of\n> pu, and you get spurious conflicts.\n> \n> The solution is to rebase your changes (and only yours). My advice is to\n> rebase them on master, like this (replace 42 by the number of commits\n> you want to rebase in HEAD~42):\n> \n>   git rebase HEAD~42 --onto origin/master\n\nFor pu this would be similar?\n\n> Once you did this, you can start using \"git pull\" (or \"git pull\n> --rebase\") as usual.\n\n\nLike this?\ngit pull --rebase HEAD~42\n\nSo far I create patches, wiped out the entire repository, cloned, forked and applied the changes, pretty painful.\n"},{"id":"198767","messageId":"vpqy5kgdctm.fsf@bauges.imag.fr","threadId":"31499","inReplyTo":"006f01cd900e$fce59a60$f6b0cf20$@schmitz-digital.de","subject":"Re: How to update a cloned git repository","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-09-11T11:21:57Z","receivedAt":"2012-09-11T11:21:57Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"Joachim Schmitz\" <jojo@schmitz-digital.de> writes:\n\n>> From: Matthieu Moy [mailto:Matthieu.Moy@grenoble-inp.fr]\n>>\n>> Short answer: don't work on pu. Work on master unless you have a good\n>> reason not to.\n>\n> There are some changes in pu, that I need as the basis, namely my\n> setitimer patch and my 2nd mkdir patch, which haven't yet made it into\n> the master branch (and in the setitimer case not out of pu)\n\nThen, work on the tip of the topic branch you depend on instead of pu.\nThese are more stable, as they will be rewritten only if this particular\ntopic branch changes.\n\n>>   git rebase HEAD~42 --onto origin/master\n>\n> For pu this would be similar?\n\nYes. If you insist in working on top of pu, you can rebase --onto\norigin/pu.\n\n> Like this?\n> git pull --rebase HEAD~42\n\nThat would be \"git fetch\" and then \"git rebase\", as I don't think \"git\npull --rebase\" would allow you to specify the starting point for rebase.\n\n> So far I create patches, wiped out the entire repository, cloned,\n> forked and applied the changes, pretty painful.\n\nThis is conceptually similar to what \"git rebase\" does, but it does it\nin a slightly more efficient way ;-).\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"198772","messageId":"vpq4nn4d968.fsf@bauges.imag.fr","threadId":"31499","inReplyTo":"007001cd9016$8f980f80$aec82e80$@schmitz-digital.de","subject":"Re: How to update a cloned git repository","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-09-11T12:40:47Z","receivedAt":"2012-09-11T12:40:47Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"[ Re-adding git@vger in Cc, I guess it was meant to be so ]\n\n\"Joachim Schmitz\" <jojo@schmitz-digital.de> writes:\n\n>> Then, work on the tip of the topic branch you depend on instead of pu.\n>> These are more stable, as they will be rewritten only if this particular\n>> topic branch changes.\n>\n> These are not available from git hub. Or are they? How?\n\nI think they exist in some of the repos junio pushes to, but I don't\nremember how/which one.\n\nAnyway, you can easily get it from the commit that merges the branch\n(it's the-merge-commit^1).\n\n>> > Like this?\n>> > git pull --rebase HEAD~42\n>> \n>> That would be \"git fetch\" and then \"git rebase\", as I don't think \"git\n>> pull --rebase\" would allow you to specify the starting point for rebase.\n>\n> OK, I'll try that next time then. Like this?\n> \tgit fetch;git rebase HEAD~42 --onto origin/pu\n\nThat should work, yes.\n\nIn general, when you have a somehow complex workflow, I recommand\nfetch+(merge|rebase) over pull. It gives you more flexibility, and the\nopportunity to check what you fetched before starting the merge.\n\n>> > So far I create patches, wiped out the entire repository, cloned,\n>> > forked and applied the changes, pretty painful.\n>> \n>> This is conceptually similar to what \"git rebase\" does, but it does it\n>> in a slightly more efficient way ;-).\n>\n> Indeed ;-)\n>\n>\n>\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"198773","messageId":"007101cd901b$bea9d3d0$3bfd7b70$@schmitz-digital.de","threadId":"31499","inReplyTo":"vpq4nn4d968.fsf@bauges.imag.fr","subject":"RE: How to update a cloned git repository","fromName":"Joachim Schmitz","fromEmail":"jojo@schmitz-digital.de","sentAt":"2012-09-11T12:48:29Z","receivedAt":"2012-09-11T12:48:29Z","isPatch":false,"sender":{"key":"jojo@schmitz-digital.de","avatar":"https://avatars.githubusercontent.com/u/1786669?v=4"},"body":"> From: Matthieu Moy [mailto:Matthieu.Moy@grenoble-inp.fr]\n> Sent: Tuesday, September 11, 2012 2:41 PM\n> To: Joachim Schmitz\n> Cc: git\n> Subject: Re: How to update a cloned git repository\n> \n> [ Re-adding git@vger in Cc, I guess it was meant to be so ]\n\n\nOops, yes it was meant to.\n\n> \"Joachim Schmitz\" <jojo@schmitz-digital.de> writes:\n> \n> >> Then, work on the tip of the topic branch you depend on instead of pu.\n> >> These are more stable, as they will be rewritten only if this particular\n> >> topic branch changes.\n> >\n> > These are not available from git hub. Or are they? How?\n> \n> I think they exist in some of the repos junio pushes to, but I don't\n> remember how/which one.\n> \n> Anyway, you can easily get it from the commit that merges the branch\n> (it's the-merge-commit^1).\n> \n> >> > Like this?\n> >> > git pull --rebase HEAD~42\n> >>\n> >> That would be \"git fetch\" and then \"git rebase\", as I don't think \"git\n> >> pull --rebase\" would allow you to specify the starting point for rebase.\n> >\n> > OK, I'll try that next time then. Like this?\n> > \tgit fetch;git rebase HEAD~42 --onto origin/pu\n> \n> That should work, yes.\n> \n> In general, when you have a somehow complex workflow, I recommand\n> fetch+(merge|rebase) over pull. It gives you more flexibility, and the\n> opportunity to check what you fetched before starting the merge.\n\nOK, thanks.\n\nI'm sure I'll have more questions later though ;-)\n"},{"id":"198774","messageId":"CABPQNSYwHaE35UiZC8qqBMyjmY37VuTK_hqFyRcbhJKnhYzz2Q@mail.gmail.com","threadId":"31499","inReplyTo":"vpq4nn4d968.fsf@bauges.imag.fr","subject":"Re: How to update a cloned git repository","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@gmail.com","sentAt":"2012-09-11T13:07:54Z","receivedAt":"2012-09-11T13:07:54Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Tue, Sep 11, 2012 at 2:40 PM, Matthieu Moy\n<Matthieu.Moy@grenoble-inp.fr> wrote:\n> [ Re-adding git@vger in Cc, I guess it was meant to be so ]\n>\n> \"Joachim Schmitz\" <jojo@schmitz-digital.de> writes:\n>\n>>> Then, work on the tip of the topic branch you depend on instead of pu.\n>>> These are more stable, as they will be rewritten only if this particular\n>>> topic branch changes.\n>>\n>> These are not available from git hub. Or are they? How?\n>\n> I think they exist in some of the repos junio pushes to, but I don't\n> remember how/which one.\n>\n\nYou can usually find them here: https://github.com/gitster/git/branches\n\nAnd Joachim's branch in particular:\nhttps://github.com/gitster/git/tree/js/compat-itimer\n"},{"id":"198778","messageId":"CAMK1S_jXA0WfC-de=mD7-+2oJiep_A2rKSZdSsqn7CcNJPsq5A@mail.gmail.com","threadId":"31499","inReplyTo":"006f01cd900e$fce59a60$f6b0cf20$@schmitz-digital.de","subject":"Re: How to update a cloned git repository","fromName":"Sitaram Chamarty","fromEmail":"sitaramc@gmail.com","sentAt":"2012-09-11T14:09:21Z","receivedAt":"2012-09-11T14:09:21Z","isPatch":false,"sender":{"key":"sitaramc@gmail.com","avatar":"https://avatars.githubusercontent.com/u/43316?v=4"},"body":"On Tue, Sep 11, 2012 at 4:47 PM, Joachim Schmitz\n<jojo@schmitz-digital.de> wrote:\n\n> Like this?\n> git pull --rebase HEAD~42\n>\n> So far I create patches, wiped out the entire repository, cloned, forked and applied the changes, pretty painful.\n\nI think a 'git pull --rebase' should usually work even for 'pu'.\n\nBut sometimes pu may have changes that take away the basis for your\npatch (i.e, not just a restructure) then you'd get conflicts.\n"},{"id":"198789","messageId":"7v627kk0re.fsf@alter.siamese.dyndns.org","threadId":"31499","inReplyTo":"006f01cd900e$fce59a60$f6b0cf20$@schmitz-digital.de","subject":"Re: How to update a cloned git repository","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-11T16:00:37Z","receivedAt":"2012-09-11T16:00:37Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Joachim Schmitz\" <jojo@schmitz-digital.de> writes:\n\n>> From: Matthieu Moy [mailto:Matthieu.Moy@grenoble-inp.fr]\n>> ..\n>> Short answer: don't work on pu. Work on master unless you have a good\n>> reason not to.\n>\n> There are some changes in pu, that I need as the basis, namely my\n> setitimer patch and my 2nd mkdir patch, which haven't yet made it\n> into the master branch (and in the setitimer case not out of pu)\n\nAnd that is not a good reason, either.\n\nIn general, it is a good habit to get into to base your changes on\nthe oldest point release they may want to be used with.  For\nexample, if you really wanted to, you could make sure your Tandem\nchanges can be back-merged all the way down to v1.7.6 by forking\nyour own branch from there, queuing your changes like mkdir, itimer\non top.  And you develop and test your changes on that branch,\nwithout pulling from or rebasing it on top of my tree where random\nother things happen that won't affect you an iota.  A recent change\nto add the new \"--set-upstream-to\" option to \"branch\" command does\nnot have any platform-specific bits, and for the purpose of the\n\"port to Tandem\" topic, keeping up to date with such a change in my\ntree is pointless, for example.  To make sure that the result is\nstill usable with recent releases, you can create a throw-away merge\nbetween your work (that is forked from a stable base) and my tip\nevery once in a while, test the result, and discard the throw-away\nmerge when you are done.  Any breakage in your series you find in\nsuch an integration test is to be fixed on your branch, not on top\nof such a throw-away merge.\n\nIt might be the case that nobody cares if the resulting patches will\nnot apply to and usable with 'master' or older integration branches,\nso in the particular case of \"Tandem\", choosing a stable fork point\nthat is older than 'master' may not make much sense, though.\n"},{"id":"198790","messageId":"7v1ui8k0in.fsf@alter.siamese.dyndns.org","threadId":"31499","inReplyTo":"vpq4nn4d968.fsf@bauges.imag.fr","subject":"Re: How to update a cloned git repository","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2012-09-11T16:05:52Z","receivedAt":"2012-09-11T16:05:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n\n> [ Re-adding git@vger in Cc, I guess it was meant to be so ]\n>\n> \"Joachim Schmitz\" <jojo@schmitz-digital.de> writes:\n>\n>>> Then, work on the tip of the topic branch you depend on instead of pu.\n>>> These are more stable, as they will be rewritten only if this particular\n>>> topic branch changes.\n>>\n>> These are not available from git hub. Or are they? How?\n>\n> I think they exist in some of the repos junio pushes to, but I don't\n> remember how/which one.\n>\n> Anyway, you can easily get it from the commit that merges the branch\n> (it's the-merge-commit^1).\n\nI think it is the-merge-commit^2; contrib/git-resurrect.sh might be\nof interest, too.\n"},{"id":"198792","messageId":"vpqbohc7cp6.fsf@bauges.imag.fr","threadId":"31499","inReplyTo":"7v1ui8k0in.fsf@alter.siamese.dyndns.org","subject":"Re: How to update a cloned git repository","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-09-11T16:21:09Z","receivedAt":"2012-09-11T16:21:09Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"Junio C Hamano <gitster@pobox.com> writes:\n\n> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n>\n>> Anyway, you can easily get it from the commit that merges the branch\n>> (it's the-merge-commit^1).\n>\n> I think it is the-merge-commit^2;\n\nRight. I forgot that Git counted parents from 1, not 0.\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"},{"id":"198795","messageId":"007301cd903c$e09c0050$a1d400f0$@schmitz-digital.de","threadId":"31499","inReplyTo":"7v627kk0re.fsf@alter.siamese.dyndns.org","subject":"RE: How to update a cloned git repository","fromName":"Joachim Schmitz","fromEmail":"jojo@schmitz-digital.de","sentAt":"2012-09-11T16:45:38Z","receivedAt":"2012-09-11T16:45:38Z","isPatch":false,"sender":{"key":"jojo@schmitz-digital.de","avatar":"https://avatars.githubusercontent.com/u/1786669?v=4"},"body":"\n\n> -----Original Message-----\n> From: Junio C Hamano [mailto:gitster@pobox.com]\n> Sent: Tuesday, September 11, 2012 6:01 PM\n> To: Joachim Schmitz\n> Cc: 'Matthieu Moy'; git@vger.kernel.org\n> Subject: Re: How to update a cloned git repository\n> \n> \"Joachim Schmitz\" <jojo@schmitz-digital.de> writes:\n> \n> >> From: Matthieu Moy [mailto:Matthieu.Moy@grenoble-inp.fr]\n> >> ..\n> >> Short answer: don't work on pu. Work on master unless you have a good\n> >> reason not to.\n> >\n> > There are some changes in pu, that I need as the basis, namely my\n> > setitimer patch and my 2nd mkdir patch, which haven't yet made it\n> > into the master branch (and in the setitimer case not out of pu)\n> \n> And that is not a good reason, either.\n> \n> In general, it is a good habit to get into to base your changes on\n> the oldest point release they may want to be used with.  For\n> example, if you really wanted to, you could make sure your Tandem\n> changes can be back-merged all the way down to v1.7.6 by forking\n\nThe first version I ever made available for NonStop is 1.5.12, so no reason for me to go back.\nOn the other hand I see nothing in my patches that would not easily backport to much older releases, as the code I touched is either\nnewly created by me (e.g. compat/mkdir.c) or pretty old (compar/win32/poll.c).\n\n> your own branch from there, queuing your changes like mkdir, itimer\n> on top.  And you develop and test your changes on that branch,\n> without pulling from or rebasing it on top of my tree where random\n> other things happen that won't affect you an iota.  A recent change\n> to add the new \"--set-upstream-to\" option to \"branch\" command does\n> not have any platform-specific bits, and for the purpose of the\n> \"port to Tandem\" topic, keeping up to date with such a change in my\n> tree is pointless, for example.  To make sure that the result is\n> still usable with recent releases, you can create a throw-away merge\n> between your work (that is forked from a stable base) and my tip\n> every once in a while, test the result, and discard the throw-away\n> merge when you are done.  Any breakage in your series you find in\n> such an integration test is to be fixed on your branch, not on top\n> of such a throw-away merge.\n> \n> It might be the case that nobody cares if the resulting patches will\n> not apply to and usable with 'master' or older integration branches,\n> so in the particular case of \"Tandem\", choosing a stable fork point\n> that is older than 'master' may not make much sense, though.\n\nMy goal here is that the next stable release has as much of my patches integrated as possible, so I have much less work when\nporting, ideals just hitting 'make'...\n\nSo far my poll patches are still needed. And then, but not earlier, my plain NonStop specific ones (like a section in Makefile and\nsome adjustments in git-compat-utils.h) , these don't make much sense earlier.\n\nBye, Jojo\n"},{"id":"198796","messageId":"007401cd903c$f425fc20$dc71f460$@schmitz-digital.de","threadId":"31499","inReplyTo":"7v1ui8k0in.fsf@alter.siamese.dyndns.org","subject":"RE: How to update a cloned git repository","fromName":"Joachim Schmitz","fromEmail":"jojo@schmitz-digital.de","sentAt":"2012-09-11T16:46:11Z","receivedAt":"2012-09-11T16:46:11Z","isPatch":false,"sender":{"key":"jojo@schmitz-digital.de","avatar":"https://avatars.githubusercontent.com/u/1786669?v=4"},"body":"> From: Junio C Hamano [mailto:gitster@pobox.com]\n> Sent: Tuesday, September 11, 2012 6:06 PM\n> To: Matthieu Moy\n> Cc: Joachim Schmitz; git\n> Subject: Re: How to update a cloned git repository\n> \n> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:\n> \n> > [ Re-adding git@vger in Cc, I guess it was meant to be so ]\n> >\n> > \"Joachim Schmitz\" <jojo@schmitz-digital.de> writes:\n> >\n> >>> Then, work on the tip of the topic branch you depend on instead of pu.\n> >>> These are more stable, as they will be rewritten only if this particular\n> >>> topic branch changes.\n> >>\n> >> These are not available from git hub. Or are they? How?\n> >\n> > I think they exist in some of the repos junio pushes to, but I don't\n> > remember how/which one.\n> >\n> > Anyway, you can easily get it from the commit that merges the branch\n> > (it's the-merge-commit^1).\n> \n> I think it is the-merge-commit^2; contrib/git-resurrect.sh might be\n> of interest, too.\n\nSorry you lost me, this is greek to me...\n"},{"id":"198816","messageId":"vpqtxv34o8a.fsf@bauges.imag.fr","threadId":"31499","inReplyTo":"007401cd903c$f425fc20$dc71f460$@schmitz-digital.de","subject":"Re: How to update a cloned git repository","fromName":"Matthieu Moy","fromEmail":"matthieu.moy@grenoble-inp.fr","sentAt":"2012-09-12T08:52:37Z","receivedAt":"2012-09-12T08:52:37Z","isPatch":false,"sender":{"key":"matthieu.moy@grenoble-inp.fr","avatar":"https://gravatar.com/avatar/72c8a2705971a25dfaff23cece15130d405685845d911aedd5667ace277f3fc5?d=mp&s=160"},"body":"\"Joachim Schmitz\" <jojo@schmitz-digital.de> writes:\n\n>> I think it is the-merge-commit^2; contrib/git-resurrect.sh might be\n>> of interest, too.\n>\n> Sorry you lost me, this is greek to me...\n\nA commit is an object that contain pointers to its parents. The root\ncommit has no parent. For ordinary commits, there is one parent which is\nthe commit on top of which it was created. For merge commits, there are\nN commits, the first is the one on top of which the merge was created,\nand the N-1 next ones are the commits being merged.\n\ncommit^ => first parent of commit\ncommit^1 => same\ncommit^2 => second parent, i.e. the one merged in commit.\n\nSee in git.git:\n\n$ git show cb10ae9433126ef <---------------------------- one commit to study\ncommit cb10ae9433126efbc4dcc46779d7ef2fe6b1f597\nMerge: 13b608a 9aeaab6   <------------------------------- list of parents\nAuthor: Junio C Hamano <gitster@pobox.com>\nDate:   Tue Sep 11 15:57:04 2012 -0700\n\n    Merge branch 'jc/maint-blame-no-such-path' into pu\n    \n    * jc/maint-blame-no-such-path:\n      blame: allow \"blame file\" in the middle of a conflicted merge\n\n$ git show cb10ae9433126ef^1 <-------------------- \"previous commit\" in origin/pu\ncommit 13b608a063ce861929322e6bb3862b5364f3fbcf\nMerge: fa17a26 bdee397\nAuthor: Junio C Hamano <gitster@pobox.com>\nDate:   Tue Sep 11 11:50:44 2012 -0700\n\n    Merge branch 'dg/run-command-child-cleanup' into pu\n    \n    * dg/run-command-child-cleanup:\n      run-command.c: fix broken list iteration in clear_child_for_cleanup\n\n$ git show cb10ae9433126ef^2 <----------------- commit being merged by cb10ae9433126ef\ncommit 9aeaab6811dce596b4f6141d76f5300359bfd009\nAuthor: Junio C Hamano <gitster@pobox.com>\nDate:   Tue Sep 11 14:30:03 2012 -0700\n\n    blame: allow \"blame file\" in the middle of a conflicted merge\n[...]\n\n-- \nMatthieu Moy\nhttp://www-verimag.imag.fr/~moy/\n"}]}