git-svnimport: Don't assume that copied files haven't changed
Don't assume that a file that SVN claims was copied from somewhere
else is bit-for-bit identical with its parent, since SVN allows
changes to copied files before they are committed.
Without this fix, such copy-modify-commit operations causes the
imported file to lack the "modify" part -- that is, we get subtle data
corruption.
Signed-off-by: Karl Hasselström <kha@treskal.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Jens Axboe noticed that recent "git push" has become very slow
since we made --thin transfer the default.
Thin pack generation to push a handful revisions that touch
relatively small number of paths out of huge tree was stupid; it
registered _everything_ from the excluded revisions. As a
result, "Counting objects" phase was unnecessarily expensive.
This changes the logic to register the blobs and trees from
excluded revisions only for paths we are actually going to send
to the other end.
Recent revision.c updates completely broken the assignment of
blames by not rewriting commit->parents field unless explicitly
asked to by the caller. The caller needs to set revs.parents.
* jc/date:
date parsing: be friendlier to our European friends.
Tweaks to make asciidoc play nice.
git-commit: document --amend
Avoid a crash if realloc returns a different pointer.
Avoid a divide by zero if there's no messages to send.
[PATCH] Provide configurable UI font for gitk
[PATCH] gitk: Use git wrapper to run git-ls-remote.
[PATCH] gitk: add key bindings for selecting first and last commit
gitk: Add a help menu item to display key bindings
[PATCH] gitk: allow goto heads
gitk: replace parent and children arrays with lists
date parsing: be friendlier to our European friends.
This does three things, only applies to cases where the user
manually tries to override the author/commit time by environment
variables, with non-ISO, non-2822 format date-string:
- Refuses to use the interpretation to put the date in the
future; recent kernel history has a commit made with
10/03/2006 which is recorded as October 3rd.
- Adds '.' as the possible year-month-date separator. We
learned from our European friends on the #git channel that
dd.mm.yyyy is the norm there.
- When the separator is '.', we prefer dd.mm.yyyy over
mm.dd.yyyy; otherwise mm/dd/yy[yy] takes precedence over
dd/mm/yy[yy].
* git://git.kernel.org/pub/scm/gitk/gitk:
[PATCH] Provide configurable UI font for gitk
[PATCH] gitk: Use git wrapper to run git-ls-remote.
[PATCH] gitk: add key bindings for selecting first and last commit
gitk: Add a help menu item to display key bindings
[PATCH] gitk: allow goto heads
gitk: replace parent and children arrays with lists
This command removes untracked files from the working tree. This
implementation is based on cg-clean with some simplifications. The
documentation is included.
[jc: with trivial documentation fix, noticed by Jakub Narebski]
Signed-off-by: Pavel Roskin <proski@gnu.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
If git is not built with NO_EXPAT, this patch changes git-http-fetch to
attempt using DAV to get a list of remote packs and fall back to using
objects/info/packs if the DAV request fails.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes the font used in the UI elements of gitk configurable in the
same way the other fonts are. The default fonts used in the Xft build of
tk8.5 are particularily horrific, making this change more important
there.
Signed-off-by: Keith Packard <keithp@neko.keithp.com> Acked-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
[PATCH] gitk: Use git wrapper to run git-ls-remote.
For some reason, the Cygwin Tcl's `exec' command has trouble running
scripts. Fix this by using the C `git' wrapper. Other GIT programs run
by gitk are written in C already, so we don't need to incur a
performance hit of going via the wrapper (which I'll bet isn't pretty
under Cygwin).
Signed-off-by: Mark Wooding <mdw@distorted.org.uk> Acked-by: Junio C Hamano <junkio@cox.net> Signed-off-by: Paul Mackerras <paulus@samba.org>
[PATCH] gitk: add key bindings for selecting first and last commit
For a keyboard addict like me some keys are still missing from
gitk. Especially a key to select a commit when no commit is selected,
like just after startup. While we're at it, complete the bindings for
moving the view seperately from the selected line. Currently, the up
and down keys act on the selected line while pageup and pagedown act
on the commits viewed.
The idea is to have to normal keys change the selected line:
- Home selects first commit
- End selects last commit
- Up selects previous commit
- Down selects next commit
- PageUp moves selected line one page up
- PageDown moves selected line one page down
...and together with the Control key, it moves the commits view:
- Control-Home views first page of commits
- Control-End views last page of commits
- Control-Up moves commit view one line up
- Control-Down moves commit view one line down
- Control-PageUp moves commit view one page up
- Control-PageDown moves commit view one page down
Signed-off-By: Rutger Nijlunsing <gitk@tux.tmfweb.nl>
and with some cleanups and simplifications... Signed-off-by: Paul Mackerras <paulus@samba.org>
This simplifies code, and also fixes a subtle bug: when importing in a
shared repository, where another user last imported from CVS, cvsimport
used to complain that it could not open <branch> for update.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/combine:
combine-diff: use built-in xdiff.
GIT 1.3.0-rc2
Set HTTP user agent to git/GIT_VERSION
git-ls-remote: send no-cache header when fetching info/refs
Bunch of cleanups with a few notable enhancements since
1.3.0-rc1:
- revision traversal infrastructure is updated so that
existence of paths limiters and/or --max-age does not cause
it to call limit_list(). This helps the latency working with
the command quite a bit.
- comes with updated gitk.
One notable fix is to make sure that the IO is restarted upon
signal even on platforms whose default signal semantics is not
to do so. This is the fix for the notorious "clone is broken
since 1.2.2 on Solaris" problem.
git-diff-* --pickaxe-regex will change the -S pickaxe to match
POSIX extended regular expressions instead of fixed strings.
The regex.h library is a rather stupid interface and I like pcre too, but
with any luck it will be everywhere we will want to run Git on, it being
POSIX.2 and all. I'm not sure if we can expect platforms like AIX to
conform to POSIX.2 or if win32 has regex.h. We might add a flag to
Makefile if there is a portability trouble potential.
* lt/fix-sol-pack:
Use sigaction and SA_RESTART in read-tree.c; add option in Makefile.
safe_fgets() - even more anal fgets()
pack-objects: be incredibly anal about stdio semantics
Fix Solaris stdio signal handling stupidities
Use blob_, commit_, tag_, and tree_type throughout.
This replaces occurences of "blob", "commit", "tag", and "tree",
where they're really used as type specifiers, which we already
have defined global constants for.
Signed-off-by: Peter Eriksen <s022018@student.dtu.dk> Signed-off-by: Junio C Hamano <junkio@cox.net>
Use sigaction and SA_RESTART in read-tree.c; add option in Makefile.
Might as well ape the sigaction change in read-tree.c to avoid
the same potential problems. The fprintf status output will
be overwritten in a second, so don't bother guarding it. Do
move the fputc after disabling SIGALRM to ensure we go to the
next line, though.
Also add a NO_SA_RESTART option in the Makefile in case someone
doesn't have SA_RESTART but does restart (maybe older HP/UX?).
We want the builder to chose this specifically in case the
system both lacks SA_RESTART and does not restart stdio calls;
a compat #define in git-compat-utils.h would silently allow
broken systems.
Signed-off-by: Jason Riedy <ejr@cs.berkeley.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/clone:
git-clone: fix handling of upsteram whose HEAD does not point at master.
fix repacking with lots of tags
Documentation: revise top of git man page
git-clone: fix handling of upsteram whose HEAD does not point at
When cloning from a remote repository that has master, main, and
origin branches _and_ with the HEAD pointing at main branch, we
did quite confused things during clone. So this cleans things
up. The behaviour is a bit different between separate remotes/
layout and the mixed branches layout.
The newer layout with $GIT_DIR/refs/remotes/$origin/, things are
simpler and more transparent:
- remote branches are copied to refs/remotes/$origin/.
- HEAD points at the branch with the same name as the remote
HEAD points at, and starts at where the remote HEAD points at.
- $GIT_DIR/remotes/$origin file is set up to fetch all remote
branches, and merge the branch HEAD pointed at at the time of
the cloning.
Everything-in-refs/heads layout was the more confused one, but
cleaned up like this:
- remote branches are copied to refs/heads, but the branch
"$origin" is not copied, instead a copy of the branch the
remote HEAD points at is created there.
- HEAD points at the branch with the same name as the remote
HEAD points at, and starts at where the remote HEAD points at.
- $GIT_DIR/remotes/$origin file is set up to fetch all remote
branches except "$origin", and merge the branch HEAD pointed
at at the time of the cloning.
With this, the remote has master, main and origin, and its HEAD
points at main, you could:
git clone $URL --origin upstream
to use refs/heads/upstream as the tracking branch for remote
"main", and your primary working branch will also be "main".
"master" and "origin" are used to track the corresponding remote
branches and with this setup they do not have any special meaning.
I'm afraid I'll be accused of trying to suck all the jokes and the
personality out of the git documentation. I'm not! Really!
That said, "man git" is one of the first things a new user is likely try,
and it seems a little cruel to start off with a somewhat obscure joke
about the architecture of git.
So instead I'm trying for a relatively straightforward description of what
git does, and what features distinguish it from other systems, together
with immediate links to introductory documentation.
I also did some minor reorganization in an attempt to clarify the
classification of commands. And revised a bit for conciseness (as is
obvious from the diffstat--hopefully I didn't cut anything important).
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu> Signed-off-by: Junio C Hamano <junkio@cox.net>
pack-objects: be incredibly anal about stdio semantics
This is the "letter of the law" version of using fgets() properly in the
face of incredibly broken stdio implementations. We can work around the
Solaris breakage with SA_RESTART, but in case anybody else is ever that
stupid, here's the "safe" (read: "insanely anal") way to use fgets.
It probably goes without saying that I'm not terribly impressed by
Solaris libc.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
contrib/git-svn/git-svn.txt:
added git-repo-config key names for options
fixed quoting of "git-svn-HEAD" in the manpage
use preformatted text for examples
contrib/git-svn/Makefile:
add target to generate HTML:
http://git-svn.yhbt.net/git-svn.html
Signed-off-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
revision: Fix --topo-order and --max-age with reachability limiting.
What ends up not working very well at all is the combination of
"--topo-order" and the output filter in get_revision. It will
return NULL when we see the first commit out of date-order, even
if we have other commits coming.
So we really should do the "past the date order" thing in
get_revision() only if we have _not_ done it already in
limit_list().
Something like this.
The easiest way to test this is with just
gitk --since=3.days.ago
on the kernel tree. Without this patch, it tends to be pretty obviously
broken.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
This makes git-rev-list able to do path-limiting without having to parse
all of history before it starts showing the results.
This makes things like "git log -- pathname" much more pleasant to use.
This is actually a pretty small patch, and the biggest part of it is
purely cleanups (turning the "goto next" statements into "continue"), but
it's conceptually a lot bigger than it looks.
What it does is that if you do a path-limited revision list, and you do
_not_ ask for pseudo-parenthood information, it won't do all the
path-limiting up-front, but instead do it incrementally in
"get_revision()".
This is an absolutely huge deal for anything like "git log -- <pathname>",
but also for some things that we don't do yet - like the "find where
things changed" logic I've described elsewhere, where we want to find the
previous revision that changed a file.
The reason I put "RFC" in the subject line is that while I've validated it
various ways, like doing
git-rev-list HEAD -- drivers/char/ | md5sum
before-and-after on the kernel archive, it's "git-rev-list" after all. In
other words, it's that really really subtle and complex central piece of
software. So while I think this is important and should go in asap, I also
think it should get lots of testing and eyeballs looking at the code.
Btw, don't even bother testing this with the git archive. git itself is so
small that parsing the whole revision history for it takes about a second
even with path limiting. The thing that _really_ shows this off is doing
git log drivers/
on the kernel archive, or even better, on the _historic_ kernel archive.
With this change, the response is instantaneous (although seeking to the
end of the result will obviously take as long as it ever did). Before this
change, the command would think about the result for tens of seconds - or
even minutes, in the case of the bigger old kernel archive - before
starting to output the results.
NOTE NOTE NOTE! Using path limiting with things like "gitk", which uses
the "--parents" flag to actually generate a pseudo-history of the
resulting commits won't actually see the improvement in interactivity,
since that forces git-rev-list to do the whole-history thing after all.
MAYBE we can fix that too at some point, but I won't promise anything.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Move "--parent" parsing into generic revision.c library code
Not only do we do it in both rev-list.c and git.c, the revision walking
code will soon want to know whether we should rewrite parenthood
information or not.
Signed-off-by: Linus Torvalds <torvalds@osdl.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Indeed, we can see that gitk shows these two commits at the
bottom, because the --boundary code failed to output them.
The code did not check to avoid pushing the same uninteresting
commit twice to the result list. I am not sure why this fixes
the reported problem, but this seems to fix it.
* git://git.kernel.org/pub/scm/gitk/gitk:
gitk: Better workaround for arrows on diagonal line segments
gitk: Allow top panes to scroll horizontally with mouse button 2
gitk: Prevent parent link from overwriting commit headline
gitk: Show diffs for boundary commits
gitk: Use the new --boundary flag to git-rev-list
gitk: Better workaround for arrows on diagonal line segments
Instead of adding extra padding to create a vertical line segment at
the lower end of a line that has an arrow, this now just draws a very
short vertical line segment at the lower end. This alternative
workaround for the Tk8.4 behaviour (not drawing arrows on diagonal
line segments) doesn't have the problem of making the graph very wide
when people do a lot of merges in a row (hi Junio :).
Make git-clone to take long double-dashed origin option (--origin)
git-clone currently take option '-o' to specify origin. this patch
makes git-clone to take double-dashed option '--origin' and other
abbreviations in addtion to the current single-dashed option.
[jc: with minor fixups]
Signed-off-by: Yasushi SHOJI <yashi@atmark-techno.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
gitk: Prevent parent link from overwriting commit headline
When I made drawlineseg responsible for drawing the link to the first
child rather than drawparentlinks, that meant that the right-most X
value computed by drawparentlinks didn't include those first-child
links, and thus the first-child link could go over the top of the
commit headline. This fixes it.
With this we run git-diff-tree on a commit even if we think it has
no parents, either because it really has no parents or because it
is a boundary commit. This means that gitk shows the diff for a
boundary commit when it is selected.
Introduce tree-walk.[ch] and move "struct tree_desc" and
associated functions from various places.
Rename DIFF_FILE_CANON_MODE(mode) macro to canon_mode(mode) and
move it to cache.h. This macro returns the canonicalized
st_mode value in the host byte order for files, symlinks and
directories -- to be compared with a tree_desc entry.
create_ce_mode(mode) in cache.h is similar but is intended to be
used for index entries (so it does not work for directories) and
returns the value in the network byte order.
When the executable bit is untrustworthy and when we are
comparing the tree with the working tree, we tried to reuse the
mode bits recorded in the index incorrectly (the computation was
bogus on little endian architectures). Just use mode from index
when it is a regular file.
With this, we can show the boundary (open-circle) commits immediately
after their last child, which looks much better than putting all the
boundary commits at the bottom of the graph.