Re: [PATCH 1/3] upload-pack: send the HEAD information

On Fri, Sep 06, 2013 at 10:46:24AM -0700, Junio C Hamano wrote: > I think it is perfectly fine to expose _only_ HEAD now, and wait > until we find a good reason that we should send this information for > other symbolic refs in the repository. Yeah, I agree with that. > However, because we alread

Re: [PATCH 0/3] Reject non-ff pulls by default

On Sun, Sep 8, 2013 at 1:54 AM, Jeff King wrote: > On Sun, Sep 08, 2013 at 01:17:42AM -0500, Felipe Contreras wrote: > >> > I think it's fine to tell them to do "git pull --merge". What I'd worry >> > more about is somebody who is suddenly presented with the choice between >> > "--rebase" and "--m

[PATCH v2 00/14] pack v4 support in index-pack

Mostly cleanups after Nico's comments. The diff against v2 is diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 4a24bc3..88340b5 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -22,8 +22,8 @@ struct object_entry { struct pack_idx_entry idx; unsigned lon

[PATCH v2 05/14] index-pack: do not allocate buffer for unpacking deltas in the first pass

We do need deltas until the second pass. Allocating a buffer for it then freeing later is wasteful is unnecessary. Make it use fixed_buf (aka large blob code path). --- builtin/index-pack.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/builtin/index-pack.c b/builtin/index-p

[PATCH v2 04/14] index-pack: split out varint decoding code

--- builtin/index-pack.c | 82 1 file changed, 45 insertions(+), 37 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 1dbabe0..5fbd517 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -277,6 +277,31 @@ s

[PATCH v2 02/14] pack v4: add pv4_free_dict()

--- packv4-parse.c | 8 packv4-parse.h | 1 + sha1_file.c| 2 ++ 3 files changed, 11 insertions(+) diff --git a/packv4-parse.c b/packv4-parse.c index 82661ba..d515bb9 100644 --- a/packv4-parse.c +++ b/packv4-parse.c @@ -63,6 +63,14 @@ struct packv4_dict *pv4_create_dict(const unsigne

[PATCH v2 07/14] index-pack: parse v4 header and dictionaries

--- builtin/index-pack.c | 49 - 1 file changed, 48 insertions(+), 1 deletion(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 3389262..83e6e79 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -11,6 +11,7 @@ #include

[PATCH v2 06/14] index-pack: split inflate/digest code out of unpack_entry_data

--- builtin/index-pack.c | 62 +++- 1 file changed, 37 insertions(+), 25 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 78554d0..3389262 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -431,6 +431,40 @@ s

[PATCH v2 03/14] index-pack: add more comments on some big functions

--- builtin/index-pack.c | 30 ++ 1 file changed, 26 insertions(+), 4 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 9c1cfac..1dbabe0 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -19,8 +19,8 @@ struct object_entry {

[PATCH v2 01/14] pack v4: split pv4_create_dict() out of load_dict()

--- packv4-parse.c | 63 -- packv4-parse.h | 8 2 files changed, 43 insertions(+), 28 deletions(-) diff --git a/packv4-parse.c b/packv4-parse.c index 63bba03..82661ba 100644 --- a/packv4-parse.c +++ b/packv4-parse.c @@ -30,11 +30,3

[PATCH v2 13/14] index-pack: skip looking for ofs-deltas in v4 as they are not allowed

--- builtin/index-pack.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index e903a49..ce06473 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -1173,10 +1173,13 @@ static struct base_data *find_unresolved

[PATCH v2 11/14] index-pack: move delta base queuing code to unpack_raw_entry

For v2, ofs-delta and ref-delta can only have queue one delta base at a time. A v4 tree can have more than one delta base. Move the queuing code up to unpack_raw_entry() and give unpack_tree_v4() more flexibility to add its bases. --- builtin/index-pack.c | 46 ++---

[PATCH v2 09/14] index-pack: parse v4 commit format

--- builtin/index-pack.c | 94 ++-- 1 file changed, 91 insertions(+), 3 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index efb969a..473514a 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -319,6 +319,30 @@ st

[PATCH v2 08/14] index-pack: make sure all objects are registered in v4's SHA-1 table

--- builtin/index-pack.c | 22 -- 1 file changed, 20 insertions(+), 2 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 83e6e79..efb969a 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -288,6 +288,19 @@ static inline void *fill_and_use

[PATCH v2 12/14] index-pack: record all delta bases in v4 (tree and ref-delta)

--- builtin/index-pack.c | 33 ++--- 1 file changed, 30 insertions(+), 3 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 8f2d929..e903a49 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -24,6 +24,7 @@ struct object_entry {

[PATCH v2 14/14] index-pack: resolve v4 one-base trees

This is the most common case for delta trees. In fact it's the only kind that's produced by packv4-create. It fits well in the way index-pack resolves deltas and benefits from threading (the set of objects depending on this base does not overlap with the set of objects depending on another base) M

[PATCH v2 10/14] index-pack: parse v4 tree format

--- builtin/index-pack.c | 105 +-- 1 file changed, 101 insertions(+), 4 deletions(-) diff --git a/builtin/index-pack.c b/builtin/index-pack.c index 473514a..dcb6409 100644 --- a/builtin/index-pack.c +++ b/builtin/index-pack.c @@ -334,6 +334,14 @@ s

Re: [PATCH 1/3] upload-pack: send the HEAD information

On Sun, Sep 08, 2013 at 03:13:59AM -0400, Jeff King wrote: > What do you think about teaching git to read extra data after "\0" for > _every_ ref line? And then ref advertisement might look something like: > >HEAD\0multi_ack thin-pack ... symref=refs/heads/master\n >refs/heads/master\n >

Re: Officially start moving to the term 'staging area'

From: "Felipe Contreras" Sent: Sunday, September 08, 2013 2:33 AM [snip...] The snapshot concept is totally orthogonal from the staging area concept. Git works in snapshots, which are frozen images of how the content tree was at a certain point in time; IOW; a commit. (I feel that) In most peo

Re: [PATCH 0/3] Reject non-ff pulls by default

On Sun, Sep 08, 2013 at 02:15:17AM -0500, Felipe Contreras wrote: > > I think "the guy" may be git itself. For example, here is a possible > > session with jc/pull-training-wheel: > > > > $ git push > > Who told him to use 'git push'? Certainly not git. Any of the hundreds of existing tutorial

Re: [PATCH 0/3] Reject non-ff pulls by default

From: "Felipe Contreras" Sent: Sunday, September 08, 2013 3:34 AM On Thu, Sep 5, 2013 at 3:06 AM, John Keeping wrote: On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote: Are there cases where you do not want to either rebase nor merge? If so what do you want to do after "git pull"

Re: Git tag output order is incorrect (IMHO)

On Tue, Aug 20, 2013 at 05:12:47PM +0200, Antoine Pelisse wrote: > On Sat, Jul 20, 2013 at 2:22 AM, Jeff King wrote: > > I do plan to finish it eventually, but if anyone else feels like picking > > it up, I'd be glad to review patches and/or share my work-in-progress as > > a starting point. > >

Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

From: "Jeff King" Sent: Sunday, September 08, 2013 5:06 AM Was there some objective argument made that I missed? Here's more; human semantics: Isn't this one of those "pick any two from three" tasks: 'human', 'objective', 'argument'. Only 1/6 of the time is an 'objective' answer the re

Re: [PATCH 0/3] Reject non-ff pulls by default

On Sun, Sep 8, 2013 at 3:01 AM, Philip Oakley wrote: > From: "Felipe Contreras" > Sent: Sunday, September 08, 2013 3:34 AM > >> On Thu, Sep 5, 2013 at 3:06 AM, John Keeping wrote: >>> >>> On Wed, Sep 04, 2013 at 03:59:18PM -0700, Junio C Hamano wrote: Are there cases where you do not w

[PATCHv2 0/5] git-config and large integers

Here's a re-roll (and re-design) of my series to help with "git config" and large integers. It takes the different approach we discussed of simply removing (well, increasing) the range limits for "git config --int". I also improved the error messages for bogus config (patches 3-4). [1/5]: confi

[PATCH 1/5] config: factor out integer parsing from range checks

When we are parsing integers for config, we use an intmax_t (or uintmax_t) internally, and then check against the size of our result type at the end. We can parameterize the maximum representable value, which will let us re-use the parsing code for a variety of range checks. Unfortunately, we cann

[PATCH 2/5] config: properly range-check integer values

When we look at a config value as an integer using the git_config_int function, we carefully range-check the value we get and complain if it is out of our range. But the range we compare to is that of a "long", which we then cast to an "int" in the function's return value. This means that on system

[PATCH 3/5] config: set errno in numeric git_parse_* functions

When we are parsing an integer or unsigned long, we use the strto*max functions, which properly set errno to ERANGE if we get a large value. However, we also do further range checks after applying our multiplication factor, but do not set ERANGE. This means that a caller cannot tell if an error was

[PATCH 4/5] config: make numeric parsing errors more clear

If we try to parse an integer config argument and get a number outside of the representable range, we die with the cryptic message: "bad config value for '%s'". We can improve two things: 1. Show the value that produced the error (e.g., bad config value '3g' for 'foo.bar'). 2. Mention t

[PATCH 5/5] git-config: always treat --int as 64-bit internally

When you run "git config --int", the maximum size of integer you get depends on how git was compiled, and what it considers to be an "int". This is almost useful, because your scripts calling "git config" will behave similarly to git internally. But relying on this is dubious; you have to actually

Re: [PATCH 0/3] Reject non-ff pulls by default

From: "Felipe Contreras" To: "Philip Oakley" Cc: "John Keeping" ; "Junio C Hamano" ; ; "Andreas Krey" Sent: Sunday, September 08, 2013 9:16 AM Subject: Re: [PATCH 0/3] Reject non-ff pulls by default On Sun, Sep 8, 2013 at 3:01 AM, Philip Oakley wrote: From: "Felipe Contreras" Sent: Sun

Re: [PATCH 0/3] Reject non-ff pulls by default

On Sun, Sep 8, 2013 at 2:50 AM, Jeff King wrote: > On Sun, Sep 08, 2013 at 02:15:17AM -0500, Felipe Contreras wrote: > >> > I think "the guy" may be git itself. For example, here is a possible >> > session with jc/pull-training-wheel: >> > >> > $ git push >> >> Who told him to use 'git push'? Ce

Re: [PATCH 0/3] Reject non-ff pulls by default

On Sun, Sep 8, 2013 at 3:42 AM, Philip Oakley wrote: > The 'problem' is (would be) that I don't yet know that I would need the > --onto pu until I discover (how?) that the default rebase would result in > conflicts. I don't see what that has to do with an invocation of 'git rebase' without argum

[PATCH 0/2] upload-pack keepalive

I've gotten complaints that cloning from github.com with "-q" will sometimes abort before sending any data. The problem is that during a quiet clone, upload-pack may be silent for a long time while preparing the pack (i.e., the "counting objects" and "compressing" phases). We have load balancers a

[PATCH 2/2] upload-pack: bump keepalive default to 5 seconds

From: Jeff King There is no reason not to turn on keepalives by default. They take very little bandwidth, and significantly less than the progress reporting they are replacing. And in the case that progress reporting is on, we should never need to send a keepalive anyway, as we will constantly be

[PATCH 1/2] upload-pack: send keepalive packets during pack computation

Whenn upload-pack has started pack-objects, there may be a quiet period while pack-objects prepares the pack (i.e., counting objects and delta compression). Normally we would see (and send to the client) progress information, but if "--quiet" is in effect, pack-objects will produce nothing at all

Re: Officially start moving to the term 'staging area'

On Sun, Sep 8, 2013 at 2:49 AM, Philip Oakley wrote: > From: "Felipe Contreras" > Sent: Sunday, September 08, 2013 2:33 AM > [snip...] > >> The snapshot concept is totally orthogonal from the staging area >> concept. Git works in snapshots, which are frozen images of how the >> content tree was a

Re: [PATCH 0/3] Reject non-ff pulls by default

From: "Felipe Contreras" Sent: Sunday, September 08, 2013 9:49 AM On Sun, Sep 8, 2013 at 3:42 AM, Philip Oakley wrote: The 'problem' is (would be) that I don't yet know that I would need the --onto pu until I discover (how?) that the default rebase would result in conflicts. I don't see

Re: [PATCH 0/3] Reject non-ff pulls by default

On Sun, Sep 08, 2013 at 02:54:20AM -0400, Jeff King wrote: > I am genuinely curious what people in favor of this feature would want > to say in the documentation to a user encountering this choice for the > first time. In my experience, rebasing introduces more complications, > specifically: > >

Re: [PATCH v3] Teach git to change to a given directory using -C option

On Wed, Sep 4, 2013 at 8:20 AM, Nazri Ramliy wrote: > Subject: git: run in a directory given with -C option > > This is similar in spirit to to "make -C dir ..." and "tar -C dir ...". > --- > diff --git a/Documentation/git.txt b/Documentation/git.txt > index 83edf30..ae049da 100644 > --- a/Documen

Re: [PATCH 0/3] Reject non-ff pulls by default

From: "Philip Oakley" [2] http://dx.doi.org/10.%2F1467-8721.01235 "Why People Fail to Recognize Their Own Incompetence". Oops, That's behind a paywall, and a more recent variant. Though the corollaries (People fail to recognise their own skills, a

[PATCH] Doc: 'replace' merge and non-merge commits

Merges are often treated as special case objects so tell users that they are not special here. Signed-off-by: Philip Oakley --- This updates my in-line patch given in [PATCH v3 07/11] Documentation/replace: tell that -f option bypasses the type check ($gmane/233997 05 September 2013 23:20) and J

Bash completion doing full tree traversal?

I experienced a weird stall from git bash completion: $ git add p I did some investigation and found this call trace: + __git_index_files '--others --modified' '' ---> git ls-files --exclude-standard --others --modified This bash function captures output of the git call and strips all but the

Re: [PATCH] dir: remove dead code

Am 08.09.2013 08:09, schrieb Ramkumar Ramachandra: Remove dead code around remove_dir_recursively(). This basically reverts ae2f203e (clean: preserve nested git worktree in subdirectories). t7300 still seems to pass, though. I wonder why. Signed-off-by: Ramkumar Ramachandra --- dir.c |

[PATCH 04/11] pack v4: add version argument to write_pack_header

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/pack-objects.c | 2 +- bulk-checkin.c | 2 +- pack-write.c | 7 +-- pack.h | 3 +-- 4 files changed, 8 insertions(+), 6 deletions(-) diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index f069462..

[PATCH 05/11] pack-write.c: add pv4_encode_in_pack_object_header

Signed-off-by: Nguyễn Thái Ngọc Duy --- pack-write.c | 29 + pack.h | 1 + 2 files changed, 30 insertions(+) diff --git a/pack-write.c b/pack-write.c index 88e4788..6f11104 100644 --- a/pack-write.c +++ b/pack-write.c @@ -1,6 +1,7 @@ #include "cache.h" #incl

[PATCH 07/11] list-objects.c: add show_tree_entry callback to traverse_commit_list

This helps construct tree dictionary in pack v4. Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/pack-objects.c | 2 +- builtin/rev-list.c | 4 ++-- list-objects.c | 9 - list-objects.h | 3 ++- upload-pack.c | 2 +- 5 files changed, 14 insertions(+), 6 delet

[PATCH 00/11] pack v4 support in pack-objects

I can produce pack v4 on git.git with this and verify it with index-pack. I'm not familiar with pack-objects code and not really confident with my changes. Suggestions are welcome. Also I chose to keep packv4-create.c in libgit.a and move test code out to test-packv4.c. Not sure if it's good decis

[PATCH 06/11] pack-objects: add --version to specify written pack version

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/pack-objects.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index 33faea8..ef68fc5 100644 --- a/builtin/pack-objects.c +++ b/builtin/pack-objects.c @@ -81,6 +81,7 @@ static

[PATCH 01/11] pack v4: allocate dicts from the beginning

commit_ident_table and tree_path_table are local to packv4-create.c and test-packv4.c. Move them out of add_*_dict_entries so add_*_dict_entries can be exported to pack-objects.c Signed-off-by: Nguyễn Thái Ngọc Duy --- packv4-create.c | 22 -- 1 file changed, 12 insertions(+)

[PATCH 03/11] pack v4: move packv4-create.c to libgit.a

git-packv4-create now becomes test-packv4. Code that will not be used by pack-objects.c is moved to test-packv4.c. It may be removed when the code transition to pack-objects completes. Signed-off-by: Nguyễn Thái Ngọc Duy --- Makefile| 4 +- packv4-create.c | 491 +--

[PATCH 02/11] pack v4: stop using static/global variables in packv4-create.c

Signed-off-by: Nguyễn Thái Ngọc Duy --- packv4-create.c | 103 -- packv4-create.h (new) | 11 ++ 2 files changed, 69 insertions(+), 45 deletions(-) create mode 100644 packv4-create.h diff --git a/packv4-create.c b/packv4-create.c index

[PATCH 09/11] pack-objects: do not cache delta for v4 trees

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/pack-objects.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index 69a22c1..665853d 100644 --- a/builtin/pack-objects.c +++ b/builtin/pack-objects.c @@ -1759,8 +1759,12 @@ s

[PATCH 10/11] pack-objects: exclude commits out of delta objects in v4

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/pack-objects.c | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index 665853d..daa4349 100644 --- a/builtin/pack-objects.c +++ b/builtin/pack-objects.c @@ -1332,7 +1332,8 @@ sta

[PATCH 11/11] pack-objects: support writing pack v4

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/pack-objects.c | 85 -- pack.h | 2 +- 2 files changed, 76 insertions(+), 11 deletions(-) diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index daa4349..f6586a1 100644 -

[PATCH 08/11] pack-objects: create pack v4 tables

Signed-off-by: Nguyễn Thái Ngọc Duy --- builtin/pack-objects.c | 87 -- 1 file changed, 85 insertions(+), 2 deletions(-) diff --git a/builtin/pack-objects.c b/builtin/pack-objects.c index b38d3dc..69a22c1 100644 --- a/builtin/pack-objects.c +++ b/

[PATCH] pull: use $curr_branch_short more

One of the first things git-pull.sh does is setting $curr_branch to the target of HEAD and $curr_branch_short to the same but with the leading "refs/heads/" removed. Simplify the code by using $curr_branch_short instead of setting $curr_branch to the same shortened value. The only other use of $c

Re: [PATCH] branch: use $curr_branch_short more

Am 31.08.2013 19:20, schrieb Felipe Contreras: A summary should contain as much information that would allow me to skip the commit message as possible. If I can't tell from the summary if I can safely skip the commit message, the summary is not doing a good job. "trivial simplification" explain

Re: [PATCH] dir: remove dead code

Am 08.09.2013 16:42, schrieb Ramkumar Ramachandra: On Sun, Sep 8, 2013 at 6:00 PM, René Scharfe mailto:l@web.de>> wrote: Am 08.09.2013 08:09, schrieb Ramkumar Ramachandra: Remove dead code around remove_dir_recursively(). This basically reverts ae2f203e (clean: preserve ne

[PATCH] l10n: de.po: use "das Tag" instead of "der Tag"

Use "das Tag" to avoid confusion with the German word "Tag" (day). Reported-by: Dirk Heinrichs Signed-off-by: Ralf Thielow --- po/de.po | 22 +++--- 1 file changed, 11 insertions(+), 11 deletions(-) diff --git a/po/de.po b/po/de.po index 11dde11..f4076fb 100644 --- a/po/de.po +

Re: [PATCH 0/3] Reject non-ff pulls by default

On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote: > On Sat, Sep 7, 2013 at 11:18 PM, Jeff King wrote: > > By "svn-like", I mean the people whose workflow is: > > > > $ hack hack hack > > $ git commit > > $ git push ;# oops, somebody else pushed in the meantime > > $ git pul

Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.

"Philip Oakley" writes: > What I observed was that all the clones had the same HEAD problem, > which I think comes from clone.c: guess_remote_head(). Yes. They share "having to guess" property because their data source does not tell them. > My quick look at clone.c suggested to me that there w

Re: [PATCH 0/3] Reject non-ff pulls by default

Richard Hansen writes: > On 2013-09-07 22:41, Felipe Contreras wrote: >> On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano wrote: >> >>> Which can be solved by adding the above "fail" option, and then >>> renaming them to "pull.integrate" and "branch..integrate" to >>> clarify what these variables

[PATCH] http-backend: provide Allow header for 405

The HTTP 1.1 standard requires an Allow header for 405 Method Not Allowed: The response MUST include an Allow header containing a list of valid methods for the requested resource. So provide such a header when we return a 405 to the user agent. Signed-off-by: brian m. carlson --- http-back

Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

Jeff King writes: >> A(ny) sanely defined "compare A with B" function should yield the >> result of subtracting B from A, i.e. cmp(A,B) should be like (A-B). >> That is what you feed qsort() and bsearch() (it is not limited to C; >> you see the same in "sort { $a <=> $b }"). The definition natur

Re: [PATCH 0/3] Reject non-ff pulls by default

On 2013-09-08 14:10, Junio C Hamano wrote: > Richard Hansen writes: >> What about something like: >> >> pull.mergeoptions (defaults to --ff-only) >> pull.rebaseoptions (defaults to empty? --preserve-merges?) >> branch..pull.mergeoptions (defaults to pull.mergeoptions) >> branch..p

[BUG] rebase not recovering gracefully from repack error

(patches|REBASE 8/9)$ git rebase --continue Applying: Check for __unix__ instead of __linux Applying: Completely disable crash handler on archs other than i386 and amd64 Auto packing the repository for optimum performance. You may also run "git gc" manually. See "git help gc" for more information.

Re: [PATCH 05/11] pack-write.c: add pv4_encode_in_pack_object_header

On Sun, 8 Sep 2013, Nguyễn Thái Ngọc Duy wrote: > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > pack-write.c | 29 + > pack.h | 1 + > 2 files changed, 30 insertions(+) > > diff --git a/pack-write.c b/pack-write.c > index 88e4788..6f11104 100644 > --- a/pack-

[PATCH] send-email: don't call methods on undefined values

If SSL verification is enabled in git send-email, we could attempt to call a method on an undefined value if the verification failed, since $smtp would end up being undef. Look up the error string in a way that will produce a helpful error message and not cause further errors. Signed-off-by: bria

Re: [PATCH 03/11] pack v4: move packv4-create.c to libgit.a

On Sun, 8 Sep 2013, Nguyễn Thái Ngọc Duy wrote: > git-packv4-create now becomes test-packv4. Code that will not be used > by pack-objects.c is moved to test-packv4.c. It may be removed when > the code transition to pack-objects completes. > > Signed-off-by: Nguyễn Thái Ngọc Duy > --- > Makefile

[PATCHv2 0/5] branch: Fix --track on a remote-tracking non-branch

Hi, Here is the second iteration of this series. Only one change from the first iteration: The first patch now also fixes some missing &&-chaining noticed by Junio in t2024. ...Johan Johan Herland (4): t2024: Fix &&-chaining and a couple of typos t3200: Minor fix when preparing for tracking

[PATCHv2 1/5] t2024: Fix &&-chaining and a couple of typos

Improved-by: Junio C Hamano Signed-off-by: Johan Herland --- t/t2024-checkout-dwim.sh | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/t/t2024-checkout-dwim.sh b/t/t2024-checkout-dwim.sh index dee55e4..094b92e 100755 --- a/t/t2024-checkout-dwim.sh +++ b/t/t2024-checkout-

[PATCHv2 4/5] t3200: Add test demonstrating minor regression in 41c21f2

In 41c21f2 (branch.c: Validate tracking branches with refspecs instead of refs/remotes/*), we changed the rules for what is considered a valid tracking branch (a.k.a. upstream branch). We now use the configured remotes and their refspecs to determine whether a proposed tracking branch is in fact wi

[PATCHv2 5/5] branch.c: Relax unnecessary requirement on upstream's remote ref name

From: Per Cederqvist When creating an upstream relationship, we use the configured remotes and their refspecs to determine the upstream configuration settings branch..remote and branch..merge. However, if the matching refspec does not have refs/heads/ on the remote side, we end up rejecting the m

[PATCHv2 2/5] t3200: Minor fix when preparing for tracking failure

We're testing that trying to --track a ref that is not covered by any remote refspec should fail. For that, we want to have refs/remotes/local/master present, but we also want the remote.local.fetch refspec to NOT match refs/remotes/local/master (so that the tracking setup will fail, as intended).

[PATCHv2 3/5] Refer to branch..remote/merge when documenting --track

Make it easier for readers to find the actual config variables that implement the "upstream" relationship. Suggested-by: Per Cederqvist Signed-off-by: Johan Herland --- Documentation/git-branch.txt | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/Documentation/git-branc

Re: [PATCH 0/3] Unconfuse git clone when two branches at are HEAD.

From: "Junio C Hamano" Sent: Sunday, September 08, 2013 6:35 PM "Philip Oakley" writes: What I observed was that all the clones had the same HEAD problem, which I think comes from clone.c: guess_remote_head(). Yes. They share "having to guess" property because their data source does not te

Re: [PATCH 0/3] Reject non-ff pulls by default

On Sun, Sep 8, 2013 at 12:26 PM, brian m. carlson wrote: > On Sat, Sep 07, 2013 at 11:37:13PM -0500, Felipe Contreras wrote: >> On Sat, Sep 7, 2013 at 11:18 PM, Jeff King wrote: >> > $ hack hack hack >> > $ svn commit ;# oops, somebody else committed in the meantime >> > $ svn update >> >

Re: [PATCH 0/3] Reject non-ff pulls by default

From: "Junio C Hamano" Sent: Sunday, September 08, 2013 7:10 PM Richard Hansen writes: On 2013-09-07 22:41, Felipe Contreras wrote: On Wed, Sep 4, 2013 at 5:59 PM, Junio C Hamano wrote: Which can be solved by adding the above "fail" option, and then renaming them to "pull.integrate" and

Re: [PATCH 0/3] Reject non-ff pulls by default

On Sun, Sep 8, 2013 at 1:10 PM, Junio C Hamano wrote: > pull. = rebase | merge [| always-fail] > > makes that choice in a clear way, I think. > > Regarding the verb "integrate". I doubt anybody thinks of pull being an "integration", and even if it is, it's still doesn't explain what 'integra

[PATCH] sequencer: trivial cleanup

Signed-off-by: Ramkumar Ramachandra --- sequencer.c | 5 + 1 file changed, 1 insertion(+), 4 deletions(-) diff --git a/sequencer.c b/sequencer.c index 351548f..8ed9f98 100644 --- a/sequencer.c +++ b/sequencer.c @@ -466,10 +466,7 @@ static int allow_empty(struct replay_opts *opts, struct com

Re: Git tag output order is incorrect (IMHO)

On Thu, Jul 18, 2013 at 10:27 AM, Rahul Bansal wrote: > I am posting here first time, so please excuse me if this is not right place > to send something like this. > > Please check - > http://stackoverflow.com/questions/6091306/can-i-make-git-print-x-y-z-style-tag-names-in-a-sensible-order > > A

Re: [PATCH] sequencer: trivial cleanup

On Sun, Sep 8, 2013 at 5:42 PM, Ramkumar Ramachandra wrote: > Signed-off-by: Ramkumar Ramachandra > --- > sequencer.c | 5 + > 1 file changed, 1 insertion(+), 4 deletions(-) > > diff --git a/sequencer.c b/sequencer.c > index 351548f..8ed9f98 100644 > --- a/sequencer.c > +++ b/sequencer.c > @

Re: [PATCH 1/3] reset: add --stage and --work options

On Sun, Sep 8, 2013 at 5:05 PM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> >> @@ -290,6 +294,22 @@ int cmd_reset(int argc, const char **argv, const char >> *prefix) >> hashcpy(sha1, tree->object.sha1); >> } >> >> + if (stage >= 0 || working_tree >= 0) {

Re: [PATCH] sequencer: trivial cleanup

Felipe Contreras wrote: >> sequencer.c | 5 + >> 1 file changed, 1 insertion(+), 4 deletions(-) >> >> diff --git a/sequencer.c b/sequencer.c >> index 351548f..8ed9f98 100644 >> --- a/sequencer.c >> +++ b/sequencer.c >> @@ -466,10 +466,7 @@ static int allow_empty(struct replay_opts *opts, struc

Re: [PATCH 0/3] Reject non-ff pulls by default

Felipe Contreras wrote: > On Sun, Sep 8, 2013 at 1:10 PM, Junio C Hamano wrote: > >> pull. = rebase | merge [| always-fail] >> >> makes that choice in a clear way, I think. The core issue is that users rarely want to merge locally: that's the maintainer's job. Users simply want to rebase, and

Re: [PATCH] branch: use $curr_branch_short more

On Sun, Sep 8, 2013 at 10:21 AM, René Scharfe wrote: > Am 31.08.2013 19:20, schrieb Felipe Contreras: > >> A summary should contain as much information that would allow me to >> skip the commit message as possible. >> >> If I can't tell from the summary if I can safely skip the commit >> message,

Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

On Sun, Sep 8, 2013 at 1:33 PM, Junio C Hamano wrote: > Jeff King writes: > Calling the abstraction "test_diff" might have avoided the wasted > brain bandwidth in this thread, but I do not think renaming it in > test-lib-functions.sh is worth the trouble, either ;-) Yes, but then it wouldn't be

Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

On Sun, Sep 8, 2013 at 12:02 AM, Jeff King wrote: > On Sat, Sep 07, 2013 at 11:52:10PM -0500, Felipe Contreras wrote: > >> > Ah, you mean "if you think that the compare function should behave like >> > C *_cmp functions, it should be A-B". Perhaps it is simply that I do not >> > think of the funct

Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

On Sun, Sep 08, 2013 at 06:25:45PM -0500, Felipe Contreras wrote: > > And I do not think it is a problem. The point of the function is not to > > abstract away the idea of comparison. The point is to give a hook for > > people on systems without "diff -u" to run the test suite. > > The point acco

Re: [PATCH 0/3] Reject non-ff pulls by default

On Sun, Sep 08, 2013 at 05:38:50PM -0500, Felipe Contreras wrote: > Yeah, but the key question at hand in this discussion is; what happens > when 'git pull' stops working for them, and they don't know what to > do, will they choose 'git pull --rebase' by mistake? I agree, they will not choose git

Re: [PATCH 1/3] reset: add --stage and --work options

Felipe Contreras wrote: > Either way it doesn't matter because Junio is determined to stand > alone versus the rest of the world in this issue. Which is why he's the maintainer. Send in incremental updates, and he should be fine. -- To unsubscribe from this list: send the line "unsubscribe git" in

Re: [PATCH] sequencer: trivial cleanup

Hi, On Sun, Sep 08, 2013 at 05:53:19PM -0500, Felipe Contreras wrote: > On Sun, Sep 8, 2013 at 5:42 PM, Ramkumar Ramachandra > wrote: > > Signed-off-by: Ramkumar Ramachandra > > --- > > sequencer.c | 5 + > > 1 file changed, 1 insertion(+), 4 deletions(-) > > > > diff --git a/sequencer.c b

Re: [PATCH 0/3] Reject non-ff pulls by default

On Sun, Sep 8, 2013 at 7:01 PM, brian m. carlson wrote: > On Sun, Sep 08, 2013 at 05:38:50PM -0500, Felipe Contreras wrote: >> Yeah, but the key question at hand in this discussion is; what happens >> when 'git pull' stops working for them, and they don't know what to >> do, will they choose 'git

Re: [PATCH 3/5] config: set errno in numeric git_parse_* functions

On Sun, Sep 8, 2013 at 4:36 AM, Jeff King wrote: > When we are parsing an integer or unsigned long, we use > the strto*max functions, which properly set errno to ERANGE > if we get a large value. However, we also do further range > checks after applying our multiplication factor, but do not > set

Re: [PATCH 0/3] Reject non-ff pulls by default

On Sun, Sep 8, 2013 at 7:29 PM, Felipe Contreras wrote: > My patches pretty much do nothing else but introduce a warning. > Nothing is broken, nothing is changed in the test suite: > > http://article.gmane.org/gmane.comp.version-control.git/233669 > > You are confusing my proposal with Junio's on

Re: [PATCH 0/3] Reject non-ff pulls by default

On Sun, Sep 08, 2013 at 07:36:21PM -0500, Felipe Contreras wrote: > On Sun, Sep 8, 2013 at 7:29 PM, Felipe Contreras > wrote: > > > My patches pretty much do nothing else but introduce a warning. > > Nothing is broken, nothing is changed in the test suite: > > > > http://article.gmane.org/gmane.c

Re: [PATCH 1/3] reset: add --stage and --work options

On Sun, Sep 8, 2013 at 7:15 PM, Ramkumar Ramachandra wrote: > Felipe Contreras wrote: >> Either way it doesn't matter because Junio is determined to stand >> alone versus the rest of the world in this issue. > > Which is why he's the maintainer. Send in incremental updates, and he > should be fine

Re: [PATCH 0/4] Re: [PATCH 3/4] t: rev-parse-parents: avoid yoda conditions

On Sun, Sep 8, 2013 at 6:45 PM, Jeff King wrote: > On Sun, Sep 08, 2013 at 06:25:45PM -0500, Felipe Contreras wrote: > >> > And I do not think it is a problem. The point of the function is not to >> > abstract away the idea of comparison. The point is to give a hook for >> > people on systems with

[PATCH v3 5/5] pull: add warning on non-ff merges

To prepare our uses for the upcoming changes we should warn them and let them know that they will need to specify a merge or a rebase in the future (when a non-fast-forward situation arises). Also, let them know we fallback to 'git pull --merge', so when the obsoletion of this mode comes, they know

  1   2   >