oscarmlage

oscarmlage

Member Since 12 years ago

Lugo, Galicia, Spain

Experience Points
57
follower
Lessons Completed
16
follow
Lessons Completed
21
stars
Best Reply Awards
41
repos

123 contributions in the last year

Pinned
⚡ django-cruds is simple drop-in django app that creates CRUD for faster prototyping
⚡ #BOFHers project
⚡ The easy-to-use and developer-friendly CMS
⚡ Don't be afraid to commit - a workshop/tutorial for inexperienced Python/Django developers who would like to contribute more to the projects they use.
⚡ The sample project layout from the book, "Two Scoops of Django 1.5 and 1.6"
Activity
Jan
13
6 days ago
Activity icon
created branch

oscarmlage in oscarmlage/divergit create branch branch45

createdAt 5 days ago
Activity icon
created branch

oscarmlage in oscarmlage/divergit create branch branch2

createdAt 5 days ago
Activity icon
created branch

oscarmlage in oscarmlage/divergit create branch branch1

createdAt 5 days ago
Activity icon
created branch
createdAt 5 days ago
Activity icon
created repository
createdAt 5 days ago
Activity icon
issue

oscarmlage issue comment jesseduffield/lazygit

oscarmlage
oscarmlage

Diverged multiple branches: push force pushes all

Description

If you have different branches, more than one are diverged from origin and then you try to force push just one of them, lazygit performs a force push to the other branches too. Result: I think not only the branch you selected to force push performs it, but all of them.

To Reproduce

  1. Init a new repo and clone it to your computer (we'll call it local)
  2. Create a couple of branches, let's say we have main, branch1, branch2
  3. Commit and push some stuff from local to origin in main and branch1
  4. Push some stuff to origin from other source in main
  5. Push some stuff to origin from other source in branch1
  6. Without any pull, commit some stuff in branch1 (we're trying to create a divergence in branch1)
  7. On lazygit, with the cursor on branch1, press P to push the changes in local 6.1. Note, need to have the disableForcePushing: false in order to allow you to force pushing 6.2. It says that it performed a git push --force-with-lease in the command log
  8. Note that not only branch1 has been pushed, main has been force pushed too
  9. Result: branch1 is ok, because is the one we wanted to "forcepush" but main is not ok, we lose all the changes we had in the remote.

Expected behavior

In my mind I expected to "forcepush" only the selected branch (branch1), not all of them, but maybe is the way git works (dunno to be honest).

Desktop (please complete the following information):

  • OS: macOS 12.1
  • Lazygit Version 0.31.4
oscarmlage
oscarmlage

Note: This issue is related - in a way - with #1668 where I was asking to disable force push by default because I had this issue. The only doubt I have right now if it's a bug or it is the way git works by default.

Activity icon
issue

oscarmlage issue jesseduffield/lazygit

oscarmlage
oscarmlage

Diverged multiple branches: push force pushes all

Description

If you have different branches, more than one are diverged from origin and then you try to force push just one of them, lazygit performs a force push to the other branches too. Result: I think not only the branch you selected to force push performs it, but all of them.

To Reproduce

  1. Init a new repo and clone it to your computer (we'll call it local)
  2. Create a couple of branches, let's say we have main, branch1, branch2
  3. Commit and push some stuff from local to origin in main and branch1
  4. Push some stuff to origin from other source in main
  5. Push some stuff to origin from other source in branch1
  6. Without any pull, commit some stuff in branch1 (we're trying to create a divergence in branch1)
  7. On lazygit, with the cursor on branch1, press P to push the changes in local 6.1. Note, need to have the disableForcePushing: false in order to allow you to force pushing 6.2. It says that it performed a git push --force-with-lease in the command log
  8. Note that not only branch1 has been pushed, main has been force pushed too
  9. Result: branch1 is ok, because is the one we wanted to "forcepush" but main is not ok, we lose all the changes we had in the remote.

Expected behavior

In my mind I expected to "forcepush" only the selected branch (branch1), not all of them, but maybe is the way git works (dunno to be honest).

Desktop (please complete the following information):

  • OS: macOS 12.1
  • Lazygit Version 0.31.4
Activity icon
issue

oscarmlage issue comment gogs/gogs

oscarmlage
oscarmlage

Smart links to other issues and PRs are not generated anymore (>= 0.12)

Describe the bug

Generation of (smart) links to issues and PRs don't work in versions higher than 0.12.

Gogs version and commit

Tried with 0.12.3 (several instances, different servers) and 0.13.0-dev

It happens also in https://try.gogs.io (see attached screenshots)

Git version

$ git version
git version 2.30.1

Operating system

FreeBSD, Debian

Database

PostgreSQL 11, MySQL 5.5

To Reproduce Steps to reproduce the behavior:

  1. open an issue, in the description write the number of another issue, like #2
  2. click on preview, in the rendered preview, #2 is a link to issue number 2
  3. click save, in the rendered page with the new issue, #2 is not a link to issue number 2

Can you reproduce the bug at https://try.gogs.io?

Yes

https://try.gogs.io/14mroot/testing-issue/issues/2

Expected behavior

Write #{issue} and a link to the issue to be rendered

Actual behavior

Wrote #{issue} and a link to the issue is not rendered

Screenshots

Attached are three screenshots with the described behaviour in try.gogs.io gogs-report-1 gogs-report-2 gogs-report-3

Additional context

Jan
12
1 week ago
Activity icon
issue

oscarmlage issue comment gogs/gogs

oscarmlage
oscarmlage

404 when comparing tags


name: 404 when comparing tags about: The /compare/endpoint balks when comparing tags instead of branch names (offered through the UI)


Describe the bug When viewing a tag the compare button offers to compare the tag to master, e.g. https://try.gogs.io/RobertKosten/example-project/compare/master...tag, which leads to a 404. It works fine when comparing branches, but tags seem to always fail (tried comparing two tags, tags with only [a-z]+).

Gogs version and commit Gogs Version: 0.11.91.0811 Go1.12.7

Git version 1.9.1

Operating system ubuntu 14.04.1

Database mysql 5.5.62-0ubuntu0.14.04.1

To Reproduce Steps to reproduce the behavior:

  1. Go to Repository page
  2. Click on 'Branch:master'
  3. Click on 'Tags'
  4. Click on any {tagname}
  5. Click on green compare button to the left on 'Tree: {tagname}'
  6. See 404

Can you reproduce the bug at https://try.gogs.io? No, because I cannot clone and there seems to be no way to create a tag through the UI.

Expected behavior A comparison between tag and branch/tag/etc. is displayed, just like between branches.

Actual behavior 404

Screenshots Let's no go overboard, no? ;-)

Additional context [TRACE] Template: status/404

oscarmlage
oscarmlage

Dunno if it's something related, but the compare button hardcodes master branch in the generated url even if it doesn't exists. I mean my repo works with main (no master at all), and when trying to compare a fork with the original, the button generates this url:

That url gives a 404. But if I change master by main in the url, as the following, it works perfectly:

I cound'nt find any config option for changing this as default behaviour.

Activity icon
issue

oscarmlage issue comment gogs/gogs

oscarmlage
oscarmlage

(Smart) Links to other issues and PRs are not generated anymore (>= 0.12)

Describe the bug

Generation of (smart) links to issues and PRs don't work in versions higher than 0.12.

Gogs version and commit

Tried with 0.12.3 (several instances, different servers) and 0.13.0-dev

It happens also in https://try.gogs.io (see attached screenshots)

Git version

$ git version
git version 2.30.1

Operating system

FreeBSD, Debian

Database

PostgreSQL 11, MySQL 5.5

To Reproduce Steps to reproduce the behavior:

  1. open an issue, in the description write the number of another issue, like #2
  2. click on preview, in the rendered preview, #2 is a link to issue number 2
  3. click save, in the rendered page with the new issue, #2 is not a link to issue number 2

Can you reproduce the bug at https://try.gogs.io?

Yes

https://try.gogs.io/14mroot/testing-issue/issues/2

Expected behavior

Write #{issue} and a link to the issue to be rendered

Actual behavior

Wrote #{issue} and a link to the issue is not rendered

Screenshots

Attached are three screenshots with the described behaviour in try.gogs.io gogs-report-1 gogs-report-2 gogs-report-3

Additional context

oscarmlage
oscarmlage

Experiencing same issue even in current try.gogs.io:

If I put #2 as reference to the issue n. 2 it's not working, it only works if I write [#2](/issues/2).

Activity icon
issue

oscarmlage issue jesseduffield/lazygit

oscarmlage
oscarmlage

MacOS config.yml PATH in ~/.config

The ~/.config/lazygit/config.yml is not taken into account in MacOS

Tried to add some config stuff to ~/.config/lazygit/config.yml in MacOS but it didn't work out. It worked when the config was added to ~/Library/Application Support/lazygit/config.yml as it says in the docs.

Proposal

Would it be posible to add ~/.config/lazygit/config.yml as a valid path for the config in MacOS too?, taking in account any kind of priority if both are present.

Additional context

I mean, as some other software reads the config from there probably it's more friendly to have the config in ~/.config too, thinking about dealing with dotfiles, put them in a repo, maintaining etc...

Activity icon
issue

oscarmlage issue jesseduffield/lazygit

oscarmlage
oscarmlage

disableForcePushing, true or false by default?

disableForcePushing

I would like to ask this community in general if wouldn't be a better approach just set disableForcePushing as true by default in order to not allow to force pushing instead of do it the other way around?.

Had something like a bad experience with the force pushing banner (something similar to #855), so in my mind it's like something that involves --force is incompatible with the lazy word, that's why I'm asking if the other way around (disable force pushing by default and enable it just in case you know what you're doing) would be more appropriate.

Thanks in advance for your thoughts.

Jan
10
1 week ago
push

oscarmlage push oscarmlage/bofhers

oscarmlage
oscarmlage

Add: Scheduled quote for BOFHers_Gamers too

commit sha: 272e3c992eaa1034e21f6410395137d411cdf933

push time in 1 week ago
Dec
30
2 weeks ago
Previous