login
Search
linux@horizon.com writes:This is a very important point to remember not for users but for us in git community. Thanks for writing it down. Dodecapus would find a few, no hits on doedecapus ;-). It is not "somewhere" but "in the current branch", so in a sense it is a bit stricter than that. While on 'master' "branch -d topic" would not remove the topic branch head if it is not fully merged to my 'master' so that is a reasonable safety measure, but when I am on 'next' it will happily remove it. It is recoverable because it is reachable from 'next', though. One bug in my previous response is that I said we do this only when the command was invoked with shorthand remote name. Not so. We do this only when we use tracking branches. The reason is because 'git pull $url $branch' (typical Linus's use) and 'git pull' (defaulting to 'origin' and using the tracking branch mapping stored in .git/remotes/origin prepared by git-clone) are sign of very different workflows. The former tends to be a one-shot event while the latter is most often synchronizing with either an upstream or a common distribution point (i.e. shared central repostiory). When you are fetching from somebody in a one-shot manner, most likely as a part of 'pull', you do not want to get the tag the other person has made to mark his private work in progress. But in the latter case, the other end is where everybody who works in the same area fetches from, and sharing the tags found there among the developers by default is desirable, and more importantly there is no risk of accidentally getting private tags, since the other end is a public distribution point and by definition should not have private tags that would clutter your refs/tags hierarchy. Here you _might_ want to mention an alternative workflow that uses rebase, which seems to be the way Wine folks run their project. Talking about all the different possibilities tends to cloud things and may not add value to the document, so I am just mentioning it as a possibility but I do not know if talking about rebase is useful in the context of this document. This is not true; "git pull . topicA topicB topicC" works as expected. But we probably would not want to even talk about Octopus in a document like this. It is a curosity, and sometimes tends to make histories even less cluttered, but otherwise it does not add much value. I haven't tried for a long time, but I do not think non-HEAD destination even works at all. It might be better not to even mention git-merge at this point of the document. You might also want to mention that recursive first 3-way merges the renames. If O->A renames a path while O->B keeps it, the resulting stages are written under the new name. Another tool to help the user decide how the mess should be sorted out is "git log --merge -- $path". It gives the logs of commits that touched the path while the two branches were forked. s/van/can/ Ancestry graph before and after this procedure would help the reader a lot here. They were conflicts during the virtual ancestor computation by recursive (the merge between 'a' and 'b' commits in your earlier example). When a virtual ancestor is created, it can textually have conflicted merge, but that is recorded along with conflict markers without manual resolving for obvious reasons. If two branches that use the virtual ancestor modifies the conflicted region the same way (because they needed to resolve that conflict in their branch), the final 3-way merge that uses the virtual ancestor as the merge-base will replace that conflicted region with their changes. This "even conflict markers can be eliminated by a merge resolution" behaviour is what inspired git-rerere, by the way. If you are using this particular commit as an example, you might also want to tell your readers about: git show -M 3f69d405 (-M is there to make the output more readable, because this merge involved a few renames). - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| David Miller | [GIT]: Networking |
| Greg KH | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Geert Uytterhoeven | Re: linux-next: Tree for August 14 |
| Bart Van Assche | Integration of SCST in the mainstream Linux kernel |
git: | |
| Arjan van de Ven | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Woodhouse | Re: [bug?] tg3: Failed to load firmware "tigon/tg3_tso.bin" |
