On Mon, Feb 22, 2016 at 10:35:34PM -0800, Junio C Hamano wrote:
> > I stopped short of dropping the create_virtual_base function in the
> > first patch, for reasons explained there. But if we were to do so, I
> > suspect we could deprecated and eventually drop "apply --no-add", too.
>
> Thanks.
From: Jon Griffiths
Changing to the socket path stops the daemon holding open
the directory the user was in when it was started,
preventing umount from working. We're already holding open a
socket in that directory, so there's no downside.
Thanks-to: Jeff King
Signed-off-by: Jon Griffiths
Sign
From: Jon Griffiths
Relative socket paths are dangerous since the user cannot generally
control when the daemon starts (initially, after a timeout, kill or
crash). Since the daemon creates but does not delete the socket
directory, this could lead to spurious directory creation relative
to the use
From: Jon Griffiths
This function does an early return, and therefore has to
repeat its cleanup. We can stick the later bit of the
function into an "else" and avoid duplicating the shared
part (which will get bigger in a future patch).
Let's also rename the function to init_socket_directory. It
The credential-cache--daemon may live forever in whatever directory it
happened to be spawned in (in practice, probably the root of some git
repo's work tree). This can prevent umount from unmounting a filesystem
that contains that directory, even though credential-cache doesn't care
one way or the
"Felipe Gonçalves Assis" writes:
> + test_cmp diff-output grep-output &&
> + while read status old new
> + do
> + th[${old:0:1}]=${status:1}
> + done http://vger.kernel.org/majordomo-info.html
Amadeusz Żołnowski writes:
> Junio C Hamano writes:
>> I wonder if it makes sense to just silently allowing submit without
>> rebasing, and without telling the user how to clean it up.
>
> It is a good point. Maybe submit shouldn't be allowed by default at all
> From bare repository. What do you
Fengguang Wu writes:
> Hi Junio,
>
> On Sun, Feb 21, 2016 at 08:19:56PM -0800, Junio C Hamano wrote:
>> Xiaolong Ye writes:
>>
>> > It would be helpful for maintainers or reviewers to know the base tree
>> > info of the patches created by git format-patch. Teach git format-patch
>> > a --base-t
Stefan Beller writes:
> On Mon, Feb 22, 2016 at 4:01 PM, Junio C Hamano wrote:
>>
>> Stefan Beller writes:
>>
>> > We may want to discuss the error message. It is the same as in the case
>> > before (git-fetch ), this is good for translation, but may be bad
>> > for the user as we may want to g
Jeff King writes:
> On Tue, Feb 23, 2016 at 12:14:02AM -0500, Jeff King wrote:
>
>> I dug this all the way down to your cb93c19 (merge-one-file: use common
>> as base, instead of emptiness., 2005-11-09), which states that the goal
>> is just to get:
>>
>> common file contents...
>> <<<
Eric Wong writes:
> git-svn has not supported GIT_SVN_NO_OPTIMIZE_COMMITS for
> the "set-tree" sub-command in 9 years since commit 490f49ea5899
> ("git-svn: remove optimized commit stuff for set-tree").
>
> So remove this target and TSVN variable to avoid confusion.
>
> ref: http://mid.gmane.org/
git-svn has not supported GIT_SVN_NO_OPTIMIZE_COMMITS for
the "set-tree" sub-command in 9 years since commit 490f49ea5899
("git-svn: remove optimized commit stuff for set-tree").
So remove this target and TSVN variable to avoid confusion.
ref: http://mid.gmane.org/56c9b7b7.7030...@f2.dion.ne.jp
On Tue, Feb 23, 2016 at 03:32:02AM +0100, Jason A. Donenfeld wrote:
> In case anyone else finds this useful, I wrote this:
>
> https://git.zx2c4.com/git-daemon-dummy/about/
>
> It's an epoll-based responder for git:// that simply returns an error
> telling users of a new URI.
Neat.
> The purpo
There are no more callers that use this mode, and none
likely to be added (as our xdl_merge() eliminates the common
use of it for generating 3-way merge bases).
This is effectively a revert of a9ed376 (xdiff: generate
"anti-diffs" aka what is common to two files, 2006-06-28),
though of course tryi
When merge_blobs sees an add/add conflict, it tries to
create a virtual base object for the 3-way merge that
consists of the common lines of each file. It inherited this
strategy from merge-one-file in 0c79938 (Improved three-way
blob merging code, 2006-06-28), and the point is to minimize
the size
When we see an add/add conflict on a file, we generate the
conflicted content by doing a 3-way merge with a "virtual"
base consisting of the common lines of the two sides. This
strategy dates back to cb93c19 (merge-one-file: use common
as base, instead of emptiness., 2005-11-09).
Back then, the ne
On Tue, Feb 23, 2016 at 12:14:02AM -0500, Jeff King wrote:
> I dug this all the way down to your cb93c19 (merge-one-file: use common
> as base, instead of emptiness., 2005-11-09), which states that the goal
> is just to get:
>
> common file contents...
> << FILENAME
> versio
On 02/22/2016 09:20 AM, Junio C Hamano wrote:
Thanks for all the comments,
I will send a new version the next days.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info
On Tue, Feb 23, 2016 at 12:02:10AM -0500, Jeff King wrote:
> > git-merge-resolve (rather, git-merge-one-file) attempts the same
> > "resolve add/add by taking the common" thing, but it implements it
> > in quite a different way.
>
> I suppose the end result of what merge-tree is trying to do make
On Mon, Feb 22, 2016 at 02:45:45PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > 2. Rip out the weird add/add conflict resolution. This gets rid of the
> > buggy code, makes merge-tree more like the rest of git, and I think
> > lets us even drop the EMIT_COMMON stuff from xd
--find-renames= and --rename-threshold= should be aliases.
Signed-off-by: Felipe Gonçalves Assis
---
t/t3034-merge-recursive-rename-options.sh | 46 +++
1 file changed, 46 insertions(+)
diff --git a/t/t3034-merge-recursive-rename-options.sh
b/t/t3034-merge-recursive
Signed-off-by: Felipe Gonçalves Assis
---
t/t3034-merge-recursive-rename-options.sh | 28
1 file changed, 28 insertions(+)
diff --git a/t/t3034-merge-recursive-rename-options.sh
b/t/t3034-merge-recursive-rename-options.sh
index 66fee8a..03ce77c 100755
--- a/t/t3034-
10ae752 (merge-recursive: option to specify rename threshold,
2010-09-27) introduced this feature but did not include any tests.
The tests use the new option --find-renames, which replaces the then
introduced and now deprecated option --rename-threshold.
Also update name and description of t3032
Based on c443d39 (merge-recursive: find-renames resets threshold, 2016-02-21).
This patch involves only the tests for the features introduced in
fa/merge-recursive-no-rename, for better review.
The tests were rewritten so that the similarity indices are parsed instead of
assumed.
Felipe Gonçalve
>From your message I’m guessing you are using Bitbucket Server with branch
permissions [1].
We’re aware the conflict resolution instructions can not always be followed.
Improving these is on our backlog
(https://jira.atlassian.com/browse/BSERV-7561) - feel free to watch/vote for
that issue.
Firs
Junio C Hamano writes:
> I wonder if it makes sense to just silently allowing submit without
> rebasing, and without telling the user how to clean it up.
It is a good point. Maybe submit shouldn't be allowed by default at all
From bare repository. What do you think about following approach? If
c
Hi folks,
In case anyone else finds this useful, I wrote this:
https://git.zx2c4.com/git-daemon-dummy/about/
It's an epoll-based responder for git:// that simply returns an error
telling users of a new URI. The purpose is to phase out git-daemon in
favor of more secure TLS/HTTPS endpoints. With
Hi Junio,
On Sun, Feb 21, 2016 at 08:19:56PM -0800, Junio C Hamano wrote:
> Xiaolong Ye writes:
>
> > It would be helpful for maintainers or reviewers to know the base tree
> > info of the patches created by git format-patch. Teach git format-patch
> > a --base-tree-info option to record these i
On 22/02/16 21:18, Jeff King wrote:
> On Mon, Feb 22, 2016 at 12:33:23AM +, Ramsay Jones wrote:
>
>>> Thanks, will do. You notice these with sparse, as I recall? I've meant
>>> to look into running that myself, but it looks like we are not
>>> warning-free with sparse currently. I see compla
Signed-off-by: Ramsay Jones
---
Hi David,
Again, If you need to re-roll your 'dt/refs-backend-lmdb' branch ...
Thanks!
ATB,
Ramsay Jones
refs.c | 16
refs/refs-internal.h | 6 --
2 files changed, 8 insertions(+), 14 deletions(-)
diff --git a/refs.c b/ref
On Mon, Feb 22, 2016 at 4:01 PM, Junio C Hamano wrote:
>
> Stefan Beller writes:
>
> > We may want to discuss the error message. It is the same as in the case
> > before (git-fetch ), this is good for translation, but may be bad
> > for the user as we may want to give extra information.
> > ("We
Stefan Beller writes:
> We may want to discuss the error message. It is the same as in the case
> before (git-fetch ), this is good for translation, but may be bad
> for the user as we may want to give extra information.
> ("We fetched for you and it worked, however the sha1 was not included,
> s
On Mon, Feb 22, 2016 at 03:08:01PM -0800, Junio C Hamano wrote:
> > The only thing common in this series is it's the result of
> > -Wwrite-strings. 1/3 changes some "char *" to "const char *", you
> > don't miss anything.
>
> While reading Peff's clarification patch, I did find the assignment
> o
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> Stefan Beller writes:
>>
>>> Junio wrote:
To be complete, the rev-list command line should also run with
"--objects"; after all, a commit walker fetch may have downloaded
commit chain completely but haven't fetched necessary tr
Jeff King writes:
> On Fri, Feb 19, 2016 at 06:19:41AM -0500, Jeff King wrote:
>
>> Here's a re-roll of jk/tighten-alloc series from:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/286253
>
> And here's v3. The changes this time (and philosophical rationalization
> of changes I d
Duy Nguyen writes:
> On Tue, Feb 23, 2016 at 1:12 AM, Jeff King wrote:
>> On Mon, Feb 22, 2016 at 01:06:46PM -0500, Jeff King wrote:
>>
>>> Is there a case I'm missing here where we actually leak memory or try to
>>> free non-allocated memory? I didn't see it.
>>
>> By the way, I saw only patche
Junio C Hamano writes:
> Stefan Beller writes:
>
>> Junio wrote:
>>> To be complete, the rev-list command line should also run with
>>> "--objects"; after all, a commit walker fetch may have downloaded
>>> commit chain completely but haven't fetched necessary trees and
>>> blobs when it was kill
On Tue, Feb 23, 2016 at 1:12 AM, Jeff King wrote:
> On Mon, Feb 22, 2016 at 01:06:46PM -0500, Jeff King wrote:
>
>> Is there a case I'm missing here where we actually leak memory or try to
>> free non-allocated memory? I didn't see it.
>
> By the way, I saw only patches 2/3 and 3/3 on the list. So
On Tue, Feb 23, 2016 at 1:28 AM, Jeff King wrote:
> On Mon, Feb 22, 2016 at 01:06:45PM -0500, Jeff King wrote:
>
>> I have a feeling you were confused by the fact that fill_textconv()
>> does:
>
> Looking over it, I agree this is a pretty confusing interface that grew
> out of control over time.
Stefan Beller writes:
> Junio wrote:
>> To be complete, the rev-list command line should also run with
>> "--objects"; after all, a commit walker fetch may have downloaded
>> commit chain completely but haven't fetched necessary trees and
>> blobs when it was killed, and "rev-list $sha1 --not --a
Jeff King writes:
> 2. Rip out the weird add/add conflict resolution. This gets rid of the
> buggy code, makes merge-tree more like the rest of git, and I think
> lets us even drop the EMIT_COMMON stuff from xdiff).
That is a nice bonus.
git-merge-resolve (rather, git-merge-one-file
Now that we're built around xmalloc and friends, we can use
helpers like REALLOC_ARRAY, ALLOC_GROW, and so on to make
the code shorter and protect against integer overflow.
Signed-off-by: Jeff King
---
ewah/bitmap.c | 16
ewah/ewah_bitmap.c | 5 ++---
ewah/ewah_io.c |
This code was originally written with the idea that it could
be spun off into its own ewah library, and uses the
overrideable ewah_malloc to do allocations.
We plug in xmalloc as our ewah_malloc, of course. But over
the years the ewah code itself has become more entangled
with git, and the return
There are no callers of this left, as the last one was
dropped in the previous patch. And there are not likely to
be new ones, as the function has been around since 2010
without gaining any new callers.
Signed-off-by: Jeff King
---
git-compat-util.h | 9 -
1 file changed, 9 deletions(-)
We allocate 100 bytes to hold the "Submodule commit ..."
text. This is enough, but it's not immediately obvious that
this is the case, and we have to repeat the magic 100 twice.
We could get away with xstrfmt here, but we want to know the
size, as well, so let's use a real strbuf. And while we're
The normalize_path_copy function needs an output buffer that
is at least as long as its input (it may shrink the path,
but never expand it). However, this test program feeds it
static PATH_MAX-sized buffers, which have no relation to the
input size.
In the normalize_ceiling_entry case, we do at le
For a commit with sha1 "1234abcd" and subject "foo", this
function produces a struct with three strings:
1. "foo"
2. "1234abcd... foo"
3. "parent of 1234abcd... foo"
It takes advantage of the fact that these strings are
subsets of each other, and allocates only _one_ string, with
pointers in
Using FLEX_ARRAY macros reduces the amount of manual
computation size we have to do. It also ensures we don't
overflow size_t, and it makes sure we write the same number
of bytes that we allocated.
Signed-off-by: Jeff King
---
attr.c | 4 +---
builtin/blame.c | 4 +---
built
These functions transform an existing argv into one suitable
for exec-ing or spawning via git or a shell. We can use an
argv_array in each to avoid dealing with manual counting and
allocation.
This also makes the memory allocation more clear and fixes
some leaks. In prepare_shell_cmd, we would som
We perform unchecked additions when computing the size of a
"struct ondisk_untracked_cache". This is unlikely to have an
integer overflow in practice, but we'd like to avoid this
dangerous pattern to make further audits easier.
Note that there's one subtlety here, though. We protect
ourselves aga
We have two variants of this function, one that takes a
string and one that takes a ptr/len combo. But we only call
the latter with the length of a NUL-terminated string, so
our first simplification is to drop it in favor of the
string variant.
Since we know we have a string, we can also replace t
This function allocate a packed_git flex-array, and adds a
mysterious 2 bytes to the length of the pack_name field. One
is for the trailing NUL, but the other has no purpose. This
is probably cargo-culted from add_packed_git, which gets the
".idx" path and needed to allocate enough space to hold th
This function uses xcalloc and two memcpy calls to
concatenate two strings. We can do this as an xstrfmt
one-liner, and then it is more clear that we are allocating
the correct amount of memory.
Signed-off-by: Jeff King
---
transport.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-
If our size computation overflows size_t, we may allocate a
much smaller buffer than we expected and overflow it. It's
probably impossible to trigger an overflow in most of these
sites in practice, but it is easy enough convert their
additions and multiplications into overflow-checking
variants. Th
We frequently allocate strings as xmalloc(len + 1), where
the extra 1 is for the NUL terminator. This can be done more
simply with xmallocz, which also checks for integer
overflow.
There's no case where switching xmalloc(n+1) to xmallocz(n)
is wrong; the result is the same length, and malloc made
The usual pattern for an argv array is to initialize it,
push in some strings, and then clear it when done. Very
occasionally, though, we must do other exotic things with
the memory, like freeing the list but keeping the strings.
Let's provide a detach function so that callers can make use
of our A
There are many manual argv allocations that predate the
argv_array API. Switching to that API brings a few
advantages:
1. We no longer have to manually compute the correct final
array size (so it's one less thing we can screw up).
2. In many cases we had to make a separate pass to count,
Each of these cases can be converted to use ALLOC_ARRAY or
REALLOC_ARRAY, which has two advantages:
1. It automatically checks the array-size multiplication
for overflow.
2. It always uses sizeof(*array) for the element-size,
so that it can never go out of sync with the declared
A combine_diff_path struct has two "flex" members allocated
alongside the struct: a string to hold the pathname, and an
array of parent pointers. We use an "int" to compute this,
meaning we may easily overflow it if the pathname is
extremely long.
We can fix this by using size_t, and checking for
Allocating a struct with a flex array is pretty simple in
practice: you over-allocate the struct, then copy some data
into the over-allocation. But it can be a slight pain to
make sure you're allocating and copying the right amounts.
This patch adds a few helpers to turn simple cases of
flex-array
You can tweak the reflog expiration for a particular subset
of refs by configuring gc.foo.reflogexpire. We keep a linked
list of reflog_expire_cfg structs, each of which holds the
pattern and a "len" field for the length of the pattern. The
pattern itself is _not_ NUL-terminated.
However, we feed
Performing computations on size_t variables that we feed to
xmalloc and friends can be dangerous, as an integer overflow
can cause us to allocate a much smaller chunk than we
realized.
We already have unsigned_add_overflows(), but let's add
unsigned_mult_overflows() to that. Furthermore, rather th
REALLOC_ARRAY inherently involves a multiplication which can
overflow size_t, resulting in a much smaller buffer than we
think we've allocated. We can easily harden it by using
st_mult() to check for overflow. Likewise, we can add
ALLOC_ARRAY to do the same thing for xmalloc calls.
xcalloc() shou
On Fri, Feb 19, 2016 at 06:19:41AM -0500, Jeff King wrote:
> Here's a re-roll of jk/tighten-alloc series from:
>
> http://thread.gmane.org/gmane.comp.version-control.git/286253
And here's v3. The changes this time (and philosophical rationalization
of changes I didn't make) are pretty small:
When reviewing a change in Gerrit, which also updates a submodule,
a common review practice is to download and cherry-pick the patch locally
to test it. However when testing it locally, the 'git submodule update'
may fail fetching the correct submodule sha1 as the corresponding commit
in the submod
On 22 February 2016 at 19:29, Junio C Hamano wrote:
> Felipe Gonçalves Assis writes:
>
>>> As I said, I am reluctant to take the 25%/50%/75% tests in their
>>> current form. Let me take the first one and a half of the last one
>>> (i.e. excluding the test) for now.
>>>
>>> Thanks.
>>
>> Ok, shou
Junio wrote:
> To be complete, the rev-list command line should also run with
> "--objects"; after all, a commit walker fetch may have downloaded
> commit chain completely but haven't fetched necessary trees and
> blobs when it was killed, and "rev-list $sha1 --not --all" would not
> catch such a b
A simple patch evolves into a series!
First we'll fix a bug by adding the --objects switch to rev-list to
have a stricter check for the desired commit to be there. IIUC this
is not 100% right yet, but it improves the situation.
The second patch introduces an extra fetch in case the first fetch
di
Felipe Gonçalves Assis writes:
>> As I said, I am reluctant to take the 25%/50%/75% tests in their
>> current form. Let me take the first one and a half of the last one
>> (i.e. excluding the test) for now.
>>
>> Thanks.
>
> Ok, should I post a new version of the patch without the tests while I
Jeff King writes:
> On Sun, Feb 21, 2016 at 11:41:35PM +, John Keeping wrote:
>
>> My original sed version was:
>>
>> sed -ne "/^author /p" -e "/^summary /p"
>>
>> which I think will work on all platforms (we already use it in
>> t-basic.sh) but then I decided to be too clever :-(
On Sun, Feb 21, 2016 at 11:43:45PM +, John Keeping wrote:
> On Sun, Feb 21, 2016 at 04:15:31PM -0500, Eric Sunshine wrote:
> > On Sun, Feb 21, 2016 at 12:32 PM, John Keeping wrote:
> > > GNU grep 2.23 detects the input used in this test as binary data so it
> > > does not work for extracting
The latest maintenance release Git v2.7.2 is now available at
the usual places.
The tarballs are found at:
https://www.kernel.org/pub/software/scm/git/
The following public repositories all have a copy of the 'v2.7.2'
tag and the 'maint' branch that the tag points at:
url = https://kernel
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
I originally penciled in -rc0 for
On Sun, Feb 21, 2016 at 11:41:35PM +, John Keeping wrote:
> My original sed version was:
>
> sed -ne "/^author /p" -e "/^summary /p"
>
> which I think will work on all platforms (we already use it in
> t-basic.sh) but then I decided to be too clever :-(
>
> I still think sed is si
On 22 February 2016 at 18:00, Junio C Hamano wrote:
> "Felipe Gonçalves Assis" writes:
>
>> This is a reorganisation of the previous series, bundling the test for the
>> fix
>> along with the commit itself, as suggested by Eric. It also includes many
>> fixes
>> and improvements pointed out by
On Wed, Feb 17, 2016 at 02:34:08PM -0800, Junio C Hamano wrote:
> * jk/merge-tree-merge-blobs (2016-02-16) 1 commit
> - merge_blobs: use strbuf instead of manually-sized mmfile_t
>
> "git merge-tree" (a throw-away demonstration) did not work very
> well when merging "both sides added a new fil
On Mon, Feb 22, 2016 at 01:56:52PM -0800, Junio C Hamano wrote:
> Jeff King writes:
>
> > I agree that there are a lot of different ways to resolve each instance,
> > and it will vary from case to case. I think the original point of a
> > microproject was to do something really easy and not cont
Jeff King writes:
> I agree that there are a lot of different ways to resolve each instance,
> and it will vary from case to case. I think the original point of a
> microproject was to do something really easy and not contentious, so
> that the student could get familiar with all of the other par
On Mon, Feb 22, 2016 at 11:22:48AM +0100, Matthieu Moy wrote:
> > Idea for microprojects. If you compile using gcc with -Wshadow, it
> > spots local variables that shadow another local or global variables.
> > These are usually bad because it makes it's easy to make mistakes when
> > changing the
On Mon, Feb 22, 2016 at 05:24:15PM +0530, Nagaraj Mandya wrote:
> In our GIT repository, all users are restricted from merging to
> master without a pull request. This works well and all developers are
> raising pull requests and merging. However, if there is a merge
> conflict during the merge,
On Mon, Feb 22, 2016 at 12:33:23AM +, Ramsay Jones wrote:
> > Thanks, will do. You notice these with sparse, as I recall? I've meant
> > to look into running that myself, but it looks like we are not
> > warning-free with sparse currently. I see complaints like:
> >
> > connect.c:377:40: wa
On Mon, Feb 08, 2016 at 11:55:37PM +, Anatoly Borodin wrote:
> unfortunately, `--tree-filter true` doesn't solve the problem with the
> repo at my work: not all old blobs are replaced with the new ones. I've
> made a test repository to demonstrate it; it's a huge one (115M), but I
> couldn't m
"Felipe Gonçalves Assis" writes:
> This is a reorganisation of the previous series, bundling the test for the fix
> along with the commit itself, as suggested by Eric. It also includes many
> fixes
> and improvements pointed out by the same reviewer, whom I thank.
>
> The typo fix is the same a
Patch attached!
Cheers,
JamesFrom f7feb714a7ec703b97552e343d5f4ce541ffb7a1 Mon Sep 17 00:00:00 2001
From: James Shubin
Date: Sun, 8 Mar 2015 19:57:17 -0400
Subject: [PATCH] Add --recursive flag to git bash completion script.
This flag was missing from the list, and I use it quite often :)
Signe
Instead of directly applying this patch, I rearranged the code a bit,
but hopefully now have reduced the non-static surface area. Thanks for
the suggestions.
On Mon, 2016-02-22 at 16:41 +, Ramsay Jones wrote:
> Signed-off-by: Ramsay Jones
> ---
>
> Hi David,
>
> If you need to re-roll your
Eric Sunshine writes:
> On Sun, Feb 21, 2016 at 8:20 PM, Moritz Neeb wrote:
>> The inputs that are read are all answers that are given by the user
>> when interacting with git on the commandline. As these answers are
>> not supposed to contain a meaningful CR it is safe to
>> replace strbuf_getl
Moritz Neeb writes:
> diff --git a/wt-status.c b/wt-status.c
> index ab4f80d..8047cf2 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -1076,10 +1076,9 @@ static void read_rebase_todolist(const char *fname,
> struct string_list *lines)
> if (!f)
> die_errno("Could not open
Eric Sunshine writes:
> A deeper issue not touched upon by the commit message (but which
> should be) is that that strbuf_split() leaves the "terminator" (space,
> in this case) on the component strings, and that is why split[0] must
> be rtrim'd. Rather than dropping only one of the rtrim's, a c
Am 20.02.2016 um 01:11 schrieb Junio C Hamano:
Stefan Beller writes:
On Fri, Feb 19, 2016 at 2:29 PM, Junio C Hamano wrote:
Stefan Beller writes:
Doing a 'git fetch' only and not the fetch for the specific sha1 would be
incorrect?
I thought that was what you are attempting to address.
Moritz Neeb writes:
> The line read from the branch file is directly trimmed after reading with
> strbuf_trim(). There is thus no logic expecting CR, so strbuf_getline_lf()
> can be replaced by its CRLF counterpart.
>
> Signed-off-by: Moritz Neeb
> ---
> To be honest, I did not yet fully underst
"Felipe Gonçalves Assis" writes:
> 10ae752 (merge-recursive: option to specify rename threshold,
> 2010-09-27) introduced this feature but did not include any tests.
>
> The tests use the new option --find-renames, which replaces the then
> introduced and now deprecated option --rename-threshold
Jeff King writes:
> On Mon, Feb 22, 2016 at 09:43:25AM -0800, Junio C Hamano wrote:
>
>> larsxschnei...@gmail.com writes:
>>
>> > +test_expect_success '--show-origin with --list' '
>> > + cat >expect <<-EOF &&
>> > + file:$HOME/.gitconfig user.global=true
>> > + file:$HOME/.
On Mon, Feb 22, 2016 at 01:06:45PM -0500, Jeff King wrote:
> I have a feeling you were confused by the fact that fill_textconv()
> does:
Looking over it, I agree this is a pretty confusing interface that grew
out of control over time. But refactoring it is kind of tricky, because
we really do wa
On Mon, Feb 22, 2016 at 01:06:46PM -0500, Jeff King wrote:
> Is there a case I'm missing here where we actually leak memory or try to
> free non-allocated memory? I didn't see it.
By the way, I saw only patches 2/3 and 3/3 on the list. So maybe there
is something interesting going on in 1/3, or i
On Mon, Feb 22, 2016 at 07:52:25PM +0700, Nguyễn Thái Ngọc Duy wrote:
> fill_textconv() have four code paths to return a new buffer. Two of
> them, run_textconv() and notes_cache_get(), return a newly allocated
> buffer. The other two return either a constant string or an existing
> buffer (mmfile
Eric Wong writes:
> The following changes since commit 0233b800c838ddda41db318ee396320b3c21a560:
>
> Merge branch 'maint' (2016-02-17 10:14:39 -0800)
>
> are available in the git repository at:
>
> git://bogomips.org/git-svn.git ks/svn-pathnameencoding-4
>
> for you to fetch changes up to 1b4
On Mon, Feb 22, 2016 at 09:43:25AM -0800, Junio C Hamano wrote:
> larsxschnei...@gmail.com writes:
>
> > +test_expect_success '--show-origin with --list' '
> > + cat >expect <<-EOF &&
> > + file:$HOME/.gitconfig user.global=true
> > + file:$HOME/.gitconfig user.override=
Michael J Gruber writes:
>> That is rather unfortunate. Most of them predate the "worktree"
>> subcommand, I think, and having to rename them merely because a
>> subcommand with a confusing name appeared sound somewhat backwards.
>
> The question is: What ist the way forward?
Probably many. Ta
larsxschnei...@gmail.com writes:
> +test_expect_success '--show-origin with --list' '
> + cat >expect <<-EOF &&
> + file:$HOME/.gitconfig user.global=true
> + file:$HOME/.gitconfig user.override=global
> + file:$HOME/.gitconfig
> include.path=$INCLUDE
On Mon, Feb 22, 2016 at 05:24:15PM +0530, Nagaraj Mandya wrote:
> Hello,
> In our GIT repository, all users are restricted from merging to
> master without a pull request. This works well and all developers are
> raising pull requests and merging. However, if there is a merge
> conflict during th
1 - 100 of 142 matches
Mail list logo
