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

[Sebastian Nowicki]

On 24/02/2009, at 6:10 AM, Bryan Ischo wrote:

> It's not the ability to modify a single file in two different places  
> at once.  It's the ability to keep changes logically separated by  
> directory, in a persistent manner that doesn't require git commands  
> to put changes away and bring them back, that I care about.  I find  
> it infinitely easier to keep track of what I am doing by  
> persistently retaining directory contents than by having a single  
> working view and everything else being stashed away to be retrieved  
> later.

I apologise if I'm missing something, but what's the difference  
between "cd ../branch" and "git checkout branch"? The state of your  
"working directory" is changed. You still have only one view of the  
directory. You can obviously view files in the other directory, but  
that's also possible with git, albeit somewhat harder if using a file  
manager. There are many GUI front-ends that allow you to quickly look  
at other branches and commits. What's the between "ls project-root"  
and "git branch"? Both list the "branches", both allow you to switch  
to that branch (cd, git checkout). I really don't see the difference,  
besides a clean project directory, in git's case.

> One example of where git stash is more cumbersome is if you've  
> created new files but haven't added them to the index yet.  You have  
> to add them to the index before you can stash.  Now this is not a  
> huge deal, but it does require more work to prep your tree for a  
> stash than simply cd'ing out to another branch directory would  
> take.  There may be other cases where more work is involved in  
> stashing (above and beyond having to actually run the git stash  
> commands and maintain the list of stashes) than is involved in using  
> locally stored branches, but I haven't used git stash enough to  
> discover them.  It would not surprise me to learn that there are  
> lots of subtle details to be aware of when using git stash.

This is a bit of an annoyance, but it probably has more to do with  
workflow and discipline rather than git. You could leave that file  
there without tracking it at all, as long as the same file doesn't  
exist in another branch. However, this would be bad, since it's not  
"attached" to any branch and could get confusing. Before `git stash`  
came about, people just used `git commit -a -m "WIP something"`, which  
is pretty much all `git stash` does, except in a different... ref list  
I suppose. In this edge-case it's a bit more work to change to a  
different branch, but I think it only encourages to use the SCM  
properly.

> Parallel branch directories have an advantage over git's branch  
> views whenever you need to compare the contents of branches.

False. As mentioned earlier there are GUI tools which make this  
simple. If you don't like GUIs, you can use the command line  
equivalents (most tools execute git commands anyway). I don't know  
what these are since I've never had the need to compare two branches  
beyond `git diff`.

> Maybe it's because I'm an emacs [...] [and] keeping track of [...]  
> what sequence of [...] commands I need [...] is just more mental  
> effort than I want to undertake.

*cheap shot alert*
You use emacs, yet remembering commands is too much of an effort? I  
know I twisted your words a lot, and I'm not hating on emacs, but you  
have to admit that that is somewhat hypocritical.

>  I find it so much easier to just leave a branch subdirectory and  
> when I return to it later, it is guaranteed to be exactly as it was  
> when I left, without any effort on my part.  If I am working on 4 or  
> 5 bugs in parallel (which I have certainly done at work, where  
> working on just 1 or 2 bugs at once would be inefficient because of  
> the downtime associated with building each tree) I can't even  
> imagine using git stashes to sanely keep track of everything.

This is exactly what branches are for. The exact same thing can be  
said for git branches. It's guaranteed to be exactly as it was when  
you switched to another branch. `git stash` should only be used when  
something is not ready to be committed, but you _urgently_ need to do  
something else, like a bug fix on the maintenance branch.

>>> - 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

I can't think of a situation where the file name is relevant. Even  
when renaming...

> The problem comes when someone, in a branch, renames a file, and  
> then tries to merge their changes into another branch in which the  
> file was not renamed.

This would only be a problem if the file was not only renamed, but  
also _changed_, and significantly at that. In this case git would only  
see that, say, 60% of the file content was moved. I'm not sure how  
merging would work, since I have never worked on a branch when a file  
was moved (and changed) in another.

>  Unless file renames are tracked, the merge becomes very difficult.

Not at all. If git sees that the file content was _moved_ (not  
changed), it should be able to figure that out easily. Again, I  
haven't actually done this, but I don't see why it wouldn't work. I  
would suggest asking about this on #git (or the git ML). If it is  
indeed a problem then file a bug. I'm sure Linus would be happy to  
comment on it ;).

>  Refactoring a subsystem on a 'workbranch' is something that is done  
> sometimes on large projects,  and with git, I would expect that to  
> be basically impossible to do sanely.  Even if git's 'detect renames  
> while examining history' technique did work, it still makes renames  
> cumbersome, because you can't rename a file and change its contents  
> at the same time or else git has almost no chance of detecting the  
> rename via history.  And if you can't change a file and rename it at  
> the same time, then you can't, for example, properly rename a Java  
> class, because the class name and file name have to be the same.

Why not? If you change the file contents and rename it, then obviously  
you'd also change the class name. Why else would you rename it?

> It just shouldn't be that hard.

Why not? I can't imagine other SCMs doing this any better. If a file  
contents changes drastically, it doesn't matter if the name of the  
file is tracked. The name of the file is irrelevant. A merge conflict  
would arise even if the file was never renamed.

I don't mean to contradict everything you say, it's just that I  
haven't had the same experience with git as you. Using git has been  
amazing. It does everything I want, it's sophisticated, it merges code  
well, and it has some very powerful features (like rebase).

By the way, Mercurial seems faster than Bazaar (though I haven't used  
either much), and both are written in Python. Mercurial might not be  
pure python though, I am unsure.