On 2017-01-16, at 10:25 AM, Philip Oakley <philipoak...@iee.org> wrote:
> Hi Michael, > > You are right about the historical perspective. > > However the `Worktrees` is a new feature. > > So yes, you can now have the different branches checked out in differemt > trees, and other goodies. Ok, on worktrees: Normally, if you have a branch checked out in a single work-tree, you know where you are, and you know what happens when you commit, or merge. Any time that there could be a conflict is only on merge, or on push. Push requires (effectively) that the histories agree, and merge detects conflicts and combines or asks you to combine. But that works if a single repository is only working with one set of files being modified. Lets say that two different worktrees have the same branchhead checked out. They make conflicting edits. The first commit works just fine. What happens on the second commit? Commit never had to worry about conflicts before; unless I'm missing something, now it does. === I found this example really "fascinating". From the manual: You are in the middle of a refactoring session and your boss comes in and demands that you fix something immediately. You might typically use git-stash(1) to store your changes away temporarily, however, your working tree is in such a state of disarray (with new, moved, and removed files, and other bits and pieces strewn around) that you don't want to risk disturbing any of it. Considering that this is exactly what git stash uses as it's example, plus that I've had exactly this problem -- a complete mess of a worktree that did not stash and then apply properly -- I found this highly informative. But as for why it did not apply correctly? Conflicting updates, I think, if I remember correctly. So yea, I'm concerned about how the commit works if a worktree made a change underneath you. > > Philip > > ----- Original Message ----- From: "Michael" <keybou...@gmail.com> > To: <git-users@googlegroups.com> > Sent: Monday, January 16, 2017 5:45 PM > Subject: [git-users] "Medium" git: Worktrees, submodules, subtrees > > > (I hope this isn't considered "advanced" git.) > > So I just recently found out about worktrees, that let you have two different > working trees from the same repository. (NB: Originally, I thought I had > learned that git only supported one work tree per repository, but had a > special "hardlink" to let two repositories share disk space on the same drive > -- did I misunderstand something?). > > Now, there's submodules, and subtrees. I'd like a bit of an explanation here. > > A submodule is at least at first simple enough: you have a subproject with > it's own history. But that's about all I understand about it. > > I can't tell if there's any way to convert a sub directory of a project into > a submodule, or visa-versa, or if it is a "lifetime" choice. > > And the man page on submodules talks about a "subtree merge strategy", and > I'm not sure I've even heard that before. > > So: Help? Please? Confused? > > --- > 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. > > -- > 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. --- 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.
