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

[Aaron Griffin]

On Mon, Feb 23, 2009 at 1:11 PM, Bryan Ischo
<bji-keyword-pacman.3644cb at www.ischo.com> wrote:
> Aaron Griffin wrote:
>>
>> On Sun, Feb 22, 2009 at 10:12 PM, Sebastian Nowicki <sebnow at gmail.com>
>> wrote:
>>
>>>
>>> On 23/02/2009, at 12:57 PM, Bryan Ischo wrote:
>>>
>>>
>>>>
>>>> OK, so I guess I really need to get into the habit of using git-rebase
>>>> -i.
>>>>
>>>
>>> Yes, git rebase is one of the most wonderful things about git.
>>>
>>
>> git rebase -i, git add -p, and git stash are my three most "omg
>> awesome" git commands.
>
> Just curious ... what's so awesome about git stash?  It seems to me that it
> is only necessary because git doesn't support multiple branches in the same
> tree.  The Perforce (and some DVCS systems like Bazaar) way is to root each
> branch at a different subdirectory of your repository top-level directory in
> your local filesystem.  Then you can work on files in multiple branches
> simultaneously without having to 'switch' your view between them constantly,
> 'stashing' and 'unstashing' changes all the time.

I use git stash when switching back and forth between branches when I
am of the mindset that "oh this isn't commit-able yet".

I keep noticing you mention "multiple branches in the same tree", but
am at a loss as to why that's necessary. git offers the same
functionality, mainly due to the fact that a "git checkout" is as
quick as a "cd".

git co master
...change...
commit
git co branch-a
...change...
commit
..change..
stash
git co master
git stash --apply
commit

I guess I can't think of a good use-case when you would want to edit
foo.c from BOTH master and branch-a at the exact same time... it seems
like an attention killer to me. Like watching two TVs at once or
something.

Could you explain why you would need the files side-by-side?


> - A single branch-based 'view' that switches your files around in-place as
> you change which branch you are on, instead of keeping branches in separate
> subdirectories

See above - I don't get how this is a con, as branch switching in git
is painfully quick

> - Lack of rename tracking.  Yeah, I know, git claims that it can do it after
> the fact when examining change histories but I've tried various scenarios
> and it just doesn't work very well, and even when it does, requires stupidly
> complex options to git commands to enable git to discover renames in the
> history correctly

git is focused on file contents, and doesn't really care where those
contents actually are. It seems odd to me too, but I have yet to
discover a case when this is a big deal - I mean if I'm looking at
some C code, I don't care if the file is named something.c or
SOEMTHING.c or omgwtf.c - it's the code that matters.