Aaron Griffin wrote:
On Mon, Feb 23, 2009 at 4:42 PM, Bryan Ischo <bji-keyword-pacman.3644cb@www.ischo.com> wrote:
Aaron Griffin wrote:
I dunno, I don't see this as a problem because it's just not the way my workflow works. I make heavy use of git (well, git svn) at work, on huge amounts of code, and never run into these issues.
I can certainly believe that git is very appropriate for certain workflows, and the more closely the way you want to work matches the git way, the happier you are. I can say that where I worked most recently, years and years of accumulated experience led to certain workflows for branching and merging that I don't think would have been easily adapted to the git way. But I could be wrong, in fact I'd love to be wrong, because it's obvious that lots of open source projects are adopting git and I expect I'll have to use git more and more in the future whether I like it or not. So I really hope that my issues with git are just misunderstandings and not something that will make my life very difficult when using it in the future.
I just tried the rename case and it worked perfectly fine.
http://code.phraktured.net/cgit.cgi/foobar/ branch-a was made off the first commit, all changes were done and committed, then I switched back to master, renamed a file I changed _twice_ in branch-a, switched back to branch-a and did a "git rebase master". You can see the results there. It even lists the new file name in the diffs
Attached are a few scripts to demonstrate what I'm talking about.
First is losthistory.sh, that shows that after you rename a file on a branch and then merge that back to the master, you can't easily get the history of the file before the rename. That's a bummer and can make tracking the true history of a file difficult.
Next is conflict.sh, that demonstrates that git gives conflicts if two contiguous lines of a file are modified on two separate branches. Introducing a newline between the lines allows git to merge properly. This has nothing to do with file renames, it's just something that bit me while I was composing some of these other scripts, and I thought it was interesting. Run 'conflict.sh' to see how the merge is properly handled, and then 'conflict.sh broken' to see how the merge is not properly handled if the modified lines don't have a newline between them. Unfortunate.
Finally, there's mvconflict.sh. This is the exact same as conflict.sh except that it always has the newline in between the lines (so that we know that git ought to be able to merge properly), and it renames the file on the branch before modifying it. git cannot merge the file after it has been moved and modified on the branch, and modified but not moved on the master, although it should be able to because the changes are exactly the same as in conflict.sh (that did merge properly), except with a file rename in the middle.
Perhaps rebase works better than merge when handling file renames, I don't know. Merging in Perforce is nice because you retain development history of files across branches; but I can see how this might be contrary to the git philosophy. After all, branches are generally local in git, and you lose all of your branch history when you rebase/merge your changes back into master for the purposes of pushing those changes to master in the origin git server anyway, especially if you use squash to collapse your history.
I'd be happy to take further discussion off-list if people are getting tired of this.
I think mailman scrubbed the attachments... :(
But I noticed something - are you using "merge" exclusively? That may be part of the issue here. Most of the time when I merge, say branch-a onto master, I checkout branch-a, rebase master, checkout master, merge branch-a. Even when cherry-picking commits, a rebase cleans up common commits properly. Perhaps that's part of the issue here - not using rebase
Yes, I use merge almost exclusively. I only use rebase to bring my changes that haven't been committed to the origin master up to the head of my local master branch, to ensure that they would continue to apply without changes to the master branch as it currently stands. I think it's clear that I am not entirely in tune with the zen of git yet, which is probably the cause of the majority of the problems I have had with it. I will start by trying to understand rebase much better, since it seems to be key to doing alot of things in git. I will append my scripts inline here. Thanks, Bryan --- #!/bin/sh -x mkdir losthistory cd losthistory git init echo "This is a file." > file git add file git commit -m "Added file" git checkout -b branch git mv file file2 git commit -m "Moved file to file2" echo "This is a file now named file2." > file2 git add file2 git commit -m "Modified file2" git checkout master git merge branch git log -M file2 --- #!/bin/sh -x mkdir conflict cd conflict git init echo "This is a fil." > file if [ -z "$1" ]; then echo >> file fi echo "It has two line." >> file git add file git commit -m "Added file" git checkout -b branch echo "This is a fil." > file if [ -z "$1" ]; then echo >> file fi echo "It has two lines." >> file git add file git commit -m "Fixed second line of file" git checkout master echo "This is a file." > file if [ -z "$1" ]; then echo >> file fi echo "It has two line." >> file git add file git commit -m "Fixed first line of file" git checkout branch git merge master --- #!/bin/sh -x mkdir mvconflict cd mvconflict git init echo "This is a fil." > file echo >> file echo "It has two line." >> file git add file git commit -m "Added file" git checkout -b branch git mv file file2 git commit -m "Renamed file -> file2" echo "This is a fil." > file2 echo >> file2 echo "It has two lines." >> file2 git add file2 git commit -m "Fixed second line of file2" git checkout master echo "This is a file." > file echo >> file echo "It has two line." >> file git add file git commit -m "Fixed first line of file" git checkout branch git merge master