4 ms·

I agree with Linus that creating a solid merge base is far more important than clever merging. But I think there is still room for improving on Git in this res

I agree with Linus that creating a solid merge base is far more important than clever merging. But I think there is still room for improving on Git in this respect. A lot of what I'm about to say is inspired by this video from the Camp guys: http://projects.haskell.org/camp/unique http://projects.haskell.org/camp/unique Git forces you to treat your history as a single linear sequence of commits. This is an unnecessary restriction if some of the changes in that sequence are totally independent of each other. For example, if two changes touch two completely different files and are unrelated, why should you be forced to sequence them in one order? Here is a practical situation illustrating this limitation. Once in a while I'll want to patch a coworker's in-progress change into my working directory where I also have changes. Perhaps I want to build a binary with several experimental in-progress changes in it. Suppose my coworker's changes are totally independent of mine (say they touch completely different files). I can do this in Git by applying his patch to my working directory (or doing a "git merge" with his branch). But now suppose I'm done with the experiment and want to back out my coworker's change, so my working directory is left with only my change. If I haven't made any more tweaks to my change in the meantime then I'm ok, I can just "git reset --hard HEAD^" to discard my coworker's change. But what if I made further changes to my change in the meantime? There's no easy way with Git to manipulate the two changes independently within the same branch, even though there are no actual dependencies between them. Sure you could create a separate branch for the merged thing. Every time you want to change your part you switch back to your branch, make the change, then switch back to the merged branch and merge again. But who wants to be that disciplined? Who should have to be that disciplined when the computer could do the work of knowing that the two lines of change are independent of each other? Git's ability to create stable and verifiable SHA1's is important, and I think that any future SCM will need to have this capability. But I don't think this implies that you have to treat the history in a strictly linear way. You could create SHA1 checkpoints when a particular person wants to publish and/or sign a tree and its contents, but still allow the individual commits to be treated in a more flexible way. The SHA1 checkpoints could be like barriers; each change is either part of the checkpoint or not, and the checkpoints could know their parent checkpoint(s) so that there is still a verifiable history available for auditing. I hope an approach like this could make large projects like Linux more intuitive to follow. I always found it unfortunate that the graph of commits for any project with lots of merge activity is totally indecipherable. For example, here is a screenshot of Git's own Git repository: http://i.imgur.com/RyQm3.png http://i.imgur.com/RyQm3.png If independent changes could be viewed independently, and if every merge didn't have to be an explicit commit, perhaps this could be easier to follow. There are definitely lots of unanswered questions here and I don't claim to have all the answers. My point is just that I don't think Git is necessarily the last word in distributed version control.

natep 15y ago
I don't see why you think git's approach to history is flawed. If changes to separate areas are kept separate, how can anyone coordinate on a single set of changes? What if 1 patch does't affect an area, but depends on it staying the same? Sorry, I can't imagine why you would want a commit to contain anything other than the state of the entire repo. That doesn't mean there aren't easy solutions to your problems, though. For your first situation (test-merging in coworker commits), why are you doing it on your own dev branch? Say you're working on branch 'mine', just `git checkout -b 'mine-exp'` before merging things. Then you can continue to develop on 'mine' and/or mess with 'mine-exp'. Can't manipulate separate changes within the same branch? Create more branches! Want to look at the history of only certain paths? Just specify them at the end of your `git log` command (you can get something similar to gitk's output with `git log --oneline --graph --decorate`). If that's not enough for you, there's a whole section on 'History Simplification' in the git-log manpage. It's possible in gitk as well, under View>(New/Edit) view. The penultimate text area lets you narrow the history to commits that affect the specified files and directories. Could all of this be documented better? Maybe, but in the first case, creating branches is the git philosophy (they're only 40 bytes each). And limiting the log output is something that svn had, so I figured git did as well.
- haberman 15y ago
  > I don't see why you think git's approach to history is flawed. I didn't use the word "flawed" nor do I believe it is flawed. If anything I would call it "incomplete," since what I am describing is essentially a superset of Git's existing model. I'm dreaming about whether the future could be better than what we have today. > Say you're working on branch 'mine', just `git checkout -b 'mine-exp'` before merging things. I explored this option in my comment. The problem is that it requires discipline that is not fundamentally necessary. It imposes branching/merging busywork that I believe could be avoided. Suppose I'm right and some of this branching/merging busywork could be avoided. Wouldn't we be in a better place than we are today? Isn't it worth exploring this possibility?
  - natep 15y ago
    > If anything I would call it "incomplete," Well, if you're asking the user to keep track of anything more than the SHA1 of a commit and all of the commands available to you, then that's asking a lot (because of all the commands that git has) > it requires discipline that is not fundamentally necessary If you don't proactively make branches, then you're like me. In that case, I make liberal use of git add -p, git stash, and git reset --hard (but only when everything is stashed or committed, to move branch pointers around). And then I always make a mental note, that next time I'm going to make risky changes, make the branch first (I don't get to use git often enough for my habits to change, though). But in my case, it's usually because I start working on one thing, and then mid-course, decide to work on something else. Because I came from svn, I forget how cheap commits are as well, and that it's possible to commit non-working code. It's definitely more desirable than creating commits that do too much. So, I disagree with both parts of your claim. It doesn't require significantly more discipline, provided you don't make the mistake of committing too much (e.g. always be sure to start working on an idea from a clean checkout). And the discipline required for the smoothest workflow _is_ fundamentally necessary regardless of what VCS you use, because no VCS can know what idea you're working on unless you tell it. If you're often committing to the wrong place, I suggest adding the current branch name to your shell prompt, or getting familiar with `git cherry-pick`. If you can't keep track of what's been merged with what, gitk and various git-log options are your friend. Do you at least agree that git has the history pruning options you were asking for? > Suppose I'm right and some of this branching/merging busywork could be avoided. Wouldn't we be in a better place than we are today? Isn't it worth exploring this possibility? First of all, my proposed solutions can be followed _now_, regardless of the pursuit of yours. Second, what you're describing sounds to me exactly like submodules, which require their own discipline, and have their own set of problems (hence the recent inclusion of the git-subtrees project). And if you think that maybe git can automatically decide what files go in each submodule, then good luck, because I think you're at a point where nothing can convince you otherwise. Edit: I take back all I said about your idea being unconditionally too complicated. It seems like it's already being done by the darcs/camp projects. I'll have to check those out eventually.

natep 15y ago

I don't see why you think git's approach to history is flawed. If changes to separate areas are kept separate, how can anyone coordinate on a single set of changes? What if 1 patch does't affect an area, but depends on it staying the same? Sorry, I can't imagine why you would want a commit to contain anything other than the state of the entire repo. That doesn't mean there aren't easy solutions to your problems, though. For your first situation (test-merging in coworker commits), why are you doing it on your own dev branch? Say you're working on branch 'mine', just `git checkout -b 'mine-exp'` before merging things. Then you can continue to develop on 'mine' and/or mess with 'mine-exp'. Can't manipulate separate changes within the same branch? Create more branches! Want to look at the history of only certain paths? Just specify them at the end of your `git log` command (you can get something similar to gitk's output with `git log --oneline --graph --decorate`). If that's not enough for you, there's a whole section on 'History Simplification' in the git-log manpage. It's possible in gitk as well, under View>(New/Edit) view. The penultimate text area lets you narrow the history to commits that affect the specified files and directories. Could all of this be documented better? Maybe, but in the first case, creating branches is the git philosophy (they're only 40 bytes each). And limiting the log output is something that svn had, so I figured git did as well.

haberman 15y ago
> I don't see why you think git's approach to history is flawed. I didn't use the word "flawed" nor do I believe it is flawed. If anything I would call it "incomplete," since what I am describing is essentially a superset of Git's existing model. I'm dreaming about whether the future could be better than what we have today. > Say you're working on branch 'mine', just `git checkout -b 'mine-exp'` before merging things. I explored this option in my comment. The problem is that it requires discipline that is not fundamentally necessary. It imposes branching/merging busywork that I believe could be avoided. Suppose I'm right and some of this branching/merging busywork could be avoided. Wouldn't we be in a better place than we are today? Isn't it worth exploring this possibility?
- natep 15y ago
  > If anything I would call it "incomplete," Well, if you're asking the user to keep track of anything more than the SHA1 of a commit and all of the commands available to you, then that's asking a lot (because of all the commands that git has) > it requires discipline that is not fundamentally necessary If you don't proactively make branches, then you're like me. In that case, I make liberal use of git add -p, git stash, and git reset --hard (but only when everything is stashed or committed, to move branch pointers around). And then I always make a mental note, that next time I'm going to make risky changes, make the branch first (I don't get to use git often enough for my habits to change, though). But in my case, it's usually because I start working on one thing, and then mid-course, decide to work on something else. Because I came from svn, I forget how cheap commits are as well, and that it's possible to commit non-working code. It's definitely more desirable than creating commits that do too much. So, I disagree with both parts of your claim. It doesn't require significantly more discipline, provided you don't make the mistake of committing too much (e.g. always be sure to start working on an idea from a clean checkout). And the discipline required for the smoothest workflow _is_ fundamentally necessary regardless of what VCS you use, because no VCS can know what idea you're working on unless you tell it. If you're often committing to the wrong place, I suggest adding the current branch name to your shell prompt, or getting familiar with `git cherry-pick`. If you can't keep track of what's been merged with what, gitk and various git-log options are your friend. Do you at least agree that git has the history pruning options you were asking for? > Suppose I'm right and some of this branching/merging busywork could be avoided. Wouldn't we be in a better place than we are today? Isn't it worth exploring this possibility? First of all, my proposed solutions can be followed _now_, regardless of the pursuit of yours. Second, what you're describing sounds to me exactly like submodules, which require their own discipline, and have their own set of problems (hence the recent inclusion of the git-subtrees project). And if you think that maybe git can automatically decide what files go in each submodule, then good luck, because I think you're at a point where nothing can convince you otherwise. Edit: I take back all I said about your idea being unconditionally too complicated. It seems like it's already being done by the darcs/camp projects. I'll have to check those out eventually.