Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Reuse repositories when updating #36

Closed
ruuda opened this issue Sep 3, 2015 · 9 comments
Closed

Reuse repositories when updating #36

ruuda opened this issue Sep 3, 2015 · 9 comments
Assignees
@Kwpolska
Labels
enhancement feature request
Milestone
v4.2.3

Comments

@ruuda
Copy link

ruuda commented Sep 3, 2015

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 Kwpolska self-assigned this Sep 4, 2015
@Kwpolska
Copy link
Owner

Kwpolska commented Sep 4, 2015

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

@Kwpolska
Copy link
Owner

Kwpolska commented Sep 5, 2015

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
Copy link
Author

ruuda commented Sep 5, 2015

Awesome!

@Kwpolska Kwpolska modified the milestone: v4.2.3 Sep 6, 2015
Kwpolska added a commit that referenced this issue Sep 8, 2015
@Kwpolska
v4.2.3: bugfixes and improvements (#36 #37)
5013071 
Signed-off-by: Chris Warrick <kwpolska@gmail.com>
@AladW
Copy link

AladW commented Jun 13, 2018

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
Copy link
Owner

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

@AladW
Copy link

AladW commented Jun 13, 2018

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
Copy link
Owner

I’m not sure I understand the problem.

@AladW
Copy link

AladW commented Jun 13, 2018

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
Copy link
Owner

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@Kwpolska Kwpolska

Labels
enhancement feature request
Projects
None yet
Milestone
v4.2.3
Development

No branches or pull requests
3 participants
@Kwpolska @ruuda @AladW