Re: whither merge-tree?

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.

[PATCH 3/3] credential-cache--daemon: change to the socket dir on startup

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

[PATCH 2/3] credential-cache--daemon: disallow relative socket path

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

[PATCH 1/3] credential-cache--daemon: refactor check_socket_directory

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

[PATCH 0/3] credential-cache: give daemon a predictable cwd

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

Re: [PATCH 1/3] t3034: add rename threshold tests

"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

Re: [PATCH] git-p4.py: Make submit working on bare repository

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

Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info

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

Re: [PATCH 2/2] submodule: Try harder to fetch needed sha1 by direct fetching sha1

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

Re: whither merge-tree?

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

Re: [PATCH v2] tests: remove no-op full-svn-test target

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. > >

[PATCH v2] tests: remove no-op full-svn-test target

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

Re: Git Daemon Dummy: 301 Redirects for git:// to https://

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

[PATCH 3/3] xdiff: drop XDL_EMIT_COMMON

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

[PATCH 2/3] merge-tree: drop generate_common strategy

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

[PATCH 1/3] merge-one-file: use empty blob for add/add base

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

Re: whither merge-tree?

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 >

Re: [PATCH 1/1] convert.c: correct attr_action

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

Re: whither merge-tree?

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

Re: whither merge-tree?

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

[PATCH 3/3] t3034: test deprecated interface

--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

[PATCH 2/3] t3034: test option to disable renames

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

[PATCH 1/3] t3034: add rename threshold tests

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

[PATCH 0/3] Tests for merge-recursive rename options

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

Re: Question about pull-requests

>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.

Re: [PATCH] git-p4.py: Make submit working on bare repository

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

Git Daemon Dummy: 301 Redirects for git:// to https://

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

Re: [RFC/PATCH 1/1] format-patch: add an option to record base tree info

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

Re: [PATCH] daemon.c: mark a file-local symbol as static

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

[PATCH] refs: reduce the visibility of do_for_each_ref()

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

Re: [PATCH 2/2] submodule: Try harder to fetch needed sha1 by direct fetching sha1

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

Re: [PATCH 2/2] submodule: Try harder to fetch needed sha1 by direct fetching sha1

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

Re: [PATCH 3/3] Correct conditions to free textconv result data

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 >

Re: [PATCH 1/2] submodule: Include check for objects when fetching

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

Re: [PATCH v3 0/22] hardening allocations against integer overflow

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

Re: [PATCH 3/3] Correct conditions to free textconv result data

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.

Re: [PATCH 1/2] submodule: Include check for objects when fetching

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

Re: [PATCH 3/3] Correct conditions to free textconv result data

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

Re: [PATCH] diff: clarify textconv interface

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

Re: [PATCH 1/2] submodule: Include check for objects when fetching

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

Re: whither merge-tree?

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,

[PATCH v3 21/22] convert ewah/bitmap code to use xmalloc

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

[PATCH v3 22/22] ewah: convert to REALLOC_ARRAY, etc

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 ++---

[PATCH v3 18/22] git-compat-util: drop mempcpy compat code

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,

[PATCH v3 20/22] diff_populate_gitlink: use a strbuf

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

[PATCH v3 16/22] test-path-utils: fix normalize_path_copy output buffer size

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

[PATCH v3 17/22] sequencer: simplify memory allocation of get_message

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

[PATCH v3 10/22] convert trivial cases to FLEX_ARRAY macros

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

[PATCH v3 12/22] prepare_{git,shell}_cmd: use argv_array

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

[PATCH v3 13/22] write_untracked_extension: use FLEX_ALLOC helper

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

[PATCH v3 15/22] fetch-pack: simplify add_sought_entry

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

[PATCH v3 14/22] fast-import: simplify allocation in start_packfile

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

[PATCH v3 19/22] transport_anonymize_url: use xstrfmt

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

[PATCH v3 11/22] use st_add and st_mult for allocation size computation

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.

[PATCH v3 09/22] use xmallocz to avoid size arithmetic

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

[PATCH v3 06/22] argv-array: add detach function

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

[PATCH v3 07/22] convert manual allocations to argv_array

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

[PATCH v3 08/22] convert trivial cases to ALLOC_ARRAY

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

[PATCH v3 03/22] tree-diff: catch integer overflow in combine_diff_path allocation

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

[PATCH v3 05/22] add helpers for allocating flex-array structs

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

[PATCH v3 01/22] reflog_expire_cfg: NUL-terminate pattern field

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

[PATCH v3 02/22] add helpers for detecting size_t overflow

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

[PATCH v3 04/22] harden REALLOC_ARRAY and xcalloc against size_t overflow

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()

[PATCH v3 0/22] hardening allocations against integer overflow

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:

[PATCH 2/2] submodule: Try harder to fetch needed sha1 by direct fetching sha1

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

Re: [PATCH v2 0/5] Tests and fixes for merge-recursive rename options

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

[PATCH 1/2] submodule: Include check for objects when fetching

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

[PATCH 0/2] Submodule harden fetches (WAS: submodule: Fetch the direct sha1 first)

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

Re: [PATCH v2 0/5] Tests and fixes for merge-recursive rename options

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

Re: [PATCH 1/2] t8005: avoid grep on non-ASCII data

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

Re: [PATCH 2/2] t9200: avoid grep on non-ASCII data

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

[ANNOUNCE] Git v2.7.2

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 =

What's cooking in git.git (Feb 2016, #06; Mon, 22)

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

Re: [PATCH 1/2] t8005: avoid grep on non-ASCII data

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

Re: [PATCH v2 0/5] Tests and fixes for merge-recursive rename options

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

whither merge-tree? (was: What's cooking in git.git (Feb 2016, #05; Wed, 17))

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

Re: GSoC 2016: applications open, deadline = Fri, 19/2

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

Re: GSoC 2016: applications open, deadline = Fri, 19/2

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

Re: GSoC 2016: applications open, deadline = Fri, 19/2

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

Re: Question about pull-requests

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

Re: [PATCH] daemon.c: mark a file-local symbol as static

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:

Re: A different bug in git-filter-branch (v2.7.0)

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

Re: [PATCH v2 0/5] Tests and fixes for merge-recursive rename options

"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. > >

[PATCH] Add --recursive flag to git bash completion script.

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

Re: [RFC PATCH] lmdb: restrict the visibility of some symbols

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, >

Re: [PATCH v2 3/6] clean: read user input with strbuf_getline()

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

Re: [PATCH v2 6/6] wt-status: read rebase todolist with strbuf_getline()

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) >

Re: [PATCH v2 4/6] notes: read copied notes with strbuf_getline()

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

Re: [PATCH] submodule: Fetch the direct sha1 first

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

Re: [PATCH v2 5/6] remote: read $GIT_DIR/branches/* with strbuf_getline()

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 > ---

Re: [PATCH v2 2/5] t3034: add rename threshold tests

"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

Re: [PATCH v6 4/4] config: add '--show-origin' option to print the origin of a config value

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 >> > +

[PATCH] diff: clarify textconv interface

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

Re: [PATCH 3/3] Correct conditions to free textconv result data

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

Re: [PATCH 3/3] Correct conditions to free textconv result data

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

Re: [PATCH v4 0/3] git-svn: svn.pathnameencoding for dcommit

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

Re: [PATCH v6 4/4] config: add '--show-origin' option to print the origin of a config value

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

Re: [PATCH] tests: rename work-tree tests to *work-tree*

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

Re: [PATCH v6 4/4] config: add '--show-origin' option to print the origin of a config value

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 >

Re: Question about pull-requests

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

  1   2   >