February 2009 - Pacman-dev - lists.archlinux.org

[pacman-dev] [GIT] The official pacman repository branch, maint, updated. v3.2.2-10-gb3c67a1
by dan＠archlinux.org 28 Feb '09

28 Feb '09

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, maint has been updated via b3c67a195f254fe456003559ceac0ae0771d93e6 (commit) from a309a016bfed9f67452f2a6556fb4391fd55b34e (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- ----------------------------------------------------------------------- Summary of changes: lib/libalpm/po/LINGUAS | 1 + lib/libalpm/po/kk.po | 557 +++++++++++++++++ po/LINGUAS | 1 + po/kk.po | 1575 ++++++++++++++++++++++++++++++++++++++++++++++++ 4 files changed, 2134 insertions(+), 0 deletions(-) create mode 100644 lib/libalpm/po/kk.po create mode 100644 po/kk.po hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [GIT] The official pacman repository branch, master, updated. v3.2.2-99-gd8d9ab8
by dan＠archlinux.org 28 Feb '09

28 Feb '09

This is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The official pacman repository". The branch, master has been updated via d8d9ab8c870eb9f2df5e6e607b1da34e6e40e29e (commit) via 4458f71851e6056957e6fafebec286765bbbcc39 (commit) via b4e1365657f477f4e27933ccc3d408b7e19ac6da (commit) via 8c09c19139b47dab3bf2282f87fe289e1282f361 (commit) via f09f82ee595319917c794dff69486bca851a5601 (commit) via b3c67a195f254fe456003559ceac0ae0771d93e6 (commit) from 2268981ebf562a7dda1e788dbd931e48adf9fabb (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- commit d8d9ab8c870eb9f2df5e6e607b1da34e6e40e29e Author: Dan McGee <dan(a)archlinux.org> Date: Sat Feb 28 15:46:51 2009 -0600 Update checks for python in configure Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 4458f71851e6056957e6fafebec286765bbbcc39 Merge: b4e1365657f477f4e27933ccc3d408b7e19ac6da b3c67a195f254fe456003559ceac0ae0771d93e6 Author: Dan McGee <dan(a)archlinux.org> Date: Sat Feb 28 15:43:36 2009 -0600 Merge branch 'maint' commit b4e1365657f477f4e27933ccc3d408b7e19ac6da Author: Xavier Chantry <shiningxc(a)gmail.com> Date: Wed Feb 25 19:40:57 2009 +0100 makepkg : remove xdelta support The pkgdelta script can be used instead. Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> Signed-off-by: Allan McRae <allan(a)archlinux.org> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit 8c09c19139b47dab3bf2282f87fe289e1282f361 Author: Xavier Chantry <shiningxc(a)gmail.com> Date: Wed Feb 25 18:24:38 2009 +0100 libalpm: remove from_md5 and to_md5 from pmdelta_t The from_md5 and to_md5 fields were a nice extra safety, which would avoid trying to apply deltas on corrupted package files. However, they are not strictly necessary, since xdelta should be able to detect that on its own. The main problem is that it is impossible to compute these informations from the delta only. So repo-add would not be able to compute the delta entry based on just the delta file. Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> commit f09f82ee595319917c794dff69486bca851a5601 Author: Xavier Chantry <shiningxc(a)gmail.com> Date: Thu Feb 26 18:00:15 2009 +0100 repo-add: print warning if same version already exists Simple fix for FS#13414. Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> Signed-off-by: Dan McGee <dan(a)archlinux.org> ----------------------------------------------------------------------- Summary of changes: configure.ac | 2 +- doc/makepkg.conf.5.txt | 7 +- etc/makepkg.conf.in | 5 +- lib/libalpm/alpm.h | 2 - lib/libalpm/delta.c | 57 +-- lib/libalpm/delta.h | 14 +- lib/libalpm/po/LINGUAS | 1 + lib/libalpm/po/kk.po | 557 +++++++++++++++++ lib/libalpm/sync.c | 1 - po/LINGUAS | 1 + po/kk.po | 1575 ++++++++++++++++++++++++++++++++++++++++++++++++ scripts/makepkg.sh.in | 66 -- scripts/repo-add.sh.in | 10 +- 13 files changed, 2165 insertions(+), 133 deletions(-) create mode 100644 lib/libalpm/po/kk.po create mode 100644 po/kk.po hooks/post-receive -- The official pacman repository

1 0

[pacman-dev] [PATCH 11/11] repo-add : fix package variables declaration
by Xavier Chantry 27 Feb '09

27 Feb '09

- arch was missing - backup is not used by repo-add. However makepkg still needs to put it in PKGINFO because pacman uses it - startdir is no longer used after the new delta implementation - the declaration of group, depend, backup, etc is not needed because these variables are always declared before being used : declare $var="$val" case "$var" in group) _groups="$_groups$group\n" ;; - reorder the variables declaration to follow the same order than they are written to the depends and desc file, for making future checks easier Signed-off-by: Xavier Chantry <shiningxc(a)gmail.com> --- scripts/repo-add.sh.in | 12 ++++-------- 1 files changed, 4 insertions(+), 8 deletions(-) diff --git a/scripts/repo-add.sh.in b/scripts/repo-add.sh.in index 504adfd..4097a11 100644 --- a/scripts/repo-add.sh.in +++ b/scripts/repo-add.sh.in @@ -180,10 +180,8 @@ db_write_entry() { # blank out all variables local pkgfile="$1" - local pkgname pkgver pkgdesc url builddate packager csize size \ - group depend backup license replaces provides conflict force \ - _groups _depends _backups _licenses _replaces _provides _conflicts \ - startdir optdepend _optdepends md5sum + local pkgname pkgver pkgdesc csize size md5sum url arch builddate packager force \ + _groups _licenses _replaces _depends _conflicts _provides _optdepends local OLDIFS="$IFS" # IFS (field separator) is only the newline character @@ -200,12 +198,11 @@ db_write_entry() declare $var="$val" case "$var" in group) _groups="$_groups$group\n" ;; - depend) _depends="$_depends$depend\n" ;; - backup) _backups="$_backups$backup\n" ;; license) _licenses="$_licenses$license\n" ;; replaces) _replaces="$_replaces$replaces\n" ;; - provides) _provides="$_provides$provides\n" ;; + depend) _depends="$_depends$depend\n" ;; conflict) _conflicts="$_conflicts$conflict\n" ;; + provides) _provides="$_provides$provides\n" ;; optdepend) _optdepends="$_optdepends$optdepend\n" ;; esac done @@ -222,7 +219,6 @@ db_write_entry() return 1 fi - startdir=$(pwd) pushd "$gstmpdir" 2>&1 >/dev/null if [ -d "$pkgname-$pkgver" ]; then -- 1.6.1.3

1 0

[pacman-dev] repo-add sanity check
by Allan McRae 27 Feb '09

27 Feb '09

Hi, I took repo-add from the pacman package and one built from the latest git will all Xavier's patches and made a repo db from all packages in my cache (all of testing, core and extra, some community). There are a few differences (see http://dev.archlinux.org/~allan/repoadd-diff.txt). A summary of the differences: A bunch of packages have the ARCH field removed: -%ARCH% -i686 A few differences to do with quotes. e.g. -custom:INTEL537 +custom:"INTEL537" and +%DESC% +Efficient bit vector, set of integers and "big int" math library This change is not so good... (k3b-i18n package) %DEPENDS% -k3b>=1.0.5-1 +k3b>=$pkgver Allan

3 5

[pacman-dev] Disk Space
by Matthew Wood 26 Feb '09

26 Feb '09

I'm a little new to package management coding, so forgive my stupid question, but I'm wondering if there is a way to get the current package size. For example, like Aarons example, if foobar-1.0 is installed, and we got the size of foobar then we should have a reasonable size estimate of foobar-1.1. If we took that estimate, multiply by 10% and compare that number to the disk space remaining, would that catch 99% of the errors? If there isn't a current mechanism we could have a function that adds the total size of all the installed apps files and return that to the upgrade function. What about that coupled with a prompt if disk space seems low, say below 100-200 mb? I'd be willing to help with whatever patches are necessary for this.

2 1

[pacman-dev] Dan's and Xavier's git home
by Xavier 26 Feb '09

26 Feb '09

On Thu, Feb 26, 2009 at 10:25 AM, Allan McRae <allan(a)archlinux.org> wrote: > > OK. I will pull your patches into a git branch to remind myself to go > through these in a lot of detail sometime in the next week or so. Do you > have a git home now that Dan moved his server or do I need to apply them > from the mailing list? shining.toofishes.net does not seem to exist > anymore. > My repo has moved to Dan's new server, and they can now all be found on the same page, with a cgit interface : http://code.toofishes.net/cgit/ Thanks Dan :)

2 2

[pacman-dev] Disk Space
by Matthew Wood 24 Feb '09

24 Feb '09

What if we checked for disk space on all volumes, prior to the processing of the users command. If the function detects that disk space is lower than a certain amount, say 100 mb, to at least warn the user? This would of course be a temporary solution, for a more permanent possibility we could implement two functions that work in conjunction with each other. The first function would check the downloads to ensure they completed successfully, if they did then it would pass the work to a second function that checks the extracted package size against all mounted volumes, or at least the size of the volumes of the major installation location (/usr, /etc, /var, etc) Does this make any sense or am I barking up the wrong tree? Matt

5 5

[pacman-dev] Possible bug in pacman
by Matías De la Puente 24 Feb '09

24 Feb '09

hi all! i wanted to ignore a pkg in a group but i can with this: pacman -S gnome-extra --ignore orca Pacman after i say yes to install all the packages but then ask me if i want to install orcad that's insidce ignorePkg/ignoreGroup, i say no but then pacman exit saying that it can't found orca pkg or group Thanks matias

2 1

[pacman-dev] [PATCH 1/2] Enabled new interactive prompt and updated some tests.
by Bryan Ischo 24 Feb '09

24 Feb '09

From: Bryan Ischo <bryan(a)ischo.com> Enabled a new prompt to ask the user if they'd like to remove unresolvable packages from the transaction rather than failing it. Many pactest tests that used to fail not return success codes, because pacman now issues a prompt allowing the user to cancel rather than failing many transactions, and the pactest scripts always choose to cancel with no error rather than failing. The only net effect is that the return status of pacman is now 0 in cases where it used to be nonzero. Signed-off-by: Bryan Ischo <bryan(a)ischo.com> --- lib/libalpm/alpm.h | 3 ++- lib/libalpm/deps.c | 6 +++--- lib/libalpm/sync.c | 23 ++++++++++++++++++----- pactest/tests/provision020.py | 2 +- pactest/tests/provision022.py | 2 +- pactest/tests/sync1008.py | 2 +- pactest/tests/sync300.py | 2 +- src/pacman/callback.c | 16 ++++++++++++++++ 8 files changed, 43 insertions(+), 13 deletions(-) diff --git a/lib/libalpm/alpm.h b/lib/libalpm/alpm.h index 7b7ca4e..3836d60 100644 --- a/lib/libalpm/alpm.h +++ b/lib/libalpm/alpm.h @@ -371,7 +371,8 @@ typedef enum _pmtransconv_t { PM_TRANS_CONV_REPLACE_PKG = 0x02, PM_TRANS_CONV_CONFLICT_PKG = 0x04, PM_TRANS_CONV_CORRUPTED_PKG = 0x08, - PM_TRANS_CONV_LOCAL_NEWER = 0x10 + PM_TRANS_CONV_LOCAL_NEWER = 0x10, + PM_TRANS_CONV_REMOVE_PKGS = 0x20, } pmtransconv_t; /* Transaction Progress */ diff --git a/lib/libalpm/deps.c b/lib/libalpm/deps.c index 41d2a83..ebcd18d 100644 --- a/lib/libalpm/deps.c +++ b/lib/libalpm/deps.c @@ -531,8 +531,8 @@ pmpkg_t *_alpm_resolvedep(pmdepend_t *dep, alpm_list_t *dbs, alpm_list_t *exclud !_alpm_pkg_find(excluding, pkg->name)) { if(_alpm_pkg_should_ignore(pkg)) { int install; - QUESTION(handle->trans, PM_TRANS_CONV_INSTALL_IGNOREPKG, pkg, - tpkg, NULL, &install); + QUESTION(handle->trans, PM_TRANS_CONV_INSTALL_IGNOREPKG, + pkg, tpkg, NULL, &install); if(!install) { continue; } @@ -609,7 +609,7 @@ int _alpm_resolvedeps(pmdb_t *local, alpm_list_t *dbs_sync, pmpkg_t *pkg, if(!spkg) { pm_errno = PM_ERR_UNSATISFIED_DEPS; char *missdepstring = alpm_dep_compute_string(missdep); - _alpm_log(PM_LOG_ERROR, _("cannot resolve \"%s\", a dependency of \"%s\"\n"), + _alpm_log(PM_LOG_WARNING, _("cannot resolve \"%s\", a dependency of \"%s\"\n"), missdepstring, tpkg->name); free(missdepstring); if(data) { diff --git a/lib/libalpm/sync.c b/lib/libalpm/sync.c index 5e5ca92..ea903f4 100644 --- a/lib/libalpm/sync.c +++ b/lib/libalpm/sync.c @@ -442,12 +442,25 @@ int _alpm_sync_prepare(pmtrans_t *trans, pmdb_t *db_local, alpm_list_t *dbs_sync dependencies not already on the list */ } - /* If there were unresolvable top-level packages, fail the - transaction. */ + /* If there were unresolvable top-level packages, prompt the user to + see if they'd like to ignore them rather than failing the sync */ if(unresolvable != NULL) { - /* pm_errno is set by resolvedeps */ - ret = -1; - goto cleanup; + int remove_unresolvable = 0; + QUESTION(handle->trans, PM_TRANS_CONV_REMOVE_PKGS, unresolvable, NULL, NULL, &remove_unresolvable); + if (remove_unresolvable) { + /* User wants to remove the unresolvable packages from the + transaction, so simply drop the unresolvable list. The + packages will be removed from the actual transaction when + the transaction packages are replaced with a + dependency-reordered list below */ + alpm_list_free(unresolvable); + unresolvable = NULL; + } + else { + /* pm_errno is set by resolvedeps */ + ret = -1; + goto cleanup; + } } /* Add all packages which were "pulled" (i.e. weren't already in the diff --git a/pactest/tests/provision020.py b/pactest/tests/provision020.py index 7cb0a01..c9c0ac3 100644 --- a/pactest/tests/provision020.py +++ b/pactest/tests/provision020.py @@ -10,6 +10,6 @@ self.args = "-S %s" % p.name -self.addrule("PACMAN_RETCODE=1") +self.addrule("PACMAN_RETCODE=0") self.addrule("!PKG_EXIST=pkg1") self.addrule("PKG_EXIST=pkg2") diff --git a/pactest/tests/provision022.py b/pactest/tests/provision022.py index 4883d42..190a8b6 100644 --- a/pactest/tests/provision022.py +++ b/pactest/tests/provision022.py @@ -10,6 +10,6 @@ self.args = "-S %s" % p.name -self.addrule("PACMAN_RETCODE=1") +self.addrule("PACMAN_RETCODE=0") self.addrule("!PKG_EXIST=pkg1") self.addrule("PKG_EXIST=pkg2") diff --git a/pactest/tests/sync1008.py b/pactest/tests/sync1008.py index a606459..90c61df 100644 --- a/pactest/tests/sync1008.py +++ b/pactest/tests/sync1008.py @@ -14,6 +14,6 @@ self.args = "-S pkg" -self.addrule("PACMAN_RETCODE=1") +self.addrule("PACMAN_RETCODE=0") self.addrule("!PKG_EXIST=pkg") self.addrule("!PKG_EXIST=cpkg") diff --git a/pactest/tests/sync300.py b/pactest/tests/sync300.py index 31b520a..36d6758 100644 --- a/pactest/tests/sync300.py +++ b/pactest/tests/sync300.py @@ -9,6 +9,6 @@ self.args = "-S %s" % sp1.name -self.addrule("PACMAN_RETCODE=1") +self.addrule("PACMAN_RETCODE=0") self.addrule("!PKG_EXIST=pkg1") self.addrule("!PKG_EXIST=pkg2") diff --git a/src/pacman/callback.c b/src/pacman/callback.c index 6e7930c..d6b5b01 100644 --- a/src/pacman/callback.c +++ b/src/pacman/callback.c @@ -270,6 +270,22 @@ void cb_trans_conv(pmtransconv_t event, void *data1, void *data2, (char *)data2, (char *)data2); break; + case PM_TRANS_CONV_REMOVE_PKGS: + { + alpm_list_t *unresolved = (alpm_list_t *) data1; + alpm_list_t *namelist = NULL, *i; + for (i = unresolved; i; i = i->next) { + namelist = alpm_list_add(namelist, + (char *) alpm_pkg_get_name(i->data)); + } + printf(":: the following package(s) cannot be upgraded due to " + "unresolvable dependencies:\n"); + list_display(" ", namelist); + *response = yesno(_("\nDo you want to skip the above " + "package(s) for this upgrade?")); + alpm_list_free(namelist); + } + break; case PM_TRANS_CONV_LOCAL_NEWER: if(!config->op_s_downloadonly) { *response = yesno(_(":: %s-%s: local version is newer. Upgrade anyway?"), -- 1.6.1

7 45

Re: [pacman-dev] Git's views versus parallel branches (was Re: [PATCH 1/2] Enabled ...)
by Sebastian Nowicki 24 Feb '09

24 Feb '09

On 24/02/2009, at 1:45 PM, Bryan Ischo wrote: > An analogy: using git is kind of like keeping every directory in > your home directory in a separate tar file, except for one untarred > working directory. Whenever you want to cd into a new directory, > you have to tar up the directory you were just in, and then untar > the directory you want to cd into. Although I understand what you're getting at, the analogy is an exaggeration. The workflow you described requires archiving the directory, storing the archive somewhere, then removing the directory, and un-archiving a different archive, then changing to that directory. This is in contrast with a simple "git checkout branch" (possibly with a prior commit, or stash, operation). I.e., five operations as opposed to one or two. > An example of what I can do with parallel branches: if my branch > 'new' and 'old' were stored in two separate subdirectories, then I > could grep through all of the files in both branches with one > command and see collated results; or could diff only files in which > a given identifier appeared only in a file on one branch but not the > corresponding file on another. Given git's flexibility and UNIX philosophy, I'm sure it would be possible to create tools which did this. Most of my development thus far has been either adding features, or modifying small things, so I haven't had a need for this. In general the changes where not conflicting between branches, and I did not need to compare my branches with an upstream master branch. Perhaps this is a workflow issue (doing too many things at once)? > Another problem with git: I have to constantly rebuild stuff when I > stash and unstash because my build directory doesn't stash. I don't see why anyone would want to frequently change directories and compile. When I switch to a branch I tend to work on it for a while before switching to another one. > I'd rather use a paradigm that thousands of tools already depend on, > than the special case paradigm that is git. I don't see how this would improve your workflow in any way whatsoever, but it is possible to simply keep multiple trees, with a specific branch checked out. For instance instead of having one git repository "foobar", you could have a project directory "foobar", and have two repositories "eggs" and "spam", cloned from the same "master" repository, but with the "eggs" and "spam" branches checked out, respectively. You could still do all the other operations with git, if you add the other repositories as remotes, but this adds unnecessary maintenance. I see Dan beat me to pointing this out already. > If anything, git seems messier to me because some files get changed > in-place as you switch branches in git, and some files are ignored > and left as they are (those that aren't actually tracked by git), > and distinguishing between the two types requires git commands and > lots of mental notes. As I mentioned in my previous post, the files simply shouldn't be ignored, they should be added to a temporary commit before switching, otherwise you get confused. This is the downside of switching branches in-place. I don't really have a preference between a directory-based branch structure or an in-place structure. However, git's branches let you have a single tree (working directory), which seems simpler and cleaner. > you can do a grep over multiple branches at once to find identifiers git grep (not sure if it can actually grep over multiple branches) > , you can count line numbers for entire branches if you like to see > how much bigger your code base is in one branch than another git diff my_branch..other_branch --stat > you have to run many git commands Not really. Git is highly scriptable, if you do something often, you can script the git commands to do it (if they don't already exist), and just run the script. This is also what you'd call the UNIX philosophy. > git seems to require keeping a mental model of branches that you > can't even "see" because they aren't in your filesystem anywhere. Indeed, git doesn't track files, it tracks file content. Branches are just labels for a sequence of changes. I'm sure this gives git many advantages over other SCMs, but I'm not familiar enough with the underlying implementation to give any insight. > Except that not only am I getting confused about the state of my > branches as I commit partially complete changes to them for the > purpose of saving state as I switch between branches, the tools that > I use are getting confused as well. This seems to be a consistent theme in your workflow - "I switch branches frequently". This is probably why you're having so much trouble with git, and I suggest you ask yourself _why_ you switch branches so frequently. It seems to me like you're treating branches more like commits - each branch is a single logical change to the tree. Even though branches are cheap, I still only have a few around, and rarely switch between them. They are there to separate related commits, and to provide isolation from other branches. It may be that you're a "hacker" and simply work on unrelated code arbitrarily. I do that a lot too, but I somehow don't have the same problems you're facing. > Do some google searches. File renaming in version control systems > is a big deal, and for good reason. Like this? ;) http://article.gmane.org/gmane.comp.version-control.git/217 > Yes; it's called refactoring. On a well managed project it doesn't > happen often, but it does happen. Reorganization of subtrees of > code is something that source control systems should support well. > It's the merging after such reorganization that tools that don't > track renames have problems with. For examples of git failing in > this, take a look at the simple scripts I sent out to the list > earlier today. I don't see how renames are relevant in this situation. In fact, rename information would probably cause more problems. When you refactor, you're moving content, not files. Typically you also change that content significantly. I don't see why git would have any problem with this - this is actually where git's content tracking shines. > Git doesn't allow you to rename and change contents of a file at the > same time: > > [snip] > > If I 'git commit' it will take the rename of file to file2, but not > the modification of file2. If I try to add file2 before committing, > git status now shows: > > [snip] > > If you check this in, git will not be able to merge changes to file2 > into a branch taken before this change. I just tried a a more complex example that I was sure would result in a merge conflict. I basically created "file" and committed. I created the "move" branch I moved "file" to "file2", and edited it. At this point, `git status` showed something different to your output: $ git mv file file2 $ vi file2 $ git add file2 $ git status # On branch move # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # renamed: file -> file2 # $ git commit -m "changed file and renamed as file2" [move]: created 1fe9963: "changed file and renamed as file2" 1 files changed, 6 insertions(+), 8 deletions(-) rename file => file2 (58%) I commited the change, and created a branch "change" from master. I edited the same parts of the file and commited. Now I merged branch "move" into this branch. Naturally I get a conflict: $ git merge move Renaming file => file2 Auto-merging file2 CONFLICT (rename/modify): Merge conflict in file2 Automatic merge failed; fix conflicts and then commit the result. bash-3.2$ git status file2: needs merge # On branch changes # Changes to be committed: # (use "git reset HEAD <file>..." to unstage) # # deleted: file # # Changed but not updated: # (use "git add <file>..." to update what will be committed) # (use "git checkout -- <file>..." to discard changes in working directory) # # unmerged: file2 # Even when the file was moved, and a significant amount of it was changed (42%), git managed to see that it was moved, and still merged "file2" from the "move" branch with "file" from the "change" branch. The conflict would have occurred regardless of the move operation. Perhaps in a less contrived example the result would be different, but it would be an edge case where the renamed file's content really doesn't resemble that of the original file. > My impression of git is that it feels very much like what its > history suggests that it is: a tool for managing patches that grew > into a source control system. For better or worse, git feels > 'messy' to me, like it wasn't thought out ahead of time but kind of > organically grew I'm sure it was planned out quite well. Linus knew what he hated about other SCMs, he had some good ideas about how to improve those areas, and he did. Git does everything very well so far, and it's faster than any SCM I know about. > Git has dozens of commands, each with dozens of subtle and tricky > options; that seems like needless complexity to me. Git was made by a developer for developers. Of course the interface won't be nice and shiny. The difference between Git's interface and other SCMs' interfaces is that Git has it's guts exposed. Fortunately there is nice porcelain now. I suggest that you discuss these problems with the people at #git. They seem friendly and they know a _lot_ about git. I'm sure they could either explain how to use git to accommodate your workflow, or perhaps expose "flaws" in your workflow. At the very least you will know if git is for you or not. Sorry for going so off-topic here. This isn't even about pacman anymore :P.

2 1