Merge branch 'master' of git://repo.or.cz/git-gui into maint
* 'master' of git://repo.or.cz/git-gui:
git-gui: Don't crash in citool mode on initial commit.
git-gui: Remove TODO list.
git-gui: Include browser in our usage message.
git-gui: Change summary of git-gui.
git-gui: Display all authors of git-gui.
git-gui: Use mixed path for docs on Cygwin.
git-gui: Correct crash when saving options in blame mode.
git-gui: Expose the browser as a subcommand.
git-gui: Create new branches from a tag.
git-gui: Prefer version file over git-describe.
git-gui: Print version on the console.
git-gui: More consistently display the application name.
git-gui: Permit merging tags into the current branch.
git-gui: Basic version check to ensure git 1.5.0 or later is used.
git-gui: Refactor 'exec git subcmd' idiom.
Not everyone has gzcat or bzcat installed on their system, but
gunzip -c and bunzip2 -c perform the same task and are available
if the user has installed gzip support or bzip2 support.
Signed-off-by: Michael Loeffler <zvpunry@zvpunry.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Don't crash in citool mode on initial commit.
Attempting to use `git citool` to create an initial commit caused
git-gui to crash with a Tcl error as it tried to add the newly
born branch to the non-existant branch menu. Moving this code
to after the normal commit cleanup logic resolves the issue, as
we only have a branch menu if we are not in singlecommit mode.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I'm apparently not very good at keeping my own TODO file current.
I its also somewhat strange to keep the TODO list as part of the
software branch, as its meta-information that is not directly
related to the code. I'm pulling the TODO list from git-gui and
moving it into a seperate branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that git-gui has been released to the public as part of Git 1.5.0
I am starting to see some work from other people beyond myself and
Paul. Consequently the copyright for git-gui is not strictly the
two of us anymore, and these others deserve to have some credit
given to them.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Firefox browser requires that a URL use / to delimit directories.
This is instead of \, as \ gets escaped by the browser into its hex
escape code and then relative URLs are incorrectly resolved, Firefox
no longer sees the directories for what they are. Since we are
handing the browser a true URL, we better use the standard / for
directories.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Check for PRIuMAX rather than NO_C99_FORMAT in fast-import.c.
Thanks to Simon 'corecode' Schubert <corecode@fs.ei.tum.de> for
the clean-up. Defining the C99 standard PRIuMAX when necessary
replaces UM_FMT and the awkward UM10_FMT. There are no direct
C99 translations for other uses of NO_C99_FORMAT in git, alas.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
Define UM_FMT and UM10_FMT and use in place of %ju and %10ju,
respectively. Both format as unsigned long long, so this
assumes the compiler supports long long.
Signed-off-by: Jason Riedy <jason@acm.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Solaris 8 was pre-c99, and they weren't willing to commit to
the strtoumax definition according to /usr/include/inttypes.h.
This adds NO_STRTOUMAX and NO_STRTOULL for ancient systems.
If NO_STRTOUMAX is defined, the routine in compat/strtoumax.c
will be used instead. That routine passes its arguments to
strtoull unless NO_STRTOULL is defined. If NO_STRTOULL, then
the routine uses strtoul (unsigned long).
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Acked-by: Shawn O Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation advertises the new `--depth <n>' parameter with an equal
sign, while the usage notes (shown after `git-clone --help') do not. If I
understood git-clone's source code correctly, the version without the
equal sign is correct, which is why this patch syncs documentation to the
usage note.
Signed-off-by: Christian Schlotter <schlotter@users.sourceforge.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-gui: Correct crash when saving options in blame mode.
Martin Waitz noticed that git-gui crashed while saving the user's
options out if the application was started in blame mode. This
was caused by the do_save_config procedure invoking reshow_diff
incase the number of context lines was modified by the user.
Because we bypassed main window UI setup to enter blame mode we
did not set many of the globals which were accessed by reshow_diff,
and reading unset variables is an error in Tcl.
Aside from moving the globals to be set earlier, I also modified
reshow_diff to not invoke clear_diff if there is no path currently
in the diff viewer. This way reshow_diff does not crash when in
blame mode due to the $ui_diff command not being defined.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* git://git.kernel.org/pub/scm/gitk/gitk:
Make gitk save and restore window pane position on Linux and Cygwin.
Make gitk save and restore the user set window position.
[PATCH] gitk: Use show-ref instead of ls-remote
[PATCH] Make gitk work reasonably well on Cygwin.
[PATCH] gitk - remove trailing whitespace from a few lines.
Change git repo-config to git config
Since `git add` is the approved porcelain for an end-user to invoke
when they want to manipulate the index, porcelain documentation
should steer the user to this command rather than the pure plumbing
update-index.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Attempt to improve git-rebase lead-in description.
It was mentioned on #git this morning that the lead-in description
of git-rebase is very confusing. Too many branch this and branch
that in a very short run of text.
This new description attempts to walk the user through the command
syntax, while also describing exactly what git-rebase is doing to
their repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Do not take mode bits from index after type change.
When we do not trust executable bit from lstat(2), we copied
existing ce_mode bits without checking if the filesystem object
is a regular file (which is the only thing we apply the "trust
executable bit" business) nor if the blob in the index is a
regular file (otherwise, we should do the same as registering a
new regular file, which is to default non-executable).
The 3rd branch in builtin-blame.c should also check for lacking
arguments. Running that in top dir does not trigger the problem
because the 'prefix' is NULL.
Signed-off-by: Tommi Kyntola <tommi.kyntola@ray.fi> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-merge: minor fix for no_trivial_merge_strategies.
The shell loop to determine if we should skip the trivial
in-index merge stage based on what strategy is given was not
prepared to have more than one strategy listed in the variable
$no_trivial_merge_strategies.
This does not trigger unless you use a modified git but the fix
is simple and straightforward, so let's fix it before 1.5.0.1.
Some users may find being able to browse around an arbitrary
branch to be handy, so we now expose our graphical browser
through `git gui browse <committish>`.
Yes, I'm being somewhat lazy and making the user give us
the name of the branch to browse. They can always enter
HEAD.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When somebody else extracts git tarball inside a larger project,
'git describe' would reported the version number of that upper
level project.
Sometimes, using the consistent versioning across subdirectories
of a larger project is useful, but it may not always be the
right thing to do.
This changes the script to check ./vertion file first, and then
fall back to "git describe". This way, by default, tarball
distribution will get our own version. If the upper level wants
to use consistent versioning across its subdirectories, its
Makefile can overwrite ./version file to force whatever version
number they want to give us before descending into us.
Make gitk save and restore window pane position on Linux and Cygwin.
Subtle bugs remained on both Cygwin and Linux that caused the various
window panes to be restored in positions different than where the user
last placed them. Sergey Vlasov posed a pair of suggested fixes to this,
what is done here is slightly different. The basic fix here involves
a) explicitly remembering and restoring the sash positions for the upper
window, and b) using paneconfigure to redundantly set height and width of
other elements. This redundancy is needed as Cygwin Tcl has a nasty habit
of setting pane sizes to zero if their slaves are not configured with a
specific size, but Linux Tcl does not honor the specific size given.
Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Make gitk save and restore the user set window position.
gitk was saving widget sizes and positions when the main window was
destroyed, which is after all child widgets are destroyed. The cure
is to trap the WM_DELETE_WINDOW event before the gui is torn down. Also,
the saved geometry was captured using "winfo geometry .", rather than
"wm geometry ." Under Linux, these two return different answers and the
latter one is correct.
[jc: credit goes to Brett Schwarz for suggesting the use of "wm protocol";
I also squashed the follow-up patch to remove extraneous -0
from expressions.]
Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
It used to be ls-remote on self was the only easy way to grab
the ref information. Now we have show-ref which does not
involve fork and IPC, so use it.
Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
The gitk gui layout was completely broken on Cygwin. If gitk was started
without previous geometry in ~/.gitk, the user could drag the window sashes
to get a useable layout. However, if ~/.gitk existed, this was not possible
at all.
The fix was to rewrite makewindow, changing the toplevel containers and
the particular geometry information saved between sessions. Numerous bugs
in both the Cygwin and the Linux Tk versions make this a delicate
balancing act: the version here works in both but many subtle variants
are competely broken in one or the other environment.
Three user visible changes result:
1 - The viewer is fully functional under Cygwin.
2 - The search bar moves from the bottom to the top of the lower left
pane. This was necessary to get around a layout problem on Cygwin.
3 - The window size and position is saved and restored between sessions.
Again, this is necessary to get around a layout problem on Cygwin.
Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
Clarify two backward incompatible repository options.
It was unclear if the backward compatible features were disabled
or the configuration variables that controls them were set to
false by default from the description. Obviously we meant the
former, but the problem was made worse by the fact that one
configuration variable breaks compatibility when set to true and
the other one breaks it when set to false.
Some distributions are using Git for part of their package
management system, but unpack Git's own source code for
delivery from the .tar.gz. This means that when we walk
up the directory tree with git-describe to locate a Git
repository, the repository we find is for the distribution
and *not* for git-gui. Consequently any tag we might find
there is bogus and does not apply to us.
In this case the version file should always exist and be
readable, as the packager is working from the released
.tar.gz sources. So we should always favor the version
file over anything git-describe guess for us.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Like `git version`, `git gui version` (or `git gui --version`) shows
the version of git-gui, in case the user needs to know this, without
looking at it in the GUI about dialog.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: More consistently display the application name.
I started to find it confusing that git-gui would refer to itself
as git-citool when it was started through the citool hardlink, or
with the citool subcommand. What was especially confusing was the
options dialog and the about dialog, as both seemed to imply they
were somehow different from the git-gui versions. In actuality
there is no difference at all.
Now we just call our options menu item 'Options...' (skipping the
application name) and our About dialog now always shows git-gui
within the short description (above the copyleft notice) and in
the version field.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Permit merging tags into the current branch.
It was pointed out on the git mailing list by Martin Koegler that
we did not show tags as possible things to merge into the current
branch. They actually are, and core Git's Grand Unified Merge
Driver will accept them just like any other commit.
So our merge dialog now requests all refs/heads, refs/remotes and
refs/tags named refs and attempts to match them against the commits
not in HEAD. One complicating factor here is that we must use the
%(*objectname) field when talking about an annotated tag, as they
will not appear in the output of rev-list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Basic version check to ensure git 1.5.0 or later is used.
This is a very crude (but hopefully effective) check against the
`git` executable found in our PATH. Some of the subcommands and
options that git-gui requires to be present to operate were created
during the 1.5.0 development cycle, so 1.5 is the minimum version
of git that we can expect to support.
There actually are early releases of 1.5 (e.g. 1.5.0-rc0) that
don't have everything we expect (like `blame --incremental`) but
these are purely academic at this point. 1.5.0 final was tagged
and released just a few hours ago. The release candidates will
(hopefully) fade into the dark quickly.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
As we frequently need to execute a Git subcommand and obtain
its returned output we are making heavy use of [exec git foo]
to run foo. As I'm concerned about possibly needing to carry
environment data through a shell on Cygwin for at least some
subcommands, I'm migrating all current calls to a new git
proc. This actually makes the code look cleaner too, as
we aren't saying 'exec git' everywhere.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
This also adds a hook in the Makefile I can use to automatically
include pointers to documentation for older releases when updating
the pages at http://kernel.org/pub/software/scm/git/docs/.
Mark places that need blob munging later for CRLF conversion.
Here's a patch that I think we can merge right now. There may be
other places that need this, but this at least points out the
three places that read/write working tree files for git
update-index, checkout and diff respectively. That should cover
a lot of it [jc: git-apply uses an entirely different codepath
both for reading and writing].
Some day we can actually implement it. In the meantime, this
points out a place for people to start. We *can* even start with
a really simple "we do CRLF conversion automatically, regardless
of filename" kind of approach, that just look at the data (all
three cases have the _full_ file data already in memory) and
says "ok, this is text, so let's convert to/from DOS format
directly".
THAT somebody can write in ten minutes, and it would already
make git much nicer on a DOS/Windows platform, I suspect.
And it would be totally zero-cost if you just make it a config
option (but please make it dynamic with the _default_ just being
0/1 depending on whether it's UNIX/Windows, just so that UNIX
people can _test_ it easily).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
"git-fetch --tags $URL" should not overwrite existing tags
Use the same --exclude-existing filter as we use for automatic
tag following to avoid overwriting existing tags with replacement
ones the other side created.
Some of the git-svn tests can fail on fast machines due to a race in
Subversion: if a file is modified in the same second it was checked out
(or in for that matter), Subversion will not consider it modified. This
works around the problem by increasing the timestamp by one second
before each commit.
[jc: with "touch -r -d" replacement from Eric]
Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Michael Spang <mspang@uwaterloo.ca> Signed-off-by: Junio C Hamano <junkio@cox.net>
Make gitk save and restore window pane position on Linux and Cygwin.
Subtle bugs remained on both Cygwin and Linux that caused the various
window panes to be restored in positions different than where the user
last placed them. Sergey Vlasov posed a pair of suggested fixes to this,
what is done here is slightly different. The basic fix here involves
a) explicitly remembering and restoring the sash positions for the upper
window, and b) using paneconfigure to redundantly set height and width of
other elements. This redundancy is needed as Cygwin Tcl has a nasty habit
of setting pane sizes to zero if their slaves are not configured with a
specific size, but Linux Tcl does not honor the specific size given.
Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
I'm exporting gitexecdir because git-gui wants to know where
it should install git-gui and git-citool. These belong under
gitexecdir, just like git-diff, as the git wrapper is able to
invoke these commands for the end-user.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'master' of git://repo.or.cz/git-gui:
git-gui: Change base version to 0.6.
git-gui: Guess our version accurately as a subproject.
git-gui: Handle gitgui tags in version gen.
git-gui: Generate a version file on demand.
git-gui: Rename GIT_VERSION to GITGUI_VERSION.
git-gui: Allow gitexecdir, INSTALL to be set by the caller.
This is the start of the 0.6 series of git-gui. I'm calling it 0.6
(rather than any other value) as I already had a private tag on
one system based on 0.5, and that tag is quite a bit behind this
version.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Guess our version accurately as a subproject.
When we are included as a subproject, such as how git.git carries
us, we want to retain our own version number and not the version
number assigned by git.git's own tags. Consequently we need to
locate the correct tag which applies to our tree content and
its commit lineage.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
I've decided to use gitgui-0.5 as the format for tags in the
git-gui repository. The prefix of gitgui was chosen here to
make its namespace different from the namespace used by git
itself, allowing developers to pull both tag namespaces into
the same repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because git-gui is being shipped as a subproject of the main
Git project and will often have a different lifecycle than
the main Git project, we should ship our own version number
in the release tarball rather than relying on the main Git
version file.
Git's master Makefile will invoke our own with the target
dist-version, asking us to save off our GITGUI_VERSION value
into our own version file, so that our GIT-VERSION-GEN script
can recover it at build time.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that the decision has been made to treat git-gui as a
subproject, rather than merging it directly into git, we
should use a different substitution for our version value
to avoid any possible confusion.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
git-gui: Allow gitexecdir, INSTALL to be set by the caller.
When used as a subproject within git.git our Makefile must honor
the gitexecdir which git.git's Makefile is passing down to us,
ensuring that we install our executables into the libexec chosen
by the end-user or packager.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
fast-import: Support reusing 'from' and brown paper bag fix reset.
It was suggested on the mailing list that being able to use `from`
in any commit to reset the current branch is useful in some types of
importers, such as a darcs importer.
We originally did not permit resetting an existing branch with a
new `from` command during a `commit` command, but this restriction
was only to help debug the hacked up cvs2svn that Jon Smirl was
developing in parallel with git-fast-import. It is probably more
of a problem to disallow it than to allow it. So now we permit a
`from` during any `commit`.
While making the changes required to permit multiple `from`
commands on the same branch, I discovered we no longer needed the
last_commit field to be set to 0 during a reset, so that was removed.
(Reset was originally setting the field to 0 to signal cmd_from()
that it was OK to execute on the branch.)
While poking around in this section of fast-import I also realized
the `reset` command was not working as intended if the corresponding
`from` command was omitted (as allowed by the BNF grammar and the
code). If `from` was omitted we cleared out the tree but we left
the tree SHA-1 and parent commit SHA-1 intact. This is not what
the user intended in this case. Instead they would be trying to
reset the branch to have no parent and to have no tree, making the
branch look new-born during the next commit. We now clear these
SHA-1 values during `reset`, ensuring the branch looks new-born if
`from` does not get supplied.
New test cases for these were also added.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Merge branch 'master' of git://repo.or.cz/git/fastimport
* 'master' of git://repo.or.cz/git/fastimport:
bash: Hide git-fast-import.
fast-import: Add tip about importing renames.
fast-import: Hide the pack boundary commits by default.
The new git-fast-import command is not intended to be invoked
directly by an end user. So offering it as a possible completion
for a subcommand is not very useful.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
fast-import: Hide the pack boundary commits by default.
Most users don't need the pack boundary information that fast-import
was printing to standard output, especially if they were calling
it with --quiet.
Those users who do want this information probably want it captured
so they can go back and use it to repack the imported repository.
So dumping the boundary commits to a log file makes more sense then
printing them to standard output.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Now that git 1.5.0 and later contains a version of gitk that uses
correct geometry on Windows platforms, even if ~/.gitk exists, we
should not delete the user's ~/.gitk to work around the bug. It
is downright mean to remove a user's preferences for another app.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Make gitk save and restore the user set window position.
gitk was saving widget sizes and positions when the main window was
destroyed, which is after all child widgets are destroyed. The cure
is to trap the WM_DELETE_WINDOW event before the gui is torn down. Also,
the saved geometry was captured using "winfo geometry .", rather than
"wm geometry ." Under Linux, these two return different answers and the
latter one is correct.
[jc: credit goes to Brett Schwarz for suggesting the use of "wm protocol";
I also squashed the follow-up patch to remove extraneous -0
from expressions.]
Signed-off-by: Mark Levedahl <mdl123@verizon.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Some of the short help texts that are shown e.g. when running 'git'
without any parameters wrap on a 80-column terminal. They are just
one character over the line. This patch avoids it by decreasing the
number of spaces around the preceding command name from four to
three (on both sides for symmetry).
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <junkio@cox.net>