search

prati0100 / git-gui

Tcl/Tk based UI for Git. I am currently acting as the project's maintainer.
160 stars 87 forks source link

Add screenshots to the README #97

Closed ottok closed 9 months ago

ottok commented 1 year ago

The README is written in Markdown which supports images. Having a couple of screenshots in the README (and thus on the project page on Github) would help new users immediately understand the value of git-gui.

The screenshots are chosen to illustrate some of the main features.

The images are scaled down and compressed with optipng -v -o7 *.png to ensure they don't waste space despite being binary files.

I know this project prefers submissions via email, but since this is a visual submission, I decided to use Github PR.

You can preview the rendered Markdown at https://github.com/ottok/git-gui/tree/docs-screenshots

ottok commented 1 year ago

@prati0100 Could you please review/merge this PR? Thanks!

ottok commented 1 year ago

Yes it is kind of separate at git://ozlabs.org/~paulus/gitk but it has now website nor any releases or distribution of its own. It is distributed only here in git-gui.

rimrul commented 1 year ago

It is distributed only here in git-gui.

It is not distributed here either. It is distributed in git.git.

PhilipOakley commented 1 year ago

It is distributed only here in git-gui.

s/git-gui/git's gui/ maybe?

Open source can be confusing ;-)

prati0100 commented 9 months ago

Hi @ottok

Thanks for the pull request. I am happy to apply this but the commit is missing your Signed-off-by. If you reply with Signed-off-by: Otto Kekäläinen <otto@kekalainen.net> in this comment chain (or update your commit by adding it), I will pick it up.

ottok commented 9 months ago

Updated as requested and rebased on latest master.

prati0100 commented 9 months ago

Applied in 3f851e2. Thanks.

ottok commented 9 months ago

Why did you close my Github PR instead of using 'merge'? What was wrong in the PR?

According to Github stats, I have now not contributed to your project..

prati0100 commented 9 months ago

I am used to taking contributions via email and have my workflow set up to deal with patches. So for GitHub pull requests, I just convert the PR into a patch via this link and apply it and push. I see that GitHub recognizes your email and does associate it with your username. For example, the commit shows up when I list all contributions by @ottok here. So I wonder why GitHub does not also show this in your contributions.

I don't see an option to "mark as merged" a PR so I'm afraid there isn't much else I can do here. Sorry, I did not think anyone cared too much about this.

ottok commented 9 months ago

For reference, this was modified and merged as 8eb648199561612b0855ae05bc4288db92d92953.

Sure, you can download a patch (just as if it was sent to you by email) and merge it outside of GitHub, and push, and GitHub will mark the PR as automatically closed. However in your workflow you now edit the commit by amending the commit message, so the sha sum will not match anymore, commit ID will be different and GitHub will not understand that what you merged and was in the https://github.com/prati0100/git-gui/pull/97.patch as the same thing anymore.

I recommend you stop amending the git commit with your signoff, as the commit message will anyway show you as the committer. I don't see any benefit of having you marked as signoff AND committer in each commit.

image

PhilipOakley commented 9 months ago

@ottok I believe that within the Git project, as with the Linux project, the patch route is preferred, so that the Maintainer can do that sign off as an explicit step in the verification process.

The Github PR on-line, centralised, process came later. It has it's strengths (ease of use for the many), and it's limitations - the maintainer DCO aspect isn't explicitly 'signed'. The same issue will happen when the update feeds into the Git upstream with a sign-off by Junio of the pull of the updates.

ottok commented 5 months ago

The same issue will happen when the update feeds into the Git upstream with a sign-off by Junio of the pull of the updates.

That is actually not true. If you look at https://github.com/git/git/commit/b85c5a4ec66f18fdaa550fdf7801f48ebbc4292f it is the exact same commit as https://github.com/prati0100/git-gui/commit/b85c5a4ec66f18fdaa550fdf7801f48ebbc4292f. When commits from this project flow to the main git repository, merges are signed-off but original commits honored.

The way GitHub PRs are made is actually pretty smart and they do honor git principles. If you download the patch as https://github.com/prati0100/git-gui/pull/97.patch and apply it with git am and push on mainline, GitHub will see the commit id is the same despite Committer changed, and GitHub will close the pull request automatically and mark it merged.

The part of your workflow is that you add an extra Signed-off in addition to updating yourself as Committer, which results in the commit id being changed.

Side note: upstream has extra commits on top of git-gui. If you want to sync, you could git am the commit https://github.com/git/git/commit/62b4f7b9c6a767cfa9eb3efa96e65305f98386be.patch (but don't change it, otherwise git merge might not detect it is the same commit that is already merged when next time git-gui merges on git).