[pacman-dev] [PATCH 1/2] Enabled new interactive prompt and updated some tests.

[Bryan Ischo]

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.

Thanks,
Bryan