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.

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

Thoughts about --auto-pull --auto-push flags? #41

Open
N2OMatt opened this issue Sep 26, 2017 · 5 comments
Open

Thoughts about --auto-pull --auto-push flags? #41

N2OMatt opened this issue Sep 26, 2017 · 5 comments

Comments

@N2OMatt
Copy link

N2OMatt commented Sep 26, 2017

Hey ;D

I'm a "heavy" user of gitcheck... and I love it ;D

I work on multiple computers everyday - my laptop, my desktop, the company desktop,
and every once in a while, a remote server. Since I'm working at same projects
in all of them I constantly have to push all my changes and pull as well.

So, I run gitcheck --remote --quiet just to discover the repos that
have changed and after that I need go to every repo and push/pull accordingly.
That's sucks a lot... I mean the gitcheck is doing its job great but yet I
need do a lot of manual stuff :/

With that in mind, I implemented a crude --auto-push and --auto-pull flags.
They work like that:

  1. Check if repo has something to pull.
  2. Check if repo has something to push.
  3. If only pull is true - make a pull.
  4. If only push is true - make a push.

Yep, that's it... nothing fancy at this stage. But something interesting can
be worked out... like:

  • try to pull first and if no merge conflicts occurs then push.
  • if a merge conflict happened revert the merge.
  • etc...

I don't know if it's very specific to my work flow, or other ppl might
have similar "issues" with that - and if do you want something like that
in gitcheck at first place.

If it's something that sounds good to you I can refine my work in about 3,4 days
and submit a pull request ;D

Tell me what you think about it!

Cheers and thanks for gitcheck!

@glennular
Copy link
Contributor

I have use a similar set up. I have many repos for a given project and its dependencies, and want to do bulk operation across all of them. Typically a Pull as I manually go through each's changes for commits/push.

I do have a script that does a Pulls each repo, and typically I have to intervene as there are conflicts, or it wont pull due to uncommitted changes.

I think moving forwards with the Pull option would be helpful in both scenarios, just updating all repos and your pull/push one.

As for the Push, personally i would want all or nothing in that transaction. If there is a procedure you see that will check all repos, before pushing, that might make it safer.

@N2OMatt
Copy link
Author

N2OMatt commented Oct 31, 2017

So @badele what do you think about this change? I would love to make a PR!

@N2OMatt N2OMatt closed this as completed Oct 31, 2017
@N2OMatt N2OMatt reopened this Oct 31, 2017
@badele
Copy link
Owner

badele commented Nov 5, 2017

@N2OMatt, I think, that is a good idea. do you think a hook system will not a good solution ? what do you think ?

Sample :
pull-hook
push-hook
etc ..

We can will use a configuration file or param file.

--push-hook=mypush-script

Sample mypush-script

#!/bin/bash

if [ $1 == "projectname" ]; then
 git push origin master
fi

If we use hook solution, i think we can respond for all users imaginations :)

What do you think ?

@N2OMatt
Copy link
Author

N2OMatt commented Nov 9, 2017

@badele I think that's great!
Much more flexible than my proposal ;D

Some quick questions:

  • If the script isn't found is a fatal error or we just report it and continue?
  • If the script itself returns an error, it should be treated as fatal or just report it?
  • Should we provide short flags for those operations? (I think not, but just in case)
  • What arguments we should pass to script? $1 -> projectname $2 ->projectpath $3 -> currbranch?

Any further ideas??

@badele
Copy link
Owner

badele commented Nov 9, 2017

@N2OMatt

If the script isn't found is a fatal error or we just report it and continue?

I think just report (for notify user that this feature exists :) ). Because some users they havent' need this feature

If the script itself returns an error, it should be treated as fatal or just report it?

I think just report and continue

Should we provide short flags for those operations? (I think not, but just in case)

No need flag, the gitcheck script just check if the file exists, this method can be change in the future

What arguments we should pass to script? $1 -> projectname $2 ->projectpath $3 -> currbranch?

I think, just the folder name, the users can call git command from this folder. The imagination of the user will do the rest :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants