On 2018-09-27, at 5:06 PM, B. Lachele Foley <lach...@gmail.com> wrote:
> I knew that a git-pull is a fetch followed by a merge. But, I had not seen > arguments for always splitting the process up. For newbies, I always > considered 'git pull' to be simpler when getting them up to speed. In this > case, you are certainly correct that it is the safer strategy. I had also > looked for a pre-merge or post-fetch hook, but could find none. I will > present the article you mention to the group. Thank you. > >... > > Would it be dangerous to name the wrapper fetch (or pull)? Would git look > for 'fetch' or 'pull' in /usr/local/bin before looking elsewhere? Does it > follow the user's PATH? In this case, preventing a fetch is reasonable: > there is not much point bothering to download the data if you aren't ready to > use it. Fetch is always safe. The only thing that a fetch can do is put objects into your store that you might or might not use, and update information about where someone else has their branch pointers at. Your issue is with the merge. You actually want a pre-merge hook, or a special form of merge, for updating your database information. And actually, when I say it that way, you are looking at a special merge. Normal developers will merge two of their own branches a lot, and from what I understand, that's not going to affect anything. It's when I merge with your code that you want to track something. (Again, my understanding of your situation). --- 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 git-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
