Re: GitHub desired workflow...

[Eric A. Borisch]

A newer git (2.6.0 [1]) is required for the rebase.autostash configuration
switch to work. As of Xcode 7.2, git is at 2.5.4.

With these two options set to true, (rebase.autostash and pull.rebase),
'git pull' feels like 'svn update' (at least to me) -- which is very nice
for transition documentation to note, with the caveat that you need a
new-enough git installed.

  - Eric

[1]
https://raw.githubusercontent.com/git/git/master/Documentation/RelNotes/2.6.0.txt

On Tue, Nov 1, 2016 at 12:53 PM, Joshua Root  wrote:

> While using the git port is a good idea for many reasons, the
> Xcode-provided git should have autostash since Xcode 5.1 or so.
>
> - Josh
>
> On 2016-11-2 03:40 , Eric A. Borisch wrote:
>
>> As should the fact that, for this to work, you need to be using a
>> new-enough git (like from ports) and not the system-provided one.
>>
>> On Tue, Nov 1, 2016 at 4:01 AM, Marko Käning > > wrote:
>>
>> On 01 Nov 2016, at 01:10 , Brandon Allbery > > wrote:
>>
>> > You can even configure so that becomes the default for "git pull"
>> for that repo.
>> >
>> > git config --local --bool pull.rebase true
>> > git config --local --bool rebase.autoStash true
>>
>> This should go into the wiki page!
>>
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Joshua Root]

While using the git port is a good idea for many reasons, the 
Xcode-provided git should have autostash since Xcode 5.1 or so.


- Josh

On 2016-11-2 03:40 , Eric A. Borisch wrote:

As should the fact that, for this to work, you need to be using a
new-enough git (like from ports) and not the system-provided one.

On Tue, Nov 1, 2016 at 4:01 AM, Marko Käning mailto:mk-macpo...@posteo.net>> wrote:

On 01 Nov 2016, at 01:10 , Brandon Allbery mailto:allber...@gmail.com>> wrote:

> You can even configure so that becomes the default for "git pull" for 
that repo.
>
> git config --local --bool pull.rebase true
> git config --local --bool rebase.autoStash true

This should go into the wiki page!


___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Brandon Allbery]

On Tue, Nov 1, 2016 at 12:40 PM, Eric A. Borisch 
wrote:

> As should the fact that, for this to work, you need to be using a
> new-enough git (like from ports) and not the system-provided one.


I would recommend that anyway, considering that the system one may be
missing things like a moderately critical OS X-specific bug fix with
security implications (a problem with case-insensitive filesystems that can
be used to overwrite normally protected repo hooks).

-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Eric A. Borisch]

As should the fact that, for this to work, you need to be using a
new-enough git (like from ports) and not the system-provided one.

On Tue, Nov 1, 2016 at 4:01 AM, Marko Käning  wrote:

> On 01 Nov 2016, at 01:10 , Brandon Allbery  wrote:
>
> > You can even configure so that becomes the default for "git pull" for
> that repo.
> >
> > git config --local --bool pull.rebase true
> > git config --local --bool rebase.autoStash true
>
> This should go into the wiki page!
>
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Marko Käning]

On 01 Nov 2016, at 01:10 , Brandon Allbery  wrote:

> You can even configure so that becomes the default for "git pull" for that 
> repo.
> 
> git config --local --bool pull.rebase true
> git config --local --bool rebase.autoStash true

This should go into the wiki page!

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Brandon Allbery]

You can even configure so that becomes the default for "git pull" for that
repo.

git config --local --bool pull.rebase true
git config --local --bool rebase.autoStash true


On Mon, Oct 31, 2016 at 7:08 PM, Eric A. Borisch 
wrote:

> I hoped someone would point me to a command like this. Thanks!
>
>   - Eric
>
> On Monday, October 31, 2016, Joshua Root  wrote:
>>
>> I'm using 'git pull --rebase --autostash' which does the stash-before and
>> pop-after automatically.
>>
>> - Josh
>>
>
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
>
>


-- 
brandon s allbery kf8nh   sine nomine associates
allber...@gmail.com  ballb...@sinenomine.net
unix, openafs, kerberos, infrastructure, xmonadhttp://sinenomine.net
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Eric A. Borisch]

I hoped someone would point me to a command like this. Thanks!

  - Eric

On Monday, October 31, 2016, Joshua Root  wrote:
>
> I'm using 'git pull --rebase --autostash' which does the stash-before and
> pop-after automatically.
>
> - Josh
>
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Joshua Root]

On 2016-11-1 09:21 , Lawrence Velázquez wrote:

The only downside of running "portindex" manually
is that you have to pass the location of the ports tree as an argument.


Or cd there first. If you're working on a ports tree you'll often be in 
the right place already.


- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Lawrence Velázquez]

> On Oct 31, 2016, at 5:55 PM, Lawrence Velázquez  wrote:
> 
>> On Oct 31, 2016, at 5:50 PM, Sean Farley  wrote:
>> 
>> I'm not sure I agree with attempting to modify the git repo at all. For
>> example, what if I'm in the middle of bisecting and need to add/remove a
>> port? Why does 'port sync' call at all what the state is?
> 
> Updating the repository is the whole point of "port sync".

That's not to say "port sync" couldn't be smarter about it, obviously.
The Git functionality was implemented in a very straightforward way,
back when just a few people used git-svn or Mac OS Forge's Git mirrors.

But yeah, it's a layer-cake sort of thing. "port selfupdate" updates
base and does a sync. "port sync" updates the ports tree and reindexes.
"portindex"…indexes. The only downside of running "portindex" manually
is that you have to pass the location of the ports tree as an argument.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Sean Farley]

Lawrence Velázquez  writes:

>> On Oct 31, 2016, at 5:50 PM, Sean Farley  wrote:
>> 
>> I'm not sure I agree with attempting to modify the git repo at all. For
>> example, what if I'm in the middle of bisecting and need to add/remove a
>> port? Why does 'port sync' call at all what the state is?
>
> Updating the repository is the whole point of "port sync". If you just
> want to refresh your portindex, you should be running "portindex
> /path/to/ports/tree".

Alrighty then. I'll change my alias.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Joshua Root]

On 2016-11-1 08:46 , Lawrence Velázquez wrote:

On Oct 31, 2016, at 5:01 PM, Eric A. Borisch  wrote:

5) 'push' changes (to macports-ports)

Oh, and and to capture upstream changes, somewhere after 1 and before
5 (4? 3?),

a) git fetch
b) git rebase origin/master
It looks like git pull --rebase does both of those, so that's not too
bad.


That's the idea, although you'll have to do this with a clean working
tree. That means committing or stashing your WIPs.


I'm using 'git pull --rebase --autostash' which does the stash-before 
and pop-after automatically.


- Josh
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Lawrence Velázquez]

> On Oct 31, 2016, at 5:50 PM, Sean Farley  wrote:
> 
> I'm not sure I agree with attempting to modify the git repo at all. For
> example, what if I'm in the middle of bisecting and need to add/remove a
> port? Why does 'port sync' call at all what the state is?

Updating the repository is the whole point of "port sync". If you just
want to refresh your portindex, you should be running "portindex
/path/to/ports/tree".

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Sean Farley]

"Eric A. Borisch"  writes:

> Thanks for all the hard work with this transition! I'm sure once we're all
> "over the hump" we'll look back and wonder why we waited so long.
>
> Just so I'm clear on this, is the desired approach for each committer to:
>
> == setup ==
> 1) clone macports/macports-ports to the local filesystem
> == every change ==
> 2) make changes
> 3) 'add' changes
> 4) 'commit' changes
> 5) 'push' changes (to macports-ports)
>
> Oh, and and to capture upstream changes, somewhere after 1 and before 5 (4?
> 3?),
>
> a) git fetch
> b) git rebase origin/master
> It looks like git pull --rebase does both of those, so that's not too bad.

I've noticed that when I do this and I run 'port sync', macports
apparently tries to rebase? 9 times out of 10 I wind up in a detached
head state.

I'm not sure I agree with attempting to modify the git repo at all. For
example, what if I'm in the middle of bisecting and need to add/remove a
port? Why does 'port sync' call at all what the state is?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Lawrence Velázquez]

> On Oct 31, 2016, at 5:46 PM, Lawrence Velázquez  wrote:
> 
> Ultimately, anything you do before pushing is up to you, as long as
> you don't push any merge commits. We've disabled force-pushing on all
> master branches, so you don't have to worry too much doing that
> accidentally.

That is to say, you don't have to worry about accidentally
force-pushing. You still have to avoid pushing merge commits.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Lawrence Velázquez]

> On Oct 31, 2016, at 5:01 PM, Eric A. Borisch  wrote:
> 
> Just so I'm clear on this, is the desired approach for each committer
> to:
> 
> == setup ==
> 1) clone macports/macports-ports to the local filesystem

After cloning, you should be sure that you are using your MacPorts email
address for commits. It's not the end of the world if you forget, but
the shorter our .mailmap files are, the better.

> == every change ==
> 2) make changes
> 3) 'add' changes
> 4) 'commit' changes

More or less. Ultimately, anything you do before pushing is up to you,
as long as you don't push any merge commits. We've disabled
force-pushing on all master branches, so you don't have to worry too
much doing that accidentally.

> 5) 'push' changes (to macports-ports)
> 
> Oh, and and to capture upstream changes, somewhere after 1 and before
> 5 (4? 3?),
> 
> a) git fetch
> b) git rebase origin/master
> It looks like git pull --rebase does both of those, so that's not too
> bad.

That's the idea, although you'll have to do this with a clean working
tree. That means committing or stashing your WIPs.

vq
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev

Re: GitHub desired workflow...

[Jeremy Lavergne]

You can `pull -r` immediately before pushing. Conveniently, you can
configure pull to autorebase. Either way, the simplest modification to
your last step is this:

git pull -r && git push


On 10/31/2016 05:01 PM, Eric A. Borisch wrote:
> Thanks for all the hard work with this transition! I'm sure once we're
> all "over the hump" we'll look back and wonder why we waited so long.
> 
> Just so I'm clear on this, is the desired approach for each committer to:
> 
> == setup ==
> 1) clone macports/macports-ports to the local filesystem
> == every change ==
> 2) make changes
> 3) 'add' changes
> 4) 'commit' changes
> 5) 'push' changes (to macports-ports)
> 
> Oh, and and to capture upstream changes, somewhere after 1 and before 5
> (4? 3?),
> 
> a) git fetch
> b) git rebase origin/master
> It looks like git pull --rebase does both of those, so that's not too bad.
> 
> If I'm wrong, or if I've missed something, please let me know; there's
> been more discussion than I've had time to follow of late surrounding
> this transition...
> 

___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev