Reuse repositories when updating

Kwpolska / pkgbuilder

An AUR helper (and library) in Python 3.

http://pkgbuilder.rtfd.org/

BSD 3-Clause "New" or "Revised" License

69 stars 13 forks source link

Reuse repositories when updating #36

Closed ruuda closed 9 years ago

ruuda commented 9 years ago

If I understand correctly, currently PKGBUILDer can only do a clone, but not a pull. For an update, an existing repository is not reused by doing a pull, but instead one has to use the -c flag to remove the old repository and clone again. It would be great if instead of

==> Cloning the git repository...
==> ERROR: Directory <package> already exists, please run with `-c` to remove it.
  -> skipping package <package>

it would simply do a pull to get the latest version.

Kwpolska commented 9 years ago

It certainly makes sense, I’ll get that done soon.

Kwpolska commented 9 years ago

Fixed on the develop branch, will make a release soon. New behavior:

if no directory exists, clone as usual
if directory exists and is a git repository, pull it and update
if directory exists and is not a git repository, skip this package

ruuda commented 9 years ago

Awesome!

AladW commented 6 years ago

This is somewhat inconvenient since any diffs are lost after git pull is done. I guess you could git diff / git merge manually before running PKGBUILDer...

Kwpolska commented 6 years ago

Are you sure about that? git pull should not remove unstaged/uncommitted changes from your working copy.

AladW commented 6 years ago

Well, in particular I meant upstream changes, for example when someone else adopted an AUR package and made a bunch of changes to the PKGBUILD compared to the last checkout.

Kwpolska commented 6 years ago

I’m not sure I understand the problem.

AladW commented 6 years ago

When I have new targets I'd run pkgbuilder -G so that I can take a look at PKGBUILDs before building them.

When I have existing targets I'd run pkgbuilder -G again, but since a git merge was run (via git pull) I'd have no way to see what changes are "new" (for example, a new maintainer changed the source to something malicious) and have to review the whole bunch anew.

Kwpolska commented 6 years ago

Okay, got it. IMO the current behavior is the better option.