They look fine, no contamination with build files. Are you doing an in-tree
build (running cmake at the root of the repository)?
-Ian
On Tue, Jan 21, 2020 at 9:33 AM Jeff Young wrote:
> FWIW, my Git tried to add the two files again (I guess from its local
> history). I think I caught it in
FWIW, my Git tried to add the two files again (I guess from its local history).
I think I caught it in time and cancelled.
I then rebased without the two commits, and without Ian’s commits to remove
them (which were also in my history).
So I think I’m up-to-date now, but if someone could
Perhaps the git commit hook can include a check for file size and
complain if larger than some-arbitrary-threshold?
On Tue, Jan 21, 2020 at 12:43 AM Wayne Stambaugh wrote:
>
> No problem. Hopefully it wont cause too many issues for other devs who
> have to rebase any local changes.
>
> Cheers,
No problem. Hopefully it wont cause too many issues for other devs who
have to rebase any local changes.
Cheers,
Wayne
On 1/20/20 6:15 PM, Jeff Young wrote:
> Thanks, Wayne!
>
> Sorry for causing such a mess.
>
> Cheers,
> Jeff.
>
>
>> On 20 Jan 2020, at 22:32, Wayne Stambaugh wrote:
>>
Thanks, Wayne!
Sorry for causing such a mess.
Cheers,
Jeff.
> On 20 Jan 2020, at 22:32, Wayne Stambaugh wrote:
>
> I found it. I had to create a new protection for the master branch. I
> pushed the changes and enabled the GitLab protection for the master
> branch so we should be good to
I found it. I had to create a new protection for the master branch. I
pushed the changes and enabled the GitLab protection for the master
branch so we should be good to resume normal development. Thank you for
the help and patience to work through this.
Cheers,
Wayne
On 1/20/20 5:27 PM, Nick
It should be there, I am sure you are just confused by the gitlab webui.
It should be something along the lines of:
Settings -> Repository -> Protected branches, click expand. Set the
proper settings in the "Protect a branch" section.
On Mon, 20 Jan 2020 at 23:26, Wayne Stambaugh wrote:
>
>
Well this is a kick in the teeth. I just unprotected it and I don't see
an option to re-enable the protection after I force the changes.
On 1/20/20 5:18 PM, Nick Østergaard wrote:
> There is a "protected branches" section in the settings of the repo.
>
> On Mon, 20 Jan 2020 at 23:18, Nick
There is a "protected branches" section in the settings of the repo.
On Mon, 20 Jan 2020 at 23:18, Nick Østergaard wrote:
>
> You probably need to disable the option to disable force pushing on the repo.
>
> On Mon, 20 Jan 2020 at 23:20, Wayne Stambaugh wrote:
> >
> > GitLab rejected the forced
You probably need to disable the option to disable force pushing on the repo.
On Mon, 20 Jan 2020 at 23:20, Wayne Stambaugh wrote:
>
> GitLab rejected the forced push using this method. Anyone else have any
> ideas. Until we get this resolved, please do not push any commits to
> the master
GitLab rejected the forced push using this method. Anyone else have any
ideas. Until we get this resolved, please do not push any commits to
the master branch.
Thanks,
Wayne
On 1/20/20 5:13 PM, Wayne Stambaugh wrote:
> Please do not push anything to the master branch or perform any merge
>
Please do not push anything to the master branch or perform any merge
requests until I push the rebase the master branch to prevent any commit
losses because forcing a push will wipe out any changes. I ran the git
command suggested by Simon and it seems to have the desired results but
I have no
Hi,
On 17.01.20 19:14, Simon Richter wrote:
> 1. "git rebase -i origin/master"
> 2. in the editor, if they are present, remove the lines
>
> pick ea31730b4 Handle error returns from lstat.
> pick e83420f19 Remove file accidentally commited in ea31730b4
> pick e27e6ee16 Also catch
Hi,
On 17.01.20 20:03, Nhat Khai wrote:
> This is call "refactor" de facto git history for better future :-). It
> that occurred, may as well add git-lfs for large bin files as well- will
> help reduce time for fresh clone too.
No, we're not supposed to have large binary files in that tree --
Hi,
On 17.01.20 18:02, Ian McInerney wrote:
> You can't just use the `git rebase
> master devBranch` command to fix it, since that will go back to the last
> unchanged commit before the binary blobs, then replay all the contents
> of their branch since then onto the current master - which will
On Fri, Jan 17, 2020 at 4:46 PM Nick Østergaard wrote:
> On Fri, 17 Jan 2020 at 17:18, Ian McInerney
> wrote:
> >
> > There are 2 main issues I can see with rebasing:
> > 1) Rebuilding the history will change the commit hashes on master, which
> will throw off our 5.1 cherry-picked commit
On Fri, 17 Jan 2020 at 17:18, Ian McInerney wrote:
>
> There are 2 main issues I can see with rebasing:
> 1) Rebuilding the history will change the commit hashes on master, which will
> throw off our 5.1 cherry-picked commit messages that refer to the master
> commit they came from (there are
There are 2 main issues I can see with rebasing:
1) Rebuilding the history will change the commit hashes on master, which
will throw off our 5.1 cherry-picked commit messages that refer to the
master commit they came from (there are at least 4 that this would happen
to).
2) The GitLab merge
Personally, I think "history is inviolate" doesn't need to apply to things
that were checked in accidentally, and thus will never need to be merged
against, diffed, etc.
On Fri, Jan 17, 2020 at 10:48 AM Simon Richter
wrote:
> Hi Seth,
>
> On Fri, Jan 17, 2020 at 06:53:46AM -0800, Seth Hillbrand
Hi Seth,
On Fri, Jan 17, 2020 at 06:53:46AM -0800, Seth Hillbrand wrote:
> >there are two massive blobs that were accidentally checked in, and
> >checking
> >out the repo requires these to be transferred. Should we make an
> >exception
> >and rebase the tree to remove them from the history?
> I
I think it would be better to just rebase to get rid of that object.
On Fri, 17 Jan 2020 at 16:08, Wayne Stambaugh wrote:
>
> On 1/17/20 9:53 AM, Seth Hillbrand wrote:
> > On 2020-01-17 03:23, Simon Richter wrote:
> >> Hi,
> >>
> >> there are two massive blobs that were accidentally checked in,
On 1/17/20 9:53 AM, Seth Hillbrand wrote:
> On 2020-01-17 03:23, Simon Richter wrote:
>> Hi,
>>
>> there are two massive blobs that were accidentally checked in, and
>> checking
>> out the repo requires these to be transferred. Should we make an
>> exception
>> and rebase the tree to remove them
On 2020-01-17 03:23, Simon Richter wrote:
Hi,
there are two massive blobs that were accidentally checked in, and
checking
out the repo requires these to be transferred. Should we make an
exception
and rebase the tree to remove them from the history?
Simon
I would say no. History is
Hi,
there are two massive blobs that were accidentally checked in, and checking
out the repo requires these to be transferred. Should we make an exception
and rebase the tree to remove them from the history?
Simon
___
Mailing list:
24 matches
Mail list logo
