murmele / gittyup Goto Github PK

This new Double Tree View of the file staging section may look a little cleaner to some than the one showcased in GitAhead, but I wouldn't really call it a complete upgrade. Some features available in the previous version have disappeared (stage/unstage multiple files at once by ctrl/shift - clicking then right click to bring the menu up, discard changes in this same menu...), and the new separation between staged and unstaged files makes it harder to simply toggle one staged then unstaged (which is sometimes necessary when you staged a file too soon)

The times this gets a little polishing, could we please get the previous file Double Tree view back, at least as an option ?

Inputting queries yield wildly varying results when they shouldn't

In the last I noticed that sometimes GittyUp add changes out of nothing to the staged commits, I wasn't able even to see them in the staged block. Here's the three latest examples:

• Droid-ify: Problematic commit its fix
• OABX: Problematic commit its fix
• OABX: Problematic commit its fix

It's also good to mention that I wasn't able to reproduce it intentionally…

• Check if all dependencies must be installed. Because to create a pkgbuild for arch the dependencies should not be needed.

At the moment ignoring files is only implemented for the TreeView, but not for the double TreeView

This label shall be removed. Maybe it was forgotten to remove
TODO: check out, whats the reason why it was there

Any time the program attempts to open a local repository that contains a "typechange", the program crashes with a segmentation fault.

Upon opening the repository:

Dictionaries dir:  QDir( "/usr/lib/gittyup/Resources/dictionaries" , nameFilters = { "*" },  QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( Dirs|Files|Drives|AllEntries ) )
Dictionaries dir:  QDir( "/usr/lib/gittyup/Resources/dictionaries" , nameFilters = { "*" },  QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( Dirs|Files|Drives|AllEntries ) )
Lexers dir:  QDir( "/usr/lib/gittyup/Resources/lexers" , nameFilters = { "*" },  QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( Dirs|Files|Drives|AllEntries ) )
Plugins dir:  QDir( "/usr/lib/gittyup/Resources/plugins" , nameFilters = { "*" },  QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( Dirs|Files|Drives|AllEntries ) )
Lexers dir:  QDir( "/usr/lib/gittyup/Resources/lexers" , nameFilters = { "*" },  QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( Dirs|Files|Drives|AllEntries ) )
Name:  "Unstaged" Current Collapsed:  32742 ; New Collapsed:  0
Name:  "Staged" Current Collapsed:  32742 ; New Collapsed:  0
Name:  "Unstaged" Current Collapsed:  0 ; New Collapsed:  0
Name:  "Staged" Current Collapsed:  0 ; New Collapsed:  0
Lexers dir:  QDir( "/usr/lib/gittyup/Resources/lexers" , nameFilters = { "*" },  QDir::SortFlags( Name | IgnoreCase ) , QDir::Filters( Dirs|Files|Drives|AllEntries ) )
Segmentation fault (core dumped)

In my case, a typechange is caused when I delete a file and replace it with a symlink.

The git status output:

$ git status
On branch master
Your branch is up to date with 'origin/master'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
	typechange: net6.csproj
	modified:   test.net6.csproj

no changes added to commit (use "git add" and/or "git commit -a")

This happens consistently anytime a typechange is present, and does not seem to matter if other changes are present in the repo or not.

This is certainly an edge case, and probably isn't triggered very often by anyone (aside from myself).

System info:
Arch Linux x64
5.16.16-arch1-1
gcc version: 11.2.0-3
Compiled from source, via the AUR
On current commit as of March 4th

If there's any additional info/tests you need, I'm happy to help.

With many recent opened repositories it is difficult to find a specific one easily without a searchbox.

Frequently, while selecting files by pressing the spacebar in the Unstaged Files window, the program crashes with:

Segmentation fault (core dumped)

More messages:

Diff Header:
"@@ -1,7 +1,7 @@\n"
Staged Header:
"@@ -1,7 +1,7 @@\n"
Patch lines: 8
0 )  "Origin:  ; OldLine: 1; NewLine: 1"
1 )  "Origin:  ; OldLine: 2; NewLine: 2"
2 )  "Origin:  ; OldLine: 3; NewLine: 3"
3 )  "Origin: -; OldLine: 4; NewLine: "
4 )  "Origin: +; OldLine: ; NewLine: 4"
5 )  "Origin:  ; OldLine: 5; NewLine: 5"
6 )  "Origin:  ; OldLine: 6; NewLine: 6"
7 )  "Origin:  ; OldLine: 7; NewLine: 7"
Staged linesStaged: 1
Staged patch No.  0
0 )  "Origin:  ; OldLine: 1; NewLine: 1"
1 )  "Origin:  ; OldLine: 2; NewLine: 2"
2 )  "Origin:  ; OldLine: 3; NewLine: 3"
3 )  "Origin: -; OldLine: 4; NewLine: "
4 )  "Origin: +; OldLine: ; NewLine: 4"
5 )  "Origin:  ; OldLine: 5; NewLine: 5"
6 )  "Origin:  ; OldLine: 6; NewLine: 6"
7 )  "Origin:  ; OldLine: 7; NewLine: 7"
Name:  "Staged"  Row:  0 :  "Services" ; Count:  1
Name:  "Staged" , countCollapsed(): 1
Name:  "Staged" Current Collapsed:  1 ; New Collapsed:  1
Segmentation fault (core dumped)

Steps to reproduce:

1. Open program
2. Open a repo with sidebar or "Open Repository" with one or more unstaged files.
3. With the "Unstaged Files" window focused, press spacebar to select a file.
4. Roughly 20% of the time, this will result in the program closing with a segmentation fault.

System info:
Arch Linux x64
5.16.11-arch1-1
gcc version: 11.2.0-3
Compiled from source, via the AUR
On current commit as of March 4th

If there's any additional info/tests you need, I'm happy to help.

Reproduce:

• Start gittyup
• Click the 'Add Github account'
• Enter username
• Enter personal access token or password
  Result:
  
• Click OK
  Result: Crash
  Segmentation fault (core dumped)

Gittyup 1.0.0 (d52896f)
Compiled via the AUR package gittyup-git

It would be great to have a prebuilt version for Apple Silicon.

Same for Windows/Linux on ARM once those gain more traction.

Sometimes there are files in ignored locations you don't want to track changes of, but still want to commit once. git add -f is here to take care of that

An option to explicitly add an ignored file from the GUI would be, I think, a nice addition. I'd imagine it as a small "plus" icon near the file staging section that would display a file choosing dialog to select one

In my opinion, the pane to see the diff is too small to have a comfortable view, here is a screenshot how it currently looks on my screen:

Resizing of the pane doesn't really help as it would make the list of commits uncomfortable small.

I think a view having the tree on top of the diff view would be more comfortable. I think about a design looking like something like this:

The view with staged / unstaged files could be left-to-right (diff-view and commit message in the next image is just copied from above, the content doesn't make sense in this context, the graphics is only to give an impression regarding the staged/unstaged files):

After logging in with a 2FA-enabled GitHub or GitLab account by username / personal access token, Gittyup successfully gets the repository list and can access the repositories. However, when attempting to make changes to the remote, i.e. pushing a new commit to the repository, I am prompted to login again.

It would be nice / efficient if there was an option for Gittyup to remember the credentials so that users are not prompted before every remote action such as a push to master.

Note: I tried this with GitHub and GitLab PATs, not sure if it happens with regular Username / Password login

I am trying the new version and it works great with a test repo. Unfortunately I am having issues with staging and commiting for some of my production repos (which work with cli git and old gitahead).

I can stage by clicking on the checkbox next to the file, but not unstage single files. The only way to unstage is to click the "Unstage all" button.

Commiting then results in an error

Unable to commit - failed to insert entry: invalid object specified - ScriptComponent 

It's a repo for a React project and it is fairly big. My system is Manjaro linux with Gnome and Wayland.

git-lfs track returns output such as (Unreal Engine example):

Listing tracked patterns
    Content/** (.gitattributes)
    *.uasset (.gitattributes)
    *.umap (.gitattributes)
Listing excluded patterns

Because of the logic in QStringList Repository::lfsTracked() in src/git/Repository.cpp, Gittyup currently appends an extra (incorrect) line to the list of tracked items, called “Listing”.

A 1.0.0 release was just tagged, there there was already a 1.0.0 tag from last year and indeed a 1.0.1 tag as well. That version is already packaged downstream in some distros as 1.0.0.

I suggest re-releasing and bumping the version to 1.1.0 or something like that to avoid perpetual confusion and mixups.

It'd be extremely helpful to have GPG-signing support, to verify uploads.

Currently using Manjaro with plasma 5.23.3, frameworks 5.88, Qt 5.15.2 and the kernel 5.14.18 on X11. I installed the flatpak version of Gittyup but there's no menu on the global menu at all, for some reason is not being exported. I already checked and it works correctly if:

• i install Gittyup form the AUR using gittyup-git.
• On flatpak version of Gittyup if i remove the global menu from the plasma panel and stop the daemon that exports the menus, then it appears again inside of the window.

Also i already confirmed that this problem doesn't happen with the flatpak version of GitAhead, it works correctly there so this most likely is a regression related to a change done after the fork.

Steps to reproduce:

1. Set up plasma's global menu on a panel so the menus are exported.
2. Install the flatpak version of Gittyup.
3. Run Gittyup, there will not be any way to access the menu because it doesn't appear.

See #114

hi, where can i get the stable binary release? the readme says the prerelease is available, but what's the stance on stable releases?

thanks (:

Hi,

I just made the jump from GitAhead to Gittyup (and to Qt 5.15 !) ; it is so nice seeing this software taking a new life !

The new filelist/diff/blame interface seems promising but currently it appears to have a bug : initially, no file/folder is selected, which means that no diff gets displayed at all. I can click on the topmost folder to see the while diff of a commit, but it will unselect when I switch to a commit that applies to a different folder. It is also not easy to show the whole diff if the commit impacts several subfolders of the repo (see screen capture).

I think a simple way to solve this would be to have the filelist have an element for the root of the repo, containing everything, and having that element activated by default.

Just discovered Gitahead today and disregarded it due to development no longer being carried out and then found gittyup awesome!

Wondered if there's any prospect of supporting Gitea? Regardless on the feasibility of this, thanks for this fork and for working on it.

See initial work in commit c207df5 and one below

Currently all GitLab instances share the same icon.
It can be a pretty normal thing for some users to use multiple GitLab instances, which are annoying to differentiate in Gittyup.
I would suggest that we look at the GitLab instance URLs and choose a more appropriate icon if available.
For example, I am on GitLab, on the KDE Gitlab instance, on the Gnome GitLab instance, on the Debian GitLab instance, and on the Alpine Linux GitLab instance.
We could either grab their favicons, or add logic for Gittyup for looking if icons are available, and then we could manually add them.
All of the instances that I checked actually have slightly or even very oversized favicons, so they would be an option even on high-dpi displays.

I thought it would help to have a little todo list for things that eventually need to be done for the gitahead for.

• Fix up the master branch
• Decide on a new name (obviously we could use a boring placeholder)
  On on our Matrix channel, we decided to use the name Gittyup for now
• Update README.md to inform people about the situation (why there is a fork)
  WIP see https://github.com/Murmele/gitahead/pull/3
• Come up with a new logo (obviously we could use a boring placeholder)
• Replace GitAhead logo with new logo
• Further update README.md to get rid of all the original GitAhead links, email-addresses, etc.
  WIP see https://github.com/Murmele/gitahead/pull/3
• Figure out how to do releases (maybe we can split the burden by platform (I have been taking care of the Linux AppImages for Vircadia releases, and would be up for doing that here as well.))

Error message from pipeline: error: static_assert failed due to requirement '__is_cpp17_move_insertable<std::__1::allocatorScintilla::FontAlias, false>::value' "The specified type does not meet the requirements of Cpp17MoveInsertable"
static_assert(__is_cpp17_move_insertable<allocator_type>::value,

After clone with --depth n and open with Gittyup, there is no git commit log at all.
The gitk or other tools can show the shallow repo correctly.

At the moment git-lfs is not supported in the flatpak package. I tried to get it into the manifest, but it did not work yet:
https://github.com/flathub/com.github.Murmele.Gittyup/tree/work/git-lfs

Hello,
I still have GitAhead (currently Version 2.6.3) and I am thinking about moving to GittyUp.
Just wanted to make sure, that a major issue that I have with GitAhead is not also one here.

At least in my installation ion MS Windows 10 with WSL, GitAhead uses an extra index which resides in the folder
.git/GitAhead/index.

As I sometimes use cli git for some actions that work better with that and some actions especially conflict solving with a GUI frontend,
it is quite annoying that they are not using the same staging index.

Is there and Option in GittyUp to at least make it use the standard git index?
I would like a GUI frontend to just behave as a frontend to standard git, not have its own repository management.
In case this issue still exists, could you kindly suggest a different frontend?
Thank you for your time and trouble.

Best regards

Philip.

The context menu in the right-side file-list (staging and commit view) should contain all options that exist in the context menu of the diff view's file header

I've attached a screenshot to show the issue. The menu bar isn't themed at all, despise my selecting Dark. For now, I've decided to use the System theme, and it works well for me. See below for screenshot. (I dislike embedding without being able to use a spoiler wrapped around.)

Broken Dark Theme

Amending a commit in Git enables a developer to modify commit message, but can do much more. It can also alter author date, creator...

An advanced dialog to change those attributes would be, I think, a nice addition. It would be just a matter of displaying the dialog on triggering the "Amend commit" option. That'd be also a welcome break from the current behavior of the GUI which seems to be just cancelling the commit, therefore incorrect since this is what "Reset" is intended for

A quick Issues search revealed the mostly-complete removal of telemetry-related stuff, but the Flatpak version (“1.0.0, Mon, Jan 3, 2022”) has a disabled (but ticked) checkbox for Usage Reporting with a Privacy Policy.

GittyUp seems to overwrite the author of the commits when cherry-picked.

This is not the usual behaviour of git. It would be great to either have git's cherry-pick default behaviour or at least an option to disable the obverwritting.

And thanks for taking over GitAhead, I'm really liking the direction this project is taking.

In the DiffTreemodel a nullptr is passed as callback. If an error occurs during update of the submodule. It will be tried to call this callback to notify the ui that an error occured.
The application crashes then

commit id: 1d37893

From the GUI we can see file changes at a specific commit, but we can't view the whole file from it while git show allows that

An option to view the file content at a specific commit instead of current content, which is the current behavior, would be a nice addition. Perhaps by modifying the existing file viewing feature and changing Gittyup opened editor's behavior to view content read only (in that case why not replace the pen logo with an eye to convey the idea we're just looking)

This is a bit of a Flatpak issue regarding trusted certificate stores. I run my own CA trusted by everything in Linux, but Flatpak apps never trust the CA because it uses its own store. Perhaps an option to trust Linux instead would be handy for people who host their own stuff!

The ability to sign-off on commits would be very much appreciated. Fetch from .gitconfig:

[format] signOff = true

I find it a bit difficult to navigate between organizational repos and personal repos in the Remote list. Perhaps subcategorizing them by Organization might be quite handy.

I notice the flatpak version uses a *.desktop, but a regular ninja install doesn't? Should this all be polluting /usr/local like it is or did I miss a step?

Hi

Very happy to see GL continued, it'd be nice to have it available on the snapstore.

Thanks in advance
J

It may be only me, but it happens that I have many repositories whose root folder name is the same

Being able to set a name of a project repository only for Gittyup could be, I think, a nice small addition

gitahead/gitahead#583 is still happening.

I recently added a new remote to a repository and Gittyup gives the aforementioned error when pulling or pushing to it when the corresponding ssh key has not already been added to the ssh agent. However if the key is loaded in the agent, everything runs fine.

Other repos do not exhibit this behaviour (I had problems with Gittyup not dealing with ssh keys properly in the past but these had gone), including some of them that use the exact same ssh key. Invoking git pull from the command line correctly gives a prompt for the password of the private key. ~/.ssh/config explicitly states which key is to be used.

The URL for the remote is of the form git+ssh://user@server:nonstandardport/path/to/.git (the remotes of the other repos are not, so this might be the reason).

OS : KUbuntu 20.04 with gnome-keyring as agent.
Gittyup : release version of master from yesterday.

Is it possible to use the Qt theme set by the user (I'm using KDE Plasma)? I haven't done much with Qt but I think Gittyup uses bundled Qt since fcitx5 also doesn't work.

There has been a problem with SSH connectivity on Windows 10 since version 1903. Libssh2-1.10.0 solves that problem.

The current version of Gittyup still references version 1.9.0. Could you please update the references submodule version for libssh2 to libssh2-1.10.0?

Hi,
I'm not sure if I use the history search of Gittyup correctly but if I try to find all commits, that altered a specific file, the search result only contains commits with one parent. e.g. commits with multiple parents like merge commits are not listed.

Is it possible to find those commits just like if I use "git log --simplify-merges" or "git log --first-parent"?