is that possible to block a push when a repo is tuned to do a pull with rebase

[george...@gmail.com]

Git Extensions have a very useful feature of blocking a push if there are pending commits to pull & I previously issued

>git config branch.master.rebase true
or
>git config branch.autosetuprebase always

In the same situation TortoiseGit simply makes a merge commit, that makes another committers angry, so I have to launch git pull manually before each push.

Is that possible to implement the same functionality in TortoiseGit to get rid of the Git Extensions completely?

-- 

WMBR, George Hazan

[Sven Strickroth]

Hi George,

your mail is missing important information: Which version of TortoiseGit
and Git are you using?

Am 19.12.2016 um 17:11 schrieb george...@gmail.com:
> Git Extensions have a very useful feature of blocking a push if there
> are pending commits to pull & I previously issued
>>git config branch.master.rebase true
> or
>>git config branch.autosetuprebase always

TortoiseGit should support both options. You can also use the "Rebase
after fetch" option in the pull dialog which automatically starts the
rebase dialog.

How does Git extensions know whether there are pending commits?

> Is that possible to implement the same functionality in TortoiseGit to
> get rid of the Git Extensions completely?

I'm not sure whether I understood all details. Can you please try to
explain with more details and maybe an example workflow?

--
Best regards,
Sven Strickroth
PGP key id F5A9D4C4 @ any key-server

[George Hazan]

Hi.

------ Original Message ------
From: "Sven Strickroth" <sv...@cs-ware.de>
To: tortoise...@googlegroups.com
Sent: 19.12.2016 19:28:51
Subject: Re: is that possible to block a push when a repo is tuned to do
a pull with rebase

>Hi George,
>
>your mail is missing important information: Which version of
>TortoiseGit
>and Git are you using?

Latest stable versions of all products:
TortoiseGit 2.3.0 64 bits
GitExtensions 2.48.90 (RC1)
git version 2.8.4.windows.1 64 bits

Windows 10 Pro 64 bits, if it's important.

>Am 19.12.2016 um 17:11 schrieb george...@gmail.com:
>> Git Extensions have a very useful feature of blocking a push if there
>> are pending commits to pull & I previously issued
>>>git config branch.master.rebase true
>> or
>>>git config branch.autosetuprebase always
>
>TortoiseGit should support both options. You can also use the "Rebase
>after fetch" option in the pull dialog which automatically starts the
>rebase dialog.

There are no problems with pull, only with commit.

>
>How does Git extensions know whether there are pending commits?

I don't know :) perhaps it issues a query to the server, requesting the
most recent commit SHA1.

>> Is that possible to implement the same functionality in TortoiseGit
>>to
>> get rid of the Git Extensions completely?
>I'm not sure whether I understood all details. Can you please try to
>explain with more details and maybe an example workflow?

It's easy - when I finish all preparations for push, I click Push (or
Commit-n-Push) in GitExtensions, and receive a modal dialog with text:
"There're pending commits in a repository, do you want to pull it
first?". After clicking Yes GitExtensions performs an usual pull with
rebase, and only then pushes my own commits, thus keeping a repo linear.
TortoiseGit simply makes a push anyway, creating a merge commit if there
were some commits after my HEAD.

[Sven Strickroth]

Hi,

Am 20.12.2016 um 18:00 schrieb George Hazan:
> There are no problems with pull, only with commit.

Why commit is a problem? Commits are always local.

>> I'm not sure whether I understood all details. Can you please try to
>> explain with more details and maybe an example workflow?
> It's easy - when I finish all preparations for push, I click Push (or
> Commit-n-Push) in GitExtensions, and receive a modal dialog with text:
> "There're pending commits in a repository, do you want to pull it
> first?". After clicking Yes GitExtensions performs an usual pull with
> rebase, and only then pushes my own commits, thus keeping a repo linear.
> TortoiseGit simply makes a push anyway, creating a merge commit if there
> were some commits after my HEAD.

This is not correct as push never creates a merge commit. You get an
error which the commit does not fast-forward to the current remote
branch. I think Git Extensions just has a nicer way of handling the
error by directly opening the pull dialog.

In TortoiseGit you get an error dialog where you can start the pull
dialog from the action links button in the lower left. There you should
make sure that "Rebase after fetch" is selected and TortoiseGit runs a
rebase directly after the fetch operation w/o creating a merge commit. -
This can also be automated when you enable in in git config.

[George Hazan]

On Wed, Dec 21, 2016 at 4:42 PM, Sven Strickroth <sv...@cs-ware.de> wrote:

This is not correct as push never creates a merge commit. You get an
error which the commit does not fast-forward to the current remote
branch. I think Git Extensions just has a nicer way of handling the
error by directly opening the pull dialog.

 

No, I don't get an error, everything goes ok unless the commit log that is not linear anymore.

Here's a screenshot in TortoiseGit, you can also observe it in GitHub 

https://farm1.staticflickr.com/676/31807310075_8e5633ede1.jpg

https://github.com/miranda-ng/miranda-ng - that is a repo

In TortoiseGit you get an error dialog where you can start the pull
dialog from the action links button in the lower left.

 

No, TortoiseGit simply commits everything & then pushes. No errors, windows, etc

--

WMBR, George Hazan

[Sven Strickroth]

Am 22.12.2016 um 18:46 schrieb George Hazan:
> This is not correct as push never creates a merge commit. You get an
> error which the commit does not fast-forward to the current remote
> branch. I think Git Extensions just has a nicer way of handling the
> error by directly opening the pull dialog.
>
>
> No, I don't get an error, everything goes ok unless the commit log that
> is not linear anymore.

Exactly that was what I was saying. When the commits are linear push
works, but if not you get an error and have to pull/rebase/merge before
you can push until the commits fast-forward (i.e., are linear).

> In TortoiseGit you get an error dialog where you can start the pull
> dialog from the action links button in the lower left.
>
>
> No, TortoiseGit simply commits everything & then pushes. No errors,
> windows, etc

As I already said: Commits are always local. THe network is only used
when fetching/pulling/pushing. If the log is not linear to use your
words, you get an error and you can then select pull in the lower left
and active "Rebase after fetch" on the pull/fetch dialog.

[George Hazan]

------ Original Message ------
From: "Sven Strickroth" <sv...@cs-ware.de>
To: tortoise...@googlegroups.com
Sent: 23.12.2016 0:51:45
Subject: Re: is that possible to block a push when a repo is tuned to do
a pull with rebase

>Am 22.12.2016 um 18:46 schrieb George Hazan:
>> This is not correct as push never creates a merge commit. You get
>>an
>> error which the commit does not fast-forward to the current
>>remote
>> branch. I think Git Extensions just has a nicer way of handling
>>the
>> error by directly opening the pull dialog.
>>
>> No, I don't get an error, everything goes ok unless the commit log
>>that
>> is not linear anymore.
>Exactly that was what I was saying. When the commits are linear push
>works, but if not you get an error and have to pull/rebase/merge before
>you can push until the commits fast-forward (i.e., are linear).

No :) that's not what you were saying. You constantly mention some
mysterious error that should emerge, but no errors happen. Commits for
the non-freshened repo are always linear, though it doesn't prevent
TortoiseGit from corrupting that linear commits chain.

>> In TortoiseGit you get an error dialog where you can start the
>>pull
>> dialog from the action links button in the lower left.
>>
>> No, TortoiseGit simply commits everything & then pushes. No errors,
>> windows, etc
> As I already said: Commits are always local. THe network is only used
>when fetching/pulling/pushing. If the log is not linear to use your
>words, you get an error and you can then select pull in the lower left
>and active "Rebase after fetch" on the pull/fetch dialog.

This error occurs only in your imagination. In practice any attempt to
push succeedes, but creates parasite merge commits. That's why I still
have to use GitExtensions...

--
WMBR, George Hazan