John Keeping [Fri, 5 Apr 2013 16:12:08 +0000 (17:12 +0100)]
submodule: print graph output next to submodule log
When running "git log -p --submodule=log", the submodule log is not
indented by the graph output, although all other lines are. Fix this by
prepending the current line prefix to each line of the submodule log.
Signed-off-by: John Keeping <redacted> Signed-off-by: Junio C Hamano <redacted>
John Keeping [Fri, 5 Apr 2013 12:19:14 +0000 (13:19 +0100)]
diff: allow unstuck arguments with --diff-algorithm
The argument to --diff-algorithm is mandatory, so there is no reason to
require the argument to be stuck to the option with '='. Change this
for consistency with other Git commands.
Note that this does not change the handling of diff-algorithm in
merge-recursive.c since the primary interface to that is via the -X
option to 'git merge' where the unstuck form does not make sense.
Signed-off-by: John Keeping <redacted> Signed-off-by: Junio C Hamano <redacted>
John Keeping [Fri, 5 Apr 2013 11:37:30 +0000 (12:37 +0100)]
git-merge(1): document diff-algorithm option to merge-recursive
Commit 07924d4 (diff: Introduce --diff-algorithm command line option
2013-01-16) added diff-algorithm as a parameter to the recursive merge
strategy but did not document it. Do so.
Signed-off-by: John Keeping <redacted> Signed-off-by: Junio C Hamano <redacted>
Junio C Hamano [Fri, 5 Apr 2013 15:19:41 +0000 (08:19 -0700)]
glossary: extend "detached HEAD" description
When we introduced the concept of "detached HEAD", we made sure that
commands that operate on the history of the current branch "just
work" in that state. They update the HEAD to point at the new
history without affecting any branch when the HEAD is detached, just
like they update the tip of the "current branch" to point at the new
history when HEAD points at a specific branch.
As this is done as the natural extension for these commands, we did
not, we still do not, and we do not want to repeat "A detached HEAD
is updated without affecting any branch" when describing what each
and every one of these commands that operates "on the current branch"
does.
Add a blanket description to the glossary to cover them instead.
The general principle is that operations to update the branch work
on and affect the HEAD, while operations to update the information
about a branch do not.
Thomas Rast [Fri, 5 Apr 2013 14:34:48 +0000 (16:34 +0200)]
log -L: fix overlapping input ranges
The existing code was too defensive, and would trigger the assert in
range_set_append() if the user gave overlapping ranges.
The intent was always to define overlapping ranges as just the union
of all of them, as evidenced by the call to sort_and_merge_range_set().
(Which was already used, unlike what the comment said.)
Fix by splitting out the meat of range_set_append() to a new _unsafe()
function that lacks the paranoia. sort_and_merge_range_set will fix
up the ranges, so we don't need the checks there.
Signed-off-by: Thomas Rast <redacted> Signed-off-by: Junio C Hamano <redacted>
Thomas Rast [Fri, 5 Apr 2013 14:34:47 +0000 (16:34 +0200)]
log -L: check range set invariants when we look it up
lookup_line_range() is a good place to check that the range sets
satisfy the invariants: they have been computed and set in earlier
iterations, and we now start working with them.
Signed-off-by: Thomas Rast <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Fri, 5 Apr 2013 05:28:10 +0000 (01:28 -0400)]
diffcore-pickaxe: unify code for log -S/-G
The logic flow of has_changes() used for "log -S" and diff_grep()
used for "log -G" are essentially the same. See if we have both
sides that could be different in any interesting way, slurp the
contents in core, possibly after applying textconv, inspect the
contents, clean-up and report the result. The only difference
between the two is how "inspect" step works.
Unify this codeflow in a helper, pickaxe_match(), which takes a
callback function that implements the specific "inspect" step.
After removing the common scaffolding code from the existing
has_changes() and diff_grep(), they each becomes such a callback
function suitable for passing to pickaxe_match().
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Junio C Hamano [Fri, 5 Apr 2013 04:03:21 +0000 (21:03 -0700)]
diffcore-pickaxe: fix leaks in "log -S<block>" and "log -G<pattern>"
The diff_grep() and has_changes() functions had early return
codepaths for unmerged filepairs, which simply returned 0. When we
taught textconv filter to them, one was ignored and continued to
return early without freeing the result filtered by textconv, and
the other had a failed attempt to fix, which allowed the planned
return value 0 to be overwritten by a bogus call to contains().
Junio C Hamano [Fri, 5 Apr 2013 03:40:31 +0000 (20:40 -0700)]
diffcore-pickaxe: port optimization from has_changes() to diff_grep()
These two functions are called in the same codeflow to implement
"log -S<block>" and "log -G<pattern>", respectively, but the latter
lacked two obvious optimizations the former implemented, namely:
- When a pickaxe limit is not given at all, they should return
without wasting any cycle;
- When both sides of the filepair are the same, and the same
textconv conversion apply to them, return early, as there will be
no interesting differences between the two anyway.
Also release the filespec data once the processing is done (this is
not about leaking memory--it is about releasing data we finished
looking at as early as possible).
Simon Ruderich [Fri, 5 Apr 2013 13:16:30 +0000 (15:16 +0200)]
diffcore-pickaxe: respect --no-textconv
git log -S doesn't respect --no-textconv:
$ echo '*.txt diff=wrong' > .gitattributes
$ git -c diff.wrong.textconv='xxx' log --no-textconv -Sfoo
error: cannot run xxx: No such file or directory
fatal: unable to read files to diff
Reported-by: Matthieu Moy <redacted> Signed-off-by: Simon Ruderich <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Fri, 5 Apr 2013 00:00:09 +0000 (20:00 -0400)]
t3600: document failure of rm across symbolic links
If we have a symlink "d" that points to a directory, we
should not be able to remove "d/f". In the normal case,
where "d/f" does not exist in the index, we already disallow
this, as we only remove things that git knows about in the
index. So for something like:
we will properly produce an error (as there is no index
entry for foo/bar). However, if there is an index entry for
the path (e.g., because the movement is due to working tree
changes that have not yet been reflected in the index), we
will happily delete it, even though the path we delete from the
filesystem is not the same as the path in the index.
This patch documents that failure with a test.
While this is a bug, it should not be possible to cause
serious data loss with it. For any path that does not have
an index entry, we will complain and bail. For a path which
does have an index entry, we will do the usual up-to-date
content check. So even if the deleted path in the filesystem
is not the same as the one we are removing from the index,
we do know that they at least have the same content, and
that the content is included in HEAD.
That means the worst case is not the accidental loss of
content, but rather confusion by the user when a copy of a
file another part of the tree is removed. Which makes this
bug a minor and hard-to-trigger annoyance rather than a
data-loss bug (and hence the fix can be saved for a rainy
day when somebody feels like working on it).
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Fri, 5 Apr 2013 00:08:47 +0000 (20:08 -0400)]
diffcore-pickaxe: remove fill_one()
fill_one is _almost_ identical to just calling fill_textconv; the
exception is that for the !DIFF_FILE_VALID case, fill_textconv gives us
an empty buffer rather than a NULL one. Since we currently use the NULL
pointer as a signal that the file is not present on one side of the
diff, we must now switch to using DIFF_FILE_VALID to make the same
check.
Signed-off-by: Jeff King <redacted> Signed-off-by: Simon Ruderich <redacted> Signed-off-by: Junio C Hamano <redacted>
Simon Ruderich [Thu, 4 Apr 2013 20:20:29 +0000 (22:20 +0200)]
diffcore-pickaxe: remove unnecessary call to get_textconv()
The fill_one() function is responsible for finding and filling the
textconv filter as necessary, and is called by diff_grep() function
that implements "git log -G<pattern>".
The has_changes() function that implements "git log -S<block>" calls
get_textconv() for two sides being compared, before it checks to see
if it was asked to perform the pickaxe limiting. Move the code
around to avoid this wastage.
After has_changes() calls get_textconv() to obtain textconv for both
sides, fill_one() is called to use them.
By adding get_textconv() to diff_grep() and relieving fill_one() of
responsibility to find the textconv filter, we can avoid calling
get_textconv() twice in has_changes().
With this change it's also no longer necessary for fill_one() to
modify the textconv argument, therefore pass a pointer instead of a
pointer to a pointer.
Signed-off-by: Simon Ruderich <redacted> Signed-off-by: Junio C Hamano <redacted>
Thomas Rast [Thu, 4 Apr 2013 20:41:42 +0000 (22:41 +0200)]
t9700: do not close STDERR
Much like the previous patch, this triggered an unrelated bug.
Closing STDERR is not worth it anyway, as we risk writing die() and
such to random files that happen to be subsequently opened on FD 2.
Don't do it.
Signed-off-by: Thomas Rast <redacted> Reviewed-by: Jonathan Nieder <redacted> Signed-off-by: Junio C Hamano <redacted>
Thomas Rast [Thu, 4 Apr 2013 20:41:41 +0000 (22:41 +0200)]
perl: redirect stderr to /dev/null instead of closing
On my system, t9100.1 triggers the following warning:
==352== Syscall param write(buf) points to uninitialised byte(s)
==352== at 0x57119C0: __write_nocancel (in /lib64/libc-2.17.so)
==352== by 0x56AC1D2: _IO_file_write@@GLIBC_2.2.5 (in /lib64/libc-2.17.so)
==352== by 0x56AC0B1: new_do_write (in /lib64/libc-2.17.so)
==352== by 0x56AD3B4: _IO_do_write@@GLIBC_2.2.5 (in /lib64/libc-2.17.so)
==352== by 0x56AD6FE: _IO_file_overflow@@GLIBC_2.2.5 (in /lib64/libc-2.17.so)
==352== by 0x56AE3D8: _IO_default_xsputn (in /lib64/libc-2.17.so)
==352== by 0x56ACAA2: _IO_file_xsputn@@GLIBC_2.2.5 (in /lib64/libc-2.17.so)
==352== by 0x5682133: buffered_vfprintf (in /lib64/libc-2.17.so)
==352== by 0x567CE9D: vfprintf (in /lib64/libc-2.17.so)
==352== by 0x5687096: fprintf (in /lib64/libc-2.17.so)
==352== by 0x4E7AC5: vreportf (usage.c:15)
==352== by 0x4E7B14: die_builtin (usage.c:38)
The actual complaint appears to be a bug in the underlying
implementation. What's interesting here is that it is apparently
_triggered_ by closing stderr, which results in (from strace)
Closing stderr is a bad idea anyway: there is a very real chance that
we print fatal error messages to some other file that just happens to
be opened on the now-free FD 2. So let's not do that.
As pointed out by Eric Wong (thanks), the initial close needs to go:
die() would again write nowhere if we close STDERR beforehand.
Signed-off-by: Thomas Rast <redacted> Signed-off-by: Eric Wong <redacted> Signed-off-by: Junio C Hamano <redacted>
Junio C Hamano [Thu, 4 Apr 2013 19:59:55 +0000 (12:59 -0700)]
Merge branch 'jk/peel-ref' into maint
* jk/peel-ref:
upload-pack: load non-tip "want" objects from disk
upload-pack: make sure "want" objects are parsed
upload-pack: drop lookup-before-parse optimization
Jeff King [Thu, 4 Apr 2013 19:03:58 +0000 (15:03 -0400)]
t3600: test behavior of reverse-d/f conflict
The previous commit taught "rm" that it is safe to consider
"d/f" removed when "d" has become a non-directory. This
patch adds a test for the opposite: a file "d" that becomes
a directory.
In this case, "git rm" does need to complain, because we
should not be removing arbitrary content under "d". Git
already behaves correctly, but let's make sure that remains
the case by protecting the behavior with a test.
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Thu, 4 Apr 2013 19:03:35 +0000 (15:03 -0400)]
rm: do not complain about d/f conflicts during deletion
If we used to have an index entry "d/f", but "d" has been
replaced by a non-directory entry, the user may still want
to run "git rm" to delete the stale index entry. They could
use "git rm --cached" to just touch the index, but "git rm"
should also work: we explicitly try to handle the case that
the file has already been removed from the working tree.
However, because unlinking "d/f" in this case will not yield
ENOENT, but rather ENOTDIR, we do not notice that the file
is already gone. Instead, we report it as an error.
The simple solution is to treat ENOTDIR in this case exactly
like ENOENT; all we want to know is whether the file is
already gone, and if a leading path is no longer a
directory, then by definition the sub-path is gone.
Reported-by: jpinheiro <redacted> Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Johannes Sixt [Thu, 4 Apr 2013 18:41:43 +0000 (20:41 +0200)]
rerere forget: do not segfault if not all stages are present
The loop that fills in the buffers that are later passed to the merge
driver exits early when not all stages of a path are present in the index.
But since the buffer pointers are not initialized in advance, the
subsequent accesses are undefined.
Initialize buffer pointers in advance to avoid undefined behavior later.
That is not sufficient, though, to get correct operation of handle_cache().
The function replays a conflicted merge to extract the part inside the
conflict markers. As written, the loop exits early when a stage is missing.
Consequently, the buffers for later stages that would be present in the
index are not filled in and the merge is replayed with incomplete data.
Fix it by investigating all stages of the given path.
Signed-off-by: Johannes Sixt <redacted> Signed-off-by: Junio C Hamano <redacted>
Jonathan Nieder [Tue, 19 Mar 2013 22:51:34 +0000 (15:51 -0700)]
add -A: only show pathless 'add -A' warning when changes exist outside cwd
In the spirit of the recent similar change for 'git add -u', avoid
pestering users that restrict their attention to a subdirectory and
will not be affected by the coming change in the behavior of pathless
'git add -A'.
Signed-off-by: Jonathan Nieder <redacted> Signed-off-by: Junio C Hamano <redacted>
Jonathan Nieder [Tue, 19 Mar 2013 22:50:50 +0000 (15:50 -0700)]
add -u: only show pathless 'add -u' warning when changes exist outside cwd
A common workflow in large projects is to chdir into a subdirectory of
interest and only do work there:
cd src
vi foo.c
make test
git add -u
git commit
The upcoming change to 'git add -u' behavior would not affect such a
workflow: when the only changes present are in the current directory,
'git add -u' will add all changes, and whether that happens via an
implicit "." or implicit ":/" parameter is an unimportant
implementation detail.
The warning about use of 'git add -u' with no pathspec is annoying
because it seemingly serves no purpose in this case. So suppress the
warning unless there are changes outside the cwd that are not being
added.
A previous version of this patch ran two I/O-intensive diff-files
passes: one to find changes outside the cwd, and another to find
changes to add to the index within the cwd. This version runs one
full-tree diff and decides for each change whether to add it or warn
and suppress it in update_callback. As a result, even on very large
repositories "git add -u" will not be significantly slower than the
future default behavior ("git add -u :/"), and the slowdown relative
to "git add -u ." should be a useful clue to users of such
repositories to get into the habit of explicitly passing '.'.
Signed-off-by: Jonathan Nieder <redacted> Acked-by: Jeff King <redacted> Improved-by: Junio C Hamano <redacted> Signed-off-by: Junio C Hamano <redacted>
Jonathan Nieder [Tue, 19 Mar 2013 22:45:52 +0000 (15:45 -0700)]
add: make warn_pathless_add() a no-op after first call
Make warn_pathless_add() print its warning the first time it is called
and do nothing if called again. This will make it easier to show the
warning on the fly when a relevant condition is detected without
risking showing it multiple times when multiple such conditions hold.
Signed-off-by: Jonathan Nieder <redacted> Signed-off-by: Junio C Hamano <redacted>
Junio C Hamano [Wed, 3 Apr 2013 16:34:53 +0000 (09:34 -0700)]
Merge branch 'jc/sha1-name-object-peeler'
There was no good way to ask "I have a random string that came from
outside world. I want to turn it into a 40-hex object name while
making sure such an object exists". A new peeling suffix ^{object}
can be used for that purpose, together with "rev-parse --verify".
* jc/sha1-name-object-peeler:
peel_onion(): teach $foo^{object} peeler
peel_onion: disambiguate to favor tree-ish when we know we want a tree-ish
Junio C Hamano [Wed, 3 Apr 2013 16:34:37 +0000 (09:34 -0700)]
Merge branch 'js/iterm-is-on-osx'
Add more logic to detect graphic environment of OS X by simply
checking TERM_PROGRAM has some value, not Apple_Terminal, to detect
iTerm.app and any other.
* js/iterm-is-on-osx:
git-web--browse: recognize any TERM_PROGRAM as a GUI terminal on OS X
Junio C Hamano [Wed, 3 Apr 2013 16:34:28 +0000 (09:34 -0700)]
Merge branch 'jk/check-corrupt-objects-carefully'
Have the streaming interface and other codepaths more carefully
examine for corrupt objects.
* jk/check-corrupt-objects-carefully:
clone: leave repo in place after checkout errors
clone: run check_everything_connected
clone: die on errors from unpack_trees
add tests for cloning corrupted repositories
streaming_write_entry: propagate streaming errors
add test for streaming corrupt blobs
avoid infinite loop in read_istream_loose
read_istream_filtered: propagate read error from upstream
check_sha1_signature: check return value from read_istream
stream_blob_to_fd: detect errors reading from stream
Try to be careful when difftool backend allows the user to write
into the temporary files being shown *and* the user makes changes
to the working tree at the same time. One of the changes has to be
lost in such a case, but at least tell the user what he did.
* jk/difftool-no-overwrite-on-copyback:
t7800: run --dir-diff tests with and without symlinks
t7800: fix tests when difftool uses --no-symlinks
t7800: don't hide grep output
difftool: don't overwrite modified files
t7800: move '--symlinks' specific test to the end
Junio C Hamano [Wed, 3 Apr 2013 16:34:04 +0000 (09:34 -0700)]
Merge branch 'jc/directory-attrs-regression-fix'
Fix 1.8.1.x regression that stopped matching "dir" (without
trailing slash) to a directory "dir".
* jc/directory-attrs-regression-fix:
t: check that a pattern without trailing slash matches a directory
dir.c::match_pathname(): pay attention to the length of string parameters
dir.c::match_pathname(): adjust patternlen when shifting pattern
dir.c::match_basename(): pay attention to the length of string parameters
attr.c::path_matches(): special case paths that end with a slash
attr.c::path_matches(): the basename is part of the pathname
Junio C Hamano [Wed, 3 Apr 2013 16:26:27 +0000 (09:26 -0700)]
Merge branch 'mg/gpg-interface-using-status' into maint
Verification of signed tags were not done correctly when not in C
or en/US locale.
* mg/gpg-interface-using-status:
pretty: make %GK output the signing key for signed commits
pretty: parse the gpg status lines rather than the output
gpg_interface: allow to request status return
log-tree: rely upon the check in the gpg_interface
gpg-interface: check good signature in a reliable way
Junio C Hamano [Wed, 3 Apr 2013 16:26:07 +0000 (09:26 -0700)]
Merge branch 'bc/commit-complete-lines-given-via-m-option' into maint
'git commit -m "$msg"' used to add an extra newline even when
$msg already ended with one.
* bc/commit-complete-lines-given-via-m-option:
Documentation/git-commit.txt: rework the --cleanup section
git-commit: only append a newline to -m mesg if necessary
t7502: demonstrate breakage with a commit message with trailing newlines
t/t7502: compare entire commit message with what was expected
Junio C Hamano [Wed, 3 Apr 2013 16:25:52 +0000 (09:25 -0700)]
Merge branch 'jc/describe' into maint
The "--match=<pattern>" option of "git describe", when used with
"--all" to allow refs that are not annotated tags to be used as a
base of description, did not restrict the output from the command to
those that match the given pattern.
* jc/describe:
describe: --match=<pattern> must limit the refs even when used with --all
Junio C Hamano [Wed, 3 Apr 2013 16:25:41 +0000 (09:25 -0700)]
Merge branch 'jk/alias-in-bare' into maint
An aliased command spawned from a bare repository that does not say
it is bare with "core.bare = yes" is treated as non-bare by mistake.
* jk/alias-in-bare:
setup: suppress implicit "." work-tree for bare repos
environment: add GIT_PREFIX to local_repo_env
cache.h: drop LOCAL_REPO_ENV_SIZE
Junio C Hamano [Wed, 3 Apr 2013 16:25:15 +0000 (09:25 -0700)]
Merge branch 'jk/empty-archive' into maint
"git archive" reports a failure when asked to create an archive out
of an empty tree. It would be more intuitive to give an empty
archive back in such a case.
* jk/empty-archive:
archive: handle commits with an empty tree
test-lib: factor out $GIT_UNZIP setup
Junio C Hamano [Wed, 3 Apr 2013 16:18:01 +0000 (09:18 -0700)]
Sync with 1.8.1 maintenance track
* maint-1.8.1:
Start preparing for 1.8.1.6
git-tag(1): we tag HEAD by default
Fix revision walk for commits with the same dates
t2003: work around path mangling issue on Windows
pack-refs: add fully-peeled trait
pack-refs: write peeled entry for non-tags
use parse_object_or_die instead of die("bad object")
avoid segfaults on parse_object failure
entry: fix filter lookup
t2003: modernize style
name-hash.c: fix endless loop with core.ignorecase=true
Junio C Hamano [Wed, 3 Apr 2013 15:37:39 +0000 (08:37 -0700)]
Merge branch 'ap/maint-diff-rename-avoid-overlap' into maint-1.8.1
* ap/maint-diff-rename-avoid-overlap:
tests: make sure rename pretty print works
diff: prevent pprint_rename from underrunning input
diff: Fix rename pretty-print when suffix and prefix overlap
Thomas Rast [Wed, 3 Apr 2013 14:27:14 +0000 (16:27 +0200)]
git-tag(1): we tag HEAD by default
The <commit>|<object> argument is actually not explained anywhere
(except implicitly in the description of an unannotated tag). Write a
little explanation, in particular to cover the default.
Signed-off-by: Thomas Rast <redacted> Signed-off-by: Junio C Hamano <redacted>
Philip Oakley [Tue, 2 Apr 2013 22:39:52 +0000 (23:39 +0100)]
doc: include --guide option description for "git help"
Note that the ability to display an individual guide was always
possible. Include this in the update.
Also tell readers how git(1) can be accessed, especially for Git for
Windows users who do not have the 'man' command. Likewise include a
commentary on how to access this page (Catch 22).
Signed-off-by: Philip Oakley <redacted> Signed-off-by: Junio C Hamano <redacted>
Philip Oakley [Tue, 2 Apr 2013 22:39:49 +0000 (23:39 +0100)]
builtin/help.c: split "-a" processing into two
"help -a" (help all) gives the list of available commands and then
further gives hints on the use of "git help". Separate these into
two steps, because we will add "help -g" (help guides) that want to
also show the overall hints after it is done.
While at it, change the definition of the "-a" option to use OPT_BOOL,
not the deprecated OPT_BOOLEAN. We do not behave differently when
the user gives the "-a" option multiple times, e.g. "git help -a -a".
Signed-off-by: Philip Oakley <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Tue, 2 Apr 2013 19:05:12 +0000 (15:05 -0400)]
branch: give advice when tracking start-point is missing
If the user requests to --set-upstream-to a branch that does
not exist, then either:
1. It was a typo.
2. They thought the branch should exist.
In case (1), there is not much we can do beyond showing the
name we tried to use. For case (2), though, we can help to
guide them through common workflows.
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Tue, 2 Apr 2013 19:04:51 +0000 (15:04 -0400)]
branch: mention start_name in set-upstream error messages
If we refuse a branch operation because the tracking
start_name the user gave us is bogus, we just print
something like:
fatal: Cannot setup tracking information; start point is not a branch
If we mention the actual name we tried to use, that may help
the user figure out why it didn't work (e.g., if they gave
us the arguments in the wrong order).
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Tue, 2 Apr 2013 19:04:27 +0000 (15:04 -0400)]
branch: improve error message for missing --set-upstream-to ref
If we are trying to set the upstream config for a branch,
the create_branch function will check both that the name
resolves as a ref, and that it is either a local or
remote-tracking branch.
However, before we do so we run get_sha1 on it to find out
whether it resolves at all (since the create_branch function
is also used to create actual branches, it wants to know
where to start the new branch). This means that if you feed
a ref that does not exist to "branch --set-upstream-to",
rather than getting a helpful message about tracking, you
only get "not a valid object name".
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Tue, 2 Apr 2013 19:03:55 +0000 (15:03 -0400)]
branch: factor out "upstream is not a branch" error messages
This message is duplicated, and is quite long. Let's factor
it out, which avoids the repetition and the long lines. It
will also make future patches easier as we tweak the
message.
While we're at it, let's also mark it for translation.
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Jeff King [Tue, 2 Apr 2013 19:02:53 +0000 (15:02 -0400)]
t3200: test --set-upstream-to with bogus refs
These tests pass with the current code, but let's make sure
we don't accidentally break the behavior in the future.
Note that our tests expect failure when we try to set the
upstream to or from a missing branch. Technically we are
just munging config here, so we do not need the refs to
exist. But seeing that they do exist is a good check that
the user has not made a typo.
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Junio C Hamano [Tue, 2 Apr 2013 22:10:53 +0000 (15:10 -0700)]
Merge branch 'jk/config-with-empty-section'
Document that "git config --unset" does not remove an empty section
head after removing the last variable in a section, and adding a
new variable does not try to reuse a leftover empty section head.
* jk/config-with-empty-section:
t1300: document some aesthetic failures of the config editor
Junio C Hamano [Tue, 2 Apr 2013 22:09:54 +0000 (15:09 -0700)]
Merge branch 'tb/cygwin-shared-repository'
Cygwin port has a faster-but-lying lstat(2) emulation whose
incorrectness does not matter in practice except for a few
codepaths, and setting permission bits to directories is a codepath
that needs to use a more correct one.
* tb/cygwin-shared-repository:
Make core.sharedRepository work under cygwin 1.7
Junio C Hamano [Tue, 2 Apr 2013 22:09:35 +0000 (15:09 -0700)]
Merge branch 'jk/no-more-self-assignment'
This started as a topic to reduce "type var = var" self assignment
tricks that were used to squelch "variable used uninitialized perhaps?"
warning from some compilers, but resulted in rewriting logic with
a version that is simpler and easier to understand for humans.
* jk/no-more-self-assignment:
match-trees: simplify score_trees() using tree_entry()
submodule: clarify logic in show_submodule_summary
Jeff King [Tue, 2 Apr 2013 14:22:19 +0000 (10:22 -0400)]
filter-branch: return to original dir after filtering
The first thing filter-branch does is to create a temporary
directory, either ".git-rewrite" in the current directory
(which may be the working tree or the repository if bare),
or in a directory specified by "-d". We then chdir to
$tempdir/t as our temporary working directory in which to run
tree filters.
After finishing the filter, we then attempt to go back to
the original directory with "cd ../..". This works in the
.git-rewrite case, but if "-d" is used, we end up in a
random directory. The only thing we do after this chdir is
to run git-read-tree, but that means that:
1. The working directory is not updated to reflect the
filtered history.
2. We dump random files into "$tempdir/.." (e.g., if you
use "-d /tmp/foo", we dump junk into /tmp).
Fix it by recording the full path to the original directory
and returning there explicitly.
Signed-off-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
Johannes Sixt [Mon, 1 Apr 2013 21:36:36 +0000 (23:36 +0200)]
rerere forget: grok files containing NUL
Using 'git rerere forget .' after a merge that involved binary files
runs into an infinite loop if the binary file contains a zero byte.
Replace a strchrnul by memchr because the former does not make progress
as soon as the NUL is encountered.
Signed-off-by: Johannes Sixt <redacted> Signed-off-by: Junio C Hamano <redacted>
This new configuration variable overrides `remote.pushdefault` and
`branch.<name>.remote` for pushes. When you pull from one
place (e.g. your upstream) and push to another place (e.g. your own
publishing repository), you would want to set `remote.pushdefault` to
specify the remote to push to for all branches, and use this option to
override it for a specific branch.
Signed-off-by: Ramkumar Ramachandra <redacted> Reviewed-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
This new configuration variable defines the default remote to push to,
and overrides `branch.<name>.remote` for all branches. It is useful
in the typical triangular-workflow setup, where the remote you're
fetching from is different from the remote you're pushing to.
Signed-off-by: Ramkumar Ramachandra <redacted> Reviewed-by: Jeff King <redacted> Signed-off-by: Junio C Hamano <redacted>
git.99rst.org / git.git / log