On Mon, Feb 23, 2009 at 4:42 PM, Bryan Ischo <[email protected]> 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 _______________________________________________ pacman-dev mailing list [email protected] http://www.archlinux.org/mailman/listinfo/pacman-dev
