Skip to content

Commit

Permalink
Browse files Browse the repository at this point in the history
* https://github.com/prati0100/git-gui:
  git-gui: improve Japanese translation
  git-gui: add a readme
  git-gui: support for diff3 conflict style
  git-gui: use existing interface to query a path's attribute
  git-gui (Windows): use git-bash.exe if it is available
  treewide: correct several "up-to-date" to "up to date"
  Fix build with core.autocrlf=true
  • Loading branch information
gitster committed Nov 4, 2019
2 parents 93bf742 + b524f6b commit ab6b50e
Show file tree
Hide file tree
Showing 4 changed files with 210 additions and 21 deletions.
174 changes: 174 additions & 0 deletions git-gui/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,174 @@
# Git GUI - A graphical user interface for Git

Git GUI allows you to use the [Git source control management
tools](https://git-scm.com/) via a GUI. This includes staging, committing,
adding, pushing, etc. It can also be used as a blame viewer, a tree browser,
and a citool (make exactly one commit before exiting and returning to shell).
More details about Git GUI can be found in its manual page by either running
`man git-gui`, or by visiting the [online manual
page](https://git-scm.com/docs/git-gui).

Git GUI was initially written by Shawn O. Pearce, and is distributed with the
standard Git installation.

# Building and installing

You need to have the following dependencies installed before you begin:

- Git
- Tcl
- Tk
- wish
- Gitk (needed for browsing history)
- msgfmt

Most of Git GUI is written in Tcl, so there is no compilation involved. Still,
some things do need to be done (mostly some substitutions), so you do need to
"build" it.

You can build Git GUI using:

```
make
```

And then install it using:

```
make install
```

You probably need to have root/admin permissions to install.

# Contributing

The project is currently maintained by Pratyush Yadav over at
https://github.com/prati0100/git-gui. Even though the project is hosted at
GitHub, the development does not happen over GitHub Issues and Pull Requests.
Instead, an email based workflow is used. The Git mailing list
[[email protected]](mailto:[email protected]) is where the patches are
discussed and reviewed.

More information about the Git mailing list and instructions to subscribe can
be found [here](https://git.wiki.kernel.org/index.php/GitCommunity).

## Sending your changes

Since the development happens over email, you need to send in your commits in
text format. Commits can be converted to emails via the two tools provided by
Git: `git-send-email` and `git-format-patch`.

You can use `git-format-patch` to generate patches in mbox format from your
commits that can then be sent via email. Let's say you are working on a branch
called 'foo' that was created on top of 'master'. You can run:

```
git format-patch -o output_dir master..foo
```

to convert all the extra commits in 'foo' into a set of patches saved in the
folder `output_dir`.

If you are sending multiple patches, it is recommended to include a cover
letter. A cover letter is an email explaining in brief what the series is
supposed to do. A cover letter template can be generated by passing
`--cover-letter` to `git-format-patch`.

After you send your patches, you might get a review suggesting some changes.
Make those changes, and re-send your patch(es) in reply to the first patch of
your initial version. Also please mention the version of the patch. This can be
done by passing `-v X` to `git-format-patch`, where 'X' is the version number
of the patch(es).

### Using git-send-email

You can use `git-send-email` to send patches generated via `git-format-patch`.
While you can directly send patches via `git-send-email`, it is recommended
that you first use `git-format-patch` to generate the emails, audit them, and
then send them via `git-send-email`.

A pretty good guide to configuring and using `git-send-email` can be found
[here](https://www.freedesktop.org/wiki/Software/PulseAudio/HowToUseGitSendEmail/)

### Using your email client

If your email client supports sending mbox format emails, you can use
`git-format-patch` to get an mbox file for each commit, and then send them. If
there is more than one patch in the series, then all patches after the first
patch (or the cover letter) need to be sent as replies to the first.
`git-send-email` does this by default.

### Using GitGitGadget

Since some people prefer a GitHub pull request based workflow, they can use
[GitGitGadget](https://gitgitgadget.github.io/) to send in patches. The tool
was originally written for sending patches to the Git project, but it now also
supports sending patches for git-gui.

Instructions for using GitGitGadget to send git-gui patches, courtesy of
Johannes Schindelin:

If you don't already have a fork of the [git/git](https://github.com/git/git)
repo, you need to make one. Then clone your fork:

```
git clone https://github.com/<your-username>/git
```

Then add GitGitGadget as a remote:

```
git remote add gitgitgadget https://github.com/gitgitgadget/git
```

Then fetch the git-gui branch:

```
git fetch gitgitgadget git-gui/master
```

Then create a new branch based on git-gui/master:

```
git checkout -b <your-branch-name> git-gui/master
```

Make whatever commits you need to, push them to your fork, and then head over
to https://github.com/gitgitgadget/git/pulls and open a Pull Request targeting
git-gui/master.

GitGitGadget will welcome you with a (hopefully) helpful message.

## Signing off

You need to sign off your commits before sending them to the list. You can do
that by passing the `-s` option to `git-commit`. You can also use the "Sign
Off" option in Git GUI.

A sign-off is a simple 'Signed-off-by: A U Thor \<[email protected]\>' line at
the end of the commit message, after your explanation of the commit.

A sign-off means that you are legally allowed to send the code, and it serves
as a certificate of origin. More information can be found at
[developercertificate.org](https://developercertificate.org/).

## Responding to review comments

It is quite likely your patches will get review comments. Those comments are
sent on the Git mailing list as replies to your patch, and you will usually be
Cc'ed in those replies.

You are expected to respond by either explaining your code further to convince
the reviewer what you are doing is correct, or acknowledge the comments and
re-send the patches with those comments addressed.

Some tips for those not familiar with communication on a mailing list:

- Use only plain text emails. No HTML at all.
- Wrap lines at around 75 characters.
- Do not send attachments. If you do need to send some files, consider using a
hosting service, and paste the link in your email.
- Do not [top post](http://www.idallen.com/topposting.html).
- Always "reply all". Keep all correspondents and the list in Cc. If you reply
directly to a reviewer, and not Cc the list, other people would not be able
to chime in.
15 changes: 13 additions & 2 deletions git-gui/git-gui.sh
Original file line number Diff line number Diff line change
Expand Up @@ -2736,10 +2736,18 @@ if {![is_bare]} {
}
if {[is_Windows]} {
# Use /git-bash.exe if available
set normalized [file normalize $::argv0]
regsub "/mingw../libexec/git-core/git-gui$" \
$normalized "/git-bash.exe" cmdLine
if {$cmdLine != $normalized && [file exists $cmdLine]} {
set cmdLine [list "Git Bash" $cmdLine &]
} else {
set cmdLine [list "Git Bash" bash --login -l &]
}
.mbar.repository add command \
-label [mc "Git Bash"] \
-command {eval exec [auto_execok start] \
[list "Git Bash" bash --login -l &]}
-command {eval exec [auto_execok start] $cmdLine}
}
if {[is_Windows] || ![is_bare]} {
Expand Down Expand Up @@ -3581,6 +3589,9 @@ $ui_diff tag conf d_s- \
$ui_diff tag conf d< \
-foreground orange \
-font font_diffbold
$ui_diff tag conf d| \
-foreground orange \
-font font_diffbold
$ui_diff tag conf d= \
-foreground orange \
-font font_diffbold
Expand Down
33 changes: 18 additions & 15 deletions git-gui/lib/diff.tcl
Original file line number Diff line number Diff line change
Expand Up @@ -270,19 +270,6 @@ proc show_other_diff {path w m cont_info} {
}
}

proc get_conflict_marker_size {path} {
set size 7
catch {
set fd_rc [eval [list git_read check-attr "conflict-marker-size" -- $path]]
set ret [gets $fd_rc line]
close $fd_rc
if {$ret > 0} {
regexp {.*: conflict-marker-size: (\d+)$} $line line size
}
}
return $size
}

proc start_show_diff {cont_info {add_opts {}}} {
global file_states file_lists
global is_3way_diff is_submodule_diff diff_active repo_config
Expand All @@ -298,7 +285,7 @@ proc start_show_diff {cont_info {add_opts {}}} {
set is_submodule_diff 0
set diff_active 1
set current_diff_header {}
set conflict_size [get_conflict_marker_size $path]
set conflict_size [gitattr $path conflict-marker-size 7]

set cmd [list]
if {$w eq $ui_index} {
Expand Down Expand Up @@ -360,6 +347,10 @@ proc start_show_diff {cont_info {add_opts {}}} {
}

set ::current_diff_inheader 1
# Detect pre-image lines of the diff3 conflict-style. They are just
# '++' lines which is not bijective. Thus, we need to maintain a state
# across lines.
set ::conflict_in_pre_image 0
fconfigure $fd \
-blocking 0 \
-encoding [get_path_encoding $path] \
Expand Down Expand Up @@ -462,11 +453,23 @@ proc read_diff {fd conflict_size cont_info} {
{--} {set tags d_--}
{++} {
set regexp [string map [list %conflict_size $conflict_size]\
{^\+\+([<>=]){%conflict_size}(?: |$)}]
{^\+\+([<>=|]){%conflict_size}(?: |$)}]
if {[regexp $regexp $line _g op]} {
set is_conflict_diff 1
set line [string replace $line 0 1 { }]
set tags d$op

# The ||| conflict-marker marks the start of the pre-image.
# All those lines are also prefixed with '++'. Thus we need
# to maintain this state.
set ::conflict_in_pre_image [expr {$op eq {|}}]
} elseif {$::conflict_in_pre_image} {
# This is a pre-image line. It is the one which both sides
# are based on. As it has also the '++' line start, it is
# normally shown as 'added'. Invert this to '--' to make
# it a 'removed' line.
set line [string replace $line 0 1 {--}]
set tags d_--
} else {
set tags d_++
}
Expand Down
9 changes: 5 additions & 4 deletions git-gui/po/ja.po
Original file line number Diff line number Diff line change
Expand Up @@ -4,14 +4,15 @@
#
# しらいし ななこ <[email protected]>, 2007.
# Satoshi Yasushima <[email protected]>, 2016.
# KIDANI Akito <[email protected]>, 2019.
#
msgid ""
msgstr ""
"Project-Id-Version: git-gui\n"
"Report-Msgid-Bugs-To: \n"
"POT-Creation-Date: 2016-05-27 17:52+0900\n"
"PO-Revision-Date: 2016-06-22 12:50+0900\n"
"Last-Translator: Satoshi Yasushima <s.yasushima@gmail.com>\n"
"PO-Revision-Date: 2019-10-13 23:20+0900\n"
"Last-Translator: KIDANI Akito <a.kid.1985@gmail.com>\n"
"Language-Team: Japanese\n"
"Language: ja\n"
"MIME-Version: 1.0\n"
Expand Down Expand Up @@ -661,7 +662,7 @@ msgstr ""
#: lib/merge.tcl:108
#, tcl-format
msgid "%s of %s"
msgstr "%s の %s ブランチ"
msgstr "%2$s の %1$s ブランチ"

#: lib/merge.tcl:122
#, tcl-format
Expand Down Expand Up @@ -956,7 +957,7 @@ msgstr "エラー: コマンドが失敗しました"
#: lib/checkout_op.tcl:85
#, tcl-format
msgid "Fetching %s from %s"
msgstr "%s から %s をフェッチしています"
msgstr "%2$s から %1$s をフェッチしています"

#: lib/checkout_op.tcl:133
#, tcl-format
Expand Down

0 comments on commit ab6b50e

Please sign in to comment.