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

[Bryan Ischo]

Aaron Griffin wrote:
> On Mon, Feb 23, 2009 at 4:42 PM, Bryan Ischo
> <bji-keyword-pacman.3644cb at 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