git-cvsserver is analogous to git-receive-pack; a checking from a cvs
client to a central server is like a git-push from a working repository.
Therefore it's nice to use the same access control (and email sending)
that a receive-pack would perform.
This patch tests for an executable update hook; if it is it is run with
the ref being updated and the old and new hashes as normal. If the
update hook returns an error code the update is aborted and the ref is
never updated. The cvsserver returns "error 1" to the client to signal
there was an EPERM error.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Instead of running around listing the changes near the release,
let's keep things nicely organized by summarizing the changes as
we merge things to the 'master' branch.
I haven't decided how well this will go with people's patch
submission procedure yet --- we'll play it by the ear and see
what happens.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
* maint:
Makefile: update check-docs target
cmd-list: add git-remote
Documentation: Drop full-stop from git-fast-import title.
Minor corrections to release notes
Old aliases are not linked to the main command list. Also the internal
git-add--interactive does not need to be on the list.
Signed-off-by: Junio C Hamano <junkio@cox.net>
`git diff --ignore-space-at-eol` will ignore whitespace at the
line ends.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If you were issuing emails for two branches, and one merged the other,
you would get the same log messages appearing in two separate emails.
e.g. A working repository, where the last push to central was done at
the revision marked "B", after which two branches were developed
further.
* -- B -- 1 -- 1 -- M (branch1)
\ /
2 -- 2 -- 2 (branch2)
Now imagine that branch2 is pushed to the email-generating repository;
an email containing all the "2" revisions would be sent. Now, let's say
branch1 is pushed, the old update hook would run
git-rev-list $newrev ^$baserev
Where $newrev would be "M" and $baserev would be "B". This list
includes all the "2" revisions as well as all the "1" revisions.
This patch addresses this problem by using
git-rev-parse --not --all | git-rev-list --stdin $newrev ^$baserev
To inhibit the display of all revisions that are already in the
repository.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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>
Update section about warning when leaving a detached head.
Also fix a few indentations that weren't like the rest of the file.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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/.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The documentation still talked about the unnecessary 'safety'
in git-checkout.
Pointed out by Matthias Lederhofer.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
In a repository with a large number of refs, the following command line
could easily overflow the command line size limitations
git-rev-list $newref $(git-rev-parse --not --all)
Fortunately, git-rev-list already has the means to cope with this
situation with the --stdin switch
git-rev-parse --not --all | git-rev-list --stdin $newref
Which is exactly what this patch does.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The config variable gc.packrefs is tristate now: "true", "false"
and "notbare", where "notbare" is the default.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Similar to commit eb8381c8, we need to use for_each_reflog() to make
sure we do not miss objects reachable from HEAD reflog.
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
The old text suggested that git-update-server-info only needs to be run
if new tags or branches are created, but not for new commits.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Also spawn the the new blameview in the background
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
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>
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>
Andy Parkins