On Wed, Nov 24, 2021 at 10:24:31PM +0100, Lars Ruoff wrote: [...]
> However, as you seem to confirm, this doesn't avoid the burden of having the > entire repo on the local machine. (I'm well aware of the DVCS nature of Git) > That being said, having it once would be acceptable, it's having it multiple > times that I would like to avoid. It's required to do just once per developer box. After that, fetching data from the central repository will transfer just the minimum amount of objects necessary to have the two communicating repositories the same history (and if you fetch, say, the missing history of just a single branch, only the objects missing in that branch in the local repository will be transferred). Still, if the initial cloning poses a problem you can employ a lesser-known fact that Git is fine from cloning (and fetching from) other local repositories, so it's quite possible to clone the master repo to a pen drive (or several) and then have each developer clone the repo from it. The resulting clone will require a little bit of tweaking afterwards - changing the URI of the "origin" repository, but that's all. [...] > and merges can be done on a single changeset level. That is interesting! (For someone not familiar with TFS, like me.) In Git, when you merge B into A (you can merge more than one "source" branch at once, but this is relatively rare a case), this operation logically brings into A the change set (which can be a subgraph, not necessarily a single straight string of commits) since the point of the previous merge of B into A (which is called the "merge base of A and B"). IoW, you cannot manually limit such a change set via some options to the `git merge` command. You _can_ of course, just remove a set of changes from the state which the merge operation generated, but this is almost always not a good idea as it breaks the semantics of the merge operation: the resulting history shows not quite what have happened. > We fix a bug on say branch A, then "merge" the changeset (and only that > changeset) to branch B. This does indeed create "diagonal" ties between > branches, but doesn't end either branch. In Git, merging does not end a branch either. Actually, branches in Git are very light-weight: a commit does not in any way "remembers" what branch it is "on" - because in Git, a branch is just a pointer at a commit, and any commit reachable from that one can be said to "be on" that branch. Oh, and by the way, while we're at it, I'd recommend to read [1] - it could make an interesting read. 1. https://hackernoon.com/how-the-creators-of-git-do-branches-e6fcc57270fb -- 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. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/20211125142855.qlwmyc5fh4l64b25%40carbon.
