On 2018-09-28, at 12:03 PM, B. Lachele Foley <[email protected]> wrote:
> We talked about this at group meeting this morning. We had just been > discussing a realization similar to Michael Gersten's observation about > needing a "special merge" when we saw his post come in. Moments before that > we had decided that we probably do want it to be a pre-fetch hook. That > is... we want to avoid needing two different versions of merge (or fetch or > pull). I will explain more. > > I might be misunderstanding some of the 'magic' associated with fetch and > merge. If one merges between branches in a single repo, would that be > subject to a pre-merge hook? As MG observed, we don't want to interfere with > what the devs do in their local repos. We only want to ensure that they have > dumped the data before merging from external sources. So, a pre-fetch makes > a little more sense unless the pre-merge hook can be set to only act on > merges from external repos (or something similar). That is, with pre-fetch, > you know that you are setting the hook to affect what might happen when you > take data in from an external source. If you had a pre-merge hook, then it would run even on local merges between branches. The "magic" of a fetch is simple: copies of objects in other repos wind up in your repo unaltered, and remote branch pointers are updated. In particular, there is no need for a fetch to be followed by a merge. You can do a fetch any time you want to know "What is Alice doing now?". And, a typical dev strategy while working on a branch from a common master is to do a pull on master (fetch of master, merge your master with the current master), followed by either a rebase or a "test merge master into my code". (*) > We only want to ensure that they have dumped the data before merging from > external sources. So, you want to say "here is special code to run before doing a special merge". (**) > > We definitely want to avoid having different versions of > merge/fetch/pull/etc. because we don't want the devs to have to remember to > do the special thing. Besides, we already have a special 'pull'. Umm ... why? (*): One dev strategy is a common master. Another is "everyone has their own master". The way you use rebase differs in each case. I do not understand rebase well enough to describe it's usage difference in the two cases. I do not like rebase because of the loss of history, and I'd love to see "rebase with history" as a native supported mode. But the only way to get that now is with imerge. And, it causes a messy history because git does not have a way to mark some parents as "uninteresting technical parents". (**): "Test merge of master into my code" can be as simple as: % <save your current branch> % git checkout master % git fetch upstream <or whatever name is associated with the master master> % git merge upstream/master <or whatever name ...> % git checkout <your current branch> % git checkout -b testmerge % git merge master Now, if you need to update files to make sure that something is maintained, where do you want it done? Note that there are *two* merges, on two different branches here. Presumably the merge on master should be a fast forward, with no changes needed, so you'll want whatever fancy stuff you are doing to happen *on that test branch merge*. If it fails? You go back to the previous "your current branch", where the file changes *have not yet occurred*. Based on this, you probably do not want your magic done on the fetch, because your code may depend on things set one way before the fetch, and then it's altered after the fetch. Now, it's possible that I am entirely misunderstanding what you are trying to do here. It sounds like you are saying "Lets update some file with local information that will be shared via git after I have successfully merged my new changes into the main system". If so, that is something that is recorded *when you have a successful merge*. Which, now that I think about it, really means a post-merge check, not a pre-fetch check. Because remember, if you do a fetch, you're seeing what the other person has, including the other person's state of that shared updated data. Any changes to that shared updated data happens on your merge of their data. --- Entertaining minecraft videos http://YouTube.com/keybounce -- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
