Conflicts:
Makefile
RelNotes
builtin-ls-files.c
builtin-tag.c
cache.h
compat/mingw.c
config.c
connect.c
cpio.sh
diff.c
exec_cmd.c
git-gui/Makefile
git-gui/lib/commit.tcl
git-gui/lib/console.tcl
git-mergetool.sh
lockfile.c
path.c
rsh.c
run-command.c
setup.c
show-index.c
spawn-pipe.c
t/Makefile
t/t0000-basic.sh
t/t1300-repo-config.sh
t/t7501-commit.sh
t/test-lib.sh
Resolve as follows
--- Makefile
- mingw/devel removes
SHELL_PATH = /bin/sh
PERL_PATH = /bin/perl
This looks ok. Both are set early in the Makefile to sensible values.
mingw accepts to execute /usr/bin/perl.
- NO_SYMLINKS is no longer needed. Should be auto-detected.
- According to our 0e2bdc35af
we want
NO_R_TO_GCC_LINKER = YesPlease
take our before their change.
- Conflict prefix, SCRIPT_SH:
our 7999f434d7 set prefix =
their 4a7c98dbaf removes cpio emulator
resolve to achieve both.
- Conflict NO_MEMMEM, THREADED_DELTA_SEARCH: take theirs
--- RelNotes
take our: removed file
--- builtin-ls-files.c
Conflict write_name_quoted: take their change.
--- builtin-tag.c
Conflict strip CR
our 7734ad404c adds strip CR
their fd17f5b5f7 modifies code to use strbuf
resolve by removing our code. TODO: we probably need a replacement?
--- cache.h
Conflict is_absolute_path()
our ef5af72062 ifdef
their 637fc51696 ifndef
both achieve the same.
our is a bit more strict but we take their code because we want
to reduce differences to mingw.
--- compat/mingw.c
Conflict at end of file:
our 194c1dbb5a adds git_exit()
resolve by taking their first, followed by our.
--- config.c
Conflict 'fd ='
our 0a453a237e merge junio/master
introduced strange 'fd ='. Resolve by removing 'fd ='.
--- connect.c
- Conflict 'host must have at least 2 chars ...' take their code.
- git_connect(): take their implementation.
--- cpio.sh
Accepted their delete file.
--- diff.c
Resolve using their implementation.
--- exec_cmd.c
Resolve using their implementation.
--- git-gui/**
Resolve using our implementation.
--- git-mergetool.sh
Resolve using their implementation
--- lockfile.c
trivial resolution (empty line removed)
--- path.c
Conflict 'tmp': accepting their implementation, trying TMP, TEMP on all platforms.
--- rsh.c
Accept their delete file.
--- run-command.c
Resolve using their implementation
--- setup.c
Resolve using their implementation
--- show-index.c
Conflict PRIuMAX
our 89697a4c15 fix warning
their 5be507fc95 PRIuMAX
resolve fixing warning in their code.
--- spawn-pipe.c
Conflict environ vs lookup_prog: resolve taking neither
--- t/Makefile
our d1f83218dc --no-hardlinks
their c603988c10 automtically detect symlink support
Resolve using our --no-hardlinks but removing --no-symlinks.
--- t/0000-basic.sh
Resolve using their implementation.
--- t/t1300-repo-config.sh
Resolve using their implementation.
--- t/t7501-commit.sh
Resolve using their implementation.
--- t/test-lib.sh
our d1f83218dc --no-hardlink
their c603988c10 automatically detect symlink support
Resolve using our --no-hardlinks but removing --no-symlinks.
Signed-off-by: Steffen Prohaska <prohaska@zib.de>
* sq_quote_buf is made public, and works on a strbuf.
* sq_quote_argv also works on a strbuf.
* make sq_quote_argv take a "maxlen" argument to check the buffer won't grow
too big.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* drop nfasprintf.
* move nfvasprintf into imap-send.c back, and let it work on a 8k buffer,
and die() in case of overflow. It should be enough for imap commands, if
someone cares about imap-send, he's welcomed to fix it properly.
* replace nfvasprintf use in merge-recursive with a copy of the strbuf_addf
logic, it's one place, we'll live with it.
To ease the change, output_buffer string list is replaced with a strbuf ;)
* rework trace.c to call vsnprintf itself. It's used to format strerror()s
and git command names, it should never be more than a few octets long, let
it work on a 8k static buffer with vsnprintf or die loudly.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
This imitates what is currently in git.git's master: a function to
determine if a path is absolute.
msysgit.git is not really the proper place to fix this, but Hannes is
still on holiday.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
In order to track and build on top of a branch 'topic' you track from
your upstream repository, you often would end up doing this sequence:
git checkout -b mytopic origin/topic
git config --add branch.mytopic.remote origin
git config --add branch.mytopic.merge refs/heads/topic
This would first fork your own 'mytopic' branch from the 'topic'
branch you track from the 'origin' repository; then it would set up two
configuration variables so that 'git pull' without parameters does the
right thing while you are on your own 'mytopic' branch.
This commit adds a --track option to git-branch, so that "git
branch --track mytopic origin/topic" performs the latter two actions
when creating your 'mytopic' branch.
If the configuration variable branch.autosetupmerge is set to true, you
do not have to pass the --track option explicitly; further patches in
this series allow setting the variable with a "git remote add" option.
The configuration variable is off by default, and there is a --no-track
option to countermand it even if the variable is set.
Signed-off-by: Paolo Bonzini <bonzini@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We recently introduced a write_in_full() which would either write
the specified object or emit an error message and fail. In order
to fix the read side we now want to introduce a read_in_full()
but without an error emit. This patch cleans up the naming
of this family of calls:
1) convert the existing write_or_whine() to write_or_whine_pipe()
to better indicate its pipe specific nature,
2) convert the existing write_in_full() calls to write_or_whine()
to better indicate its nature,
3) introduce a write_in_full() providing a write or fail semantic,
and
4) convert write_or_whine() and write_or_whine_pipe() to use
write_in_full().
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If GIT_TRACE is set to an absolute path (starting with a
'/' character), we interpret this as a file path and we
trace into it.
Also if GIT_TRACE is set to an integer value greater than
1 and lower than 10, we interpret this as an open fd value
and we trace into it.
Note that this behavior is not compatible with the
previous one.
We also trace whole messages using one write(2) call to
make sure messages from processes do net get mixed up in
the middle.
This patch makes it possible to get trace information when
running "make test".
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
