This test case would have caught the bug fixed by revision
c23290d5.
It puts various forms of $Id$ into a file in the repository,
without allowing git to collapse them to uniformity. Then enables the
$Id$ expansion on checkout, and checks that what is checked out has
coped with the various forms.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
There's no point in calculating an MD5 if we're not going to use
it. We'll also avoid the possibility of there being a bug in the
Perl MD5 library not being able to handle zero-sized files.
This is a followup to 20b3d206ac,
which allows us to track repositories that do not provide MD5
checksums.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* 'maint' of git://repo.or.cz/git-gui:
git-gui: Guess our share/git-gui/lib path at runtime if possible
Correct key bindings to Control-<foo>
git-gui: Tighten internal pattern match for lib/ directory
Those are builtins. Remove them from PROGRAMS variable
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Recently git-merge learned to avoid generating the diffstat after
a merge by reading the merge.diffstat configuration option. By
default this option is assumed to be true, as that is the old
behavior. However we can force it to false by setting it as a
standard boolean option.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Git has supported remote branch deletion for quite some time, but
I've just never gotten around to supporting it in git-gui. Some
workflows have users push short-term branches to some remote Git
repository, then delete them a few days/weeks later when that topic
has been fully merged into the main trunk. Typically in that style
of workflow the user will want to remove the branches they created.
We now offer a "Delete..." option in the Push menu, right below the
generic "Push..." option. When the user opens our generic delete
dialog they can select a preconfigured remote, or enter a random
URL. We run `git ls-remote $url` to obtain the list of branches and
tags known there, and offer this list in a listbox for the user to
select one or more from.
Like our local branch delete dialog we offer the user a way to filter
their selected branch list down to only those branches that have been
merged into another branch. This is a very common operation as the
user will likely want to select a range of topic branches, but only
delete them if they have been merged into some sort of common trunk.
Unfortunately our remote merge base detection is not nearly as strict
as the local branch version. We only offer remote heads as the test
commit (not any local ones) and we require that all necessary commits
to successfully run git-merge-base are available locally. If one or
more is missing we suggest that the user run a fetch first.
Since the Git remote protocol doesn't let us specify what the tested
commit was when we evaluated our decision to execute the remote delete
there is a race condition here. The user could do a merge test against
the trunk, determine a topic branch was fully merged, but before they
can start pushing the delete request another user could fast-forward
the remote topic branch to a new commit that is not merged into the
trunk. The delete will arrive after, and remove the topic, even though
it was not fully merged.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Git's native command line interface has had branch renaming
support for quite a while, through the -m/-M options to the
git-branch command line tool. This is an extremely useful
feature as users may decide that the name of their current
branch is not an adequate description, or was just entered
incorrectly when it was created.
Even though most people would consider git-branch to be a
Porcelain tool I'm using it here in git-gui as it is the
only code that implements the rather complex set of logic
needed to successfully rename a branch in Git. Currently
that is along the lines of:
*) Backup the ref
*) Backup the reflog
*) Delete the old ref
*) Create the new ref
*) Move the backed up reflog to the new ref
*) Record the rename event in the reflog
*) If the current branch was renamed, update HEAD
*) If HEAD changed, record the rename event in the HEAD reflog
*) Rename the [branch "$name"] section in the config file
Since that is some rather ugly set of functionality to implement
and get right, and some of it isn't easily accessible through the
raw plumbing layer I'm just cheating by relying on the Porcelain.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
The Windows and Mac OS X platforms do not generally use the tearoff
menu feature found on traditional X11 based systems. On Windows the
Tk engine does support the feature, but it really is out of place and
just confuses people who aren't used to working on a UNIX system. On
Mac OS X its not supported for the root menu bar and its submenus, as
it doesn't fit into the overall platform UI model.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If we cannot locate our git-gui library directory, or we find it
but the tclIndex file is not present there (or it is present but
is not something we are allowed to read) the user cannot use the
application. Rather than silently ignoring the errors related to
the tclIndex file being unavailable we report them up front and
display to the user why we cannot start.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
When we are using our "non-optimized" tclIndex format (which is
just a list of filenames, in the order necessary for source'ing)
we are doing all of our loading before we even tested to see if
GITGUI_VERBOSE was set in the environment. This meant we never
showed the files as we sourced them into the environment.
Now we setup our overloaded auto_load and source scripts before
we attempt to define our library path, or source the scripts that
it mentions. This way GITGUI_VERBOSE is always honored if set.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Because we now try to automatically guess the library directory
in certain installations users may wonder where git-gui is getting
its supporting files from. We now display this location in our
About dialog, and we also include the location we are getting our
Git executables from.
Unfortunately users cannot use this 'About git-gui' dialog to
troubleshoot library loading problems; the dialog is defined by
code that exists in the library directory, creating a catch-22.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
In some workflows it is common for a large number of temporary
branches to be created in a remote repository, get fetched to
clients that typically only use git-gui, and then later have
those branches deleted from the remote repository once they have
been fully merged into all destination branches. Users of git-gui
would obviously like to have their local tracking branches cleaned
up for them, otherwise their local tracking branch namespace would
grow out of control.
The best known way to remove these tracking branches is to run
"git remote prune <remotename>". Even though it is more of a
Porcelain command than plumbing I'm invoking it through the UI,
because frankly I don't see a reason to reimplement its ls-remote
output filtering and config file parsing.
A new configuration option (gui.pruneduringfetch) can be used to
automatically enable running "git remote prune <remotename>" after
the fetch of that remote also completes successfully. This is off
by default as it require an additional network connection and is
not very fast on Cygwin if a large number of tracking branches have
been removed (due to the 2 fork+exec calls per branch).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Johannes Sixt asked me to try to avoid embedding the runtime location
of git-gui's library directory in the executable script. Not embedding
it helps the MinGW to be relocatable to another directory should a user
wish to install the programs in a directory other than the location the
packager wanted them to be installed into.
Most of this is a hack. We try to determine if the path of our master
git-gui script will be able to locate the lib by ../share/git-gui/lib.
This should be true if $(gitexecdir) and $(libdir) have the same prefix.
If they do then we defer the assignment of $(libdir) until runtime, and
we get it from $argv0 rather than embedding it into the script itself.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
There is actually nothing left from the original LibXDiff code I used
over 2 years ago, and even the GIT implementation has diverged quite a
bit from LibXDiff's at this point. Let's update the copyright notice
to better reflect that fact.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Martin Koegler noted that create_delta() performs a new hash lookup
after every block copy encoding which are currently limited to 64KB.
In case of larger identical blocks, the next hash lookup would normally
point to the next 64KB block in the reference buffer and multiple block
copy operations will be consecutively encoded.
It is however possible that the reference buffer be sparsely indexed if
hash buckets have been trimmed down in create_delta_index() when hashing
of the reference buffer isn't well balanced. In that case the hash
lookup following a block copy might fail to match anything and the fact
that the reference buffer still matches beyond the previous 64KB block
will be missed.
Let's rework the code so that buffer comparison isn't bounded to 64KB
anymore. The match size should be as large as possible up front and
only then should multiple block copy be encoded to cover it all.
Also, fewer hash lookups will be performed in the end.
According to Martin, this patch should reduce his 92MB pack down to 75MB
with the dataset he has.
Tests performed on the Linux kernel repo show a slightly smaller pack and
a slightly faster repack.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Not every input value passed to get_sha1 is an abbreviated SHA-1.
Its actually quite common for refs to be passed and for those
refs to resolve to full SHA-1s, in which case we may not need to
initialize the alternate object database list in this process.
I'm relocating the call to prepare_alt_odb closer to the code
that actually needs it to maintain the fix first introduced by
Junio in 99a19b43 (to avoid ambiguous SHA-1 abbreviations from
being accepted). This allows us to avoid the alt_odb list setup
if we won't actually need it.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Calling getenv() is not that expensive, but its also not free,
and its certainly not cheaper than testing to see if alt_odb_tail
is not null.
Because we are calling prepare_alt_odb() from within find_sha1_file
every time we cannot find an object file locally we want to skip out
of prepare_alt_odb() as early as possible once we have initialized
our alternate list.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In some repository configurations the user may have many packfiles,
but all of the recent commits/trees/tags/blobs are likely to
be in the most recent packfile (the one with the newest mtime).
It is therefore common to be able to complete an entire operation
by accessing only one packfile, even if there are 25 packfiles
available to the repository.
Rather than opening and mmaping the corresponding .idx file for
every pack found, we now only open and map the .idx when we suspect
there might be an object of interest in there.
Of course we cannot known in advance which packfile contains an
object, so we still need to scan the entire packed_git list to
locate anything. But odds are users want to access objects in the
most recently created packfiles first, and that may be all they
ever need for the current operation.
Junio observed in b867092f that placing recent packfiles before
older ones can slightly improve access times for recent objects,
without degrading it for historical object access.
This change improves upon Junio's observations by trying even harder
to avoid the .idx files that we won't need.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This command can be used to initialize, update and inspect submodules. It
uses a .gitmodules file, readable by git-config, in the top level directory
of the 'superproject' to specify a mapping between submodule paths and
repository url.
Example .gitmodules layout:
[module "git"]
url = git://git.kernel.org/pub/scm/git/git.git
With this entry in .gitmodules (and a commit reference in the index entry for
the path "git"), the command 'git submodule init' will clone the repository
at kernel.org into the directory "git".
Known issues
============
There is currently no way to override the url found in the .gitmodules file,
except by manually creating the subproject repository. The place to fix this
in the script has a rather long comment about a possible plan.
Funny paths will be quoted in the output from git-ls-files, but git-submodule
does not attempt to unquote (or even detect the presence of) such paths.
Signed-off-by: Lars Hjemli <hjemli@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This just basically creates a "pack_refs()" function that could be used by
anybody. You pass it in the flags you want as a bitmask (PACK_REFS_ALL and
PACK_REFS_PRUNE), and it will do all the heavy lifting.
Of course, it's still static, and it's all in the builtin-pack-refs.c
file, so it's not actually visible to the outside, but the next step would
be to just move it all to a library file (probably refs.c) and expose it.
Then we could easily make "git gc" do this too.
While I did it, I also made it check the return value of the fflush and
fsync stage, to make sure that we don't overwrite the old packed-refs file
with something that got truncated due to write errors!
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Fix git-svn to handle svn not reporting the md5sum of a file, and test.
Fix mishandling of $Id$ expanded in the repository copy in convert.c
More echo "$user_message" fixes.
Add tests for the last two fixes.
git-commit: use printf '%s\n' instead of echo on user-supplied strings
git-am: use printf instead of echo on user-supplied strings
Documentation: Add definition of "evil merge" to GIT Glossary
Replace the last 'dircache's by 'index'
Documentation: Clean up links in GIT Glossary
* maint-1.5.1:
Fix git-svn to handle svn not reporting the md5sum of a file, and test.
More echo "$user_message" fixes.
Add tests for the last two fixes.
git-commit: use printf '%s\n' instead of echo on user-supplied strings
git-am: use printf instead of echo on user-supplied strings
Documentation: Add definition of "evil merge" to GIT Glossary
Replace the last 'dircache's by 'index'
Documentation: Clean up links in GIT Glossary
This means that send-pack and http-push will support pattern refspecs,
so builtin-push.c doesn't have to expand them, and also git push can
just turn --tags into "refs/tags/*", further simplifying
builtin-push.c
check_ref_format() gets a third "conditionally okay" result for
something that's valid as a pattern but not as a particular ref.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If the repository contained an expanded ident keyword (i.e. $Id:XXXX$),
then the wrong bytes were discarded, and the Id keyword was not
expanded. The fault was in convert.c:ident_to_worktree().
Previously, when a "$Id:" was found in the repository version,
ident_to_worktree() would search for the next "$" after this, and
discarded everything it found until then. That was done with the loop:
do {
ch = *cp++;
if (ch == '$')
break;
rem--;
} while (rem);
The above loop left cp pointing one character _after_ the final "$"
(because of ch = *cp++). This was different from the non-expanded case,
were cp is left pointing at the "$", and was different from the comment
which stated "discard up to but not including the closing $". This
patch fixes that by making the loop:
do {
ch = *cp;
if (ch == '$')
break;
cp++;
rem--;
} while (rem);
That is, cp is tested _then_ incremented.
This loop exits if it finds a "$" or if it runs out of bytes in the
source. After this loop, if there was no closing "$" the expansion is
skipped, and the outer loop is allowed to continue leaving this
non-keyword as it was. However, when the "$" is found, size is
corrected, before running the expansion:
size -= (cp - src);
This is wrong; size is going to be corrected anyway after the expansion,
so there is no need to do it here. This patch removes that redundant
correction.
To help find this bug, I heavily commented the routine; those comments
are included here as a bonus.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates t4014 to check the two fixes for git-am and git-commit
we observed with "echo" that does backslash interpolation by default
without being asked with -e option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This fixes the same issue git-am had, which was fixed by Jeff
King in the previous commit. Cleverly enough, this commit's log
message is a good test case at the same time.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Under some implementations of echo (such as that provided by
dash), backslash escapes are recognized without any other
options. This means that echo-ing user-supplied strings may
cause any backslash sequences in them to be converted. Using
printf resolves the ambiguity.
This bug can be seen when using git-am to apply a patch
whose subject contains the character sequence "\n"; the
characters are converted to a literal newline. Noticed by
Szekeres Istvan.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that the default delta depth is 50, it is a good idea to also bump
MAX_CHAIN to 50.
While at it, make the display a bit prettier by making the MAX_CHAIN
limit inclusive, and display the number of deltas that are above that
limit at the end instead of the beginning.
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
