The shell syntax "export X=Y A=B" is not understood by all shells.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The shell syntax "export X=Y" is not understood by all shells.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The shell syntax "export X=Y A=B" is not understood by all shells.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The shell syntax "export X=Y" is not understood by all shells.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The shell syntax "export X=Y" is not understood by all shells.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Do not just randomly synchronize the revisions with no checks at
all.
I don't have any evidence that there's anything wrong with the
current code, which Bazaar seems to use, but for different purposes.
Let's use the logic Bazaar UI uses to avoid surprises.
Also, add a non-ff check.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Use namebuf/namelen and mailbuf/maillen directly instead of copying
their contents into strbufs first.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Keep namelen unchanged and don't use it to hold a value that we're not
interested in anyway -- we can use maillen and the constant part
directly instead. This simplifies the code slightly and prepares for
the next patch that makes use of the original value of namelen.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of searching for LF and NUL with two strchr() calls use a single
strchrnul() call. We don't need to check if the returned pointer is NULL
because either we'll find the NUL at the end of line, or the caller
forgot to NUL-terminate the string and we'll overrun the buffer in any
case. Also we don't need to pass LF or NUL to split_ident_line() as it
ignores it anyway.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a rebase stops (e.g. interrupted by a merge conflict), it could
be useful to know how far a rebase has progressed and how many
commits in total this rebase will apply. Teach the __git_ps1()
command to display the number of commits so far applied and the
total number of commits to be applied, like this:
((3ec0a6a...)|REBASE 2/5)
In the example above the rebase has stopped at the second commit due to
a merge conflict and there are a total number of five commits to be
applied by this rebase.
This information can be already obtained from the following files which are
being generated during the rebase:
GIT_DIR/.git/rebase-merge/msgnum (git-rebase--merge.sh)
GIT_DIR/.git/rebase-merge/end (git-rebase--merge.sh)
GIT_DIR/.git/rebase-apply/next (git-am.sh)
GIT_DIR/.git/rebase-apply/last (git-am.sh)
but "rebase -i" does not leave necessary clues.
Implement this feature by doing these three things:
1) Modify git-rebase--interactive.sh to also create
GIT_DIR/.git/rebase-merge/msgnum
GIT_DIR/.git/rebase-merge/end
files for the number of commits so far applied and the total
number of commits to be applied.
2) Modify git-prompt.sh to read and display info from the above
files.
3) Update test t9903-bash-prompt.sh to reflect changes introduced
by this patch.
Signed-off-by: Zoltan Klinger <zoltan.klinger@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Allows remote-helpers to declare they can handle signed tags, and
issue a warning when using those that don't.
* jk/remote-helper-with-signed-tags:
transport-helper: add 'signed-tags' capability
transport-helper: pass --signed-tags=warn-strip to fast-export
fast-export: add --signed-tags=warn-strip mode
"git diff --diff-algorithm=algo" was understood by the command line
parser, but "git diff --diff-algorithm algo" was not.
* jk/diff-algo-finishing-touches:
diff: allow unstuck arguments with --diff-algorithm
git-merge(1): document diff-algorithm option to merge-recursive
"git log -S/-G" started paying attention to textconv filter, but
there was no way to disable this. Make it honor --no-textconv
option.
* sr/log-SG-no-textconv:
diffcore-pickaxe: unify code for log -S/-G
diffcore-pickaxe: fix leaks in "log -S<block>" and "log -G<pattern>"
diffcore-pickaxe: port optimization from has_changes() to diff_grep()
diffcore-pickaxe: respect --no-textconv
diffcore-pickaxe: remove fill_one()
diffcore-pickaxe: remove unnecessary call to get_textconv()
"git merge $(git rev-parse v1.8.2)" behaved quite differently from
"git merge v1.8.2", as if v1.8.2 were written as v1.8.2^0 and did
not pay much attention to the annotated tag payload. Make the code
notice the type of the tag object, in addition to the dwim_ref()
based classification the current code uses (i.e. the name appears in
refs/tags/) to decide when to special case merging of tags.
* jc/merge-tag-object:
t6200: test message for merging of an annotated tag
t6200: use test_config/test_unconfig
merge: a random object may not necssarily be a commit
Remove one of two consecutive, identical blocks for "git commit -c".
This was caused by a mechanical mismerge at d931e2fb25 (Merge
branch 'mp/complete-paths', 2013-02-08). The side branch wanted to
add this block at fea16b47 but the same fix was done independently
at 685397585 already.
Signed-off-by: Mårten Kongstad <marten.kongstad@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'git remote show' and 'prune' subcommands are documented as taking
only a single remote name argument, but that is not the case; they
will simply iterate the action over all remotes given. Update the
documentation and tests to match.
With the last user of the -f flag gone, we also remove the code
supporting it.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The 'git remote add' subcommand did not check for superfluous command
line arguments. Make it so.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This adds one test or comment for each subcommand of git-remote
according to its current documentation. All but 'set-branches' and
'update' are listed as taking only a fixed number of arguments; for
those we can write a test with one more (bogus) argument, and see if
the command notices that.
They fail on several counts: 'add' does not check for extra arguments,
and 'show' and 'prune' actually iterate over remotes (i.e., take any
number of args). We'll fix them in the next two patches.
The -f machinery is only there to make the tests readable while still
ensuring they pass as a whole, and will be removed in the final patch.
Signed-off-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The usage string for cherry-pick and revert has never been updated to
reflect their ability to handle multiple commits. Other documentation is
already correct.
Signed-off-by: Kevin Bracey <kevin@bracey.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When we 'git rebase $upstream', git uses 'rev-parse --verify
$current_branch' to find ORIG_HEAD. But if $current_branch
is ambiguous, 'rev-parse --verify' emits a warning and returns
a SHA1 anyway. When the wrong ambiguous choice is used,
git-rebase fails non-gracefully: it emits a warning about
failing to lock $current_branch, an error about being unable to
checkout $current_branch again, and it might even decide the
rebase is a fast-forward when it is not.
In the 'rebase $upstream' case, we already know the unambiguous
spelling of $current_branch is "HEAD". Fix git-rebase to find
$orig_head unambiguously.
Add a test in t3400-rebase.sh which creates an ambiguous branch
name and rebases it implicitly with 'git rebase $other'.
Signed-off-by: Phil Hord <hordp@cisco.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
pretty-printing body of the commit that is stored in non UTF-8
encoding did not work well. The early part of this series fixes
it. And then it adds %C(auto) specifier that turns the coloring on
when we are emitting to the terminal, and adds column-aligning
format directives.
* nd/pretty-formats:
pretty: support %>> that steal trailing spaces
pretty: support truncating in %>, %< and %><
pretty: support padding placeholders, %< %> and %><
pretty: add %C(auto) for auto-coloring
pretty: split color parsing into a separate function
pretty: two phase conversion for non utf-8 commits
utf8.c: add reencode_string_len() that can handle NULs in string
utf8.c: add utf8_strnwidth() with the ability to skip ansi sequences
utf8.c: move display_mode_esc_sequence_len() for use by other functions
pretty: share code between format_decoration and show_decorations
pretty-formats.txt: wrap long lines
pretty: get the correct encoding for --pretty:format=%e
pretty: save commit encoding from logmsg_reencode if the caller needs it
Fixes a handful of issues in the code to traverse working tree to
find untracked and/or ignored files, cleans up and optimizes the
codepath in general.
* kb/status-ignored-optim-2:
dir.c: git-status --ignored: don't scan the work tree twice
dir.c: git-status --ignored: don't scan the work tree three times
dir.c: git-status: avoid is_excluded checks for tracked files
dir.c: replace is_path_excluded with now equivalent is_excluded API
dir.c: unify is_excluded and is_path_excluded APIs
dir.c: move prep_exclude
dir.c: factor out parts of last_exclude_matching for later reuse
dir.c: git-clean -d -X: don't delete tracked directories
dir.c: make 'git-status --ignored' work within leading directories
dir.c: git-status --ignored: don't list empty directories as ignored
dir.c: git-ls-files --directories: don't hide empty directories
dir.c: git-status --ignored: don't list empty ignored directories
dir.c: git-status --ignored: don't list files in ignored directories
dir.c: git-status --ignored: don't drop ignored directories
When receive-pack detects error in the pack header it received in
order to decide which of unpack-objects or index-pack to run, it
returned without closing the error stream, which led to a hang
sideband thread.
* jk/receive-pack-deadlocks-with-early-failure:
receive-pack: close sideband fd on early pack errors
If the bisection completes with only skipped commits left to as possible
first bad commit, output the list of possible first bad commits to human
readers of the bisection log.
Signed-off-by: Torstein Hegge <hegge@resisty.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's no functional change since mercurial commit operation strips
that anyway, but that's no excuse for us not to do the right thing. So
let's be explicit about it.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
So that we can find already exported ones. We can never be 100% sure
that we already exported such data, due to mercurial design, it at least
sometimes we should detect them, and so should give us some performance
boost.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Load previous manifest first as Mercurial does; for caching reasons.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
So that we can use shortened URLs, for example 'bb:://felipec/repo'
(Bitbucket).
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
There's no point in calling the tag method for such simple action. Not
that we care much about the hg-git compat mode, it's mostly just for
comparison testing purposes.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The one from mercurial is meant for users, on top of the latest tip.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Idea from gitifyhg, the backwards compatibility is how Mercurial used to
do it.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It's simpler, and we don't need to depend on certain Mercurial versions.
Also, now we don't update the URL if 'file://' is not present.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is possible that the remote has changed the bookmarks, so let's fetch
them before we make any assumptions, just the way mercurial does.
Probably doesn't make a difference, but better be safe than sorry.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It is deprecated.
[fc: do the same in remote-bzr]
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Now we have a synonym --ignore-removal for --no-all, we can rephrase
the Git 2.0 transition warning message in a more natural way.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
In the historical context of "git add --all ." that pays attention
to "all kinds of changes" (implying "without ignoring removals"),
the option to countermand it "--no-all" may have made sense, but
because we will be making "--all" the default when a pathspec is
given, it makes more sense to rename the option to a more explicit
"--ignore-removal". The "--all" option naturally becomes its
negation, "--no-ignore-removal".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Junio C Hamano