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

[Aaron Griffin]

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