Re: [PATCH 4/4] sequencer: use trailer's trailer layout

Jonathan Tan writes: > @@ -26,30 +27,6 @@ static GIT_PATH_FUNC(git_path_opts_file, SEQ_OPTS_FILE) > static GIT_PATH_FUNC(git_path_seq_dir, SEQ_DIR) > static GIT_PATH_FUNC(git_path_head_file, SEQ_HEAD_FILE) > > -static int is_rfc2822_line(const char *buf, int len) >

Re: [PATCH v2 1/6] submodules: add helper functions to determine presence of submodules

On Mon, Oct 31, 2016 at 3:38 PM, Brandon Williams wrote: > +int is_submodule_checked_out(const char *path) > +{ > + int ret = 0; > + struct strbuf buf = STRBUF_INIT; > + > + strbuf_addf(, "%s/.git", path); > + ret = file_exists(buf.buf); I think we can

Re: [ANNOUNCE] Git v2.11.0-rc0

On Mon, Oct 31, 2016 at 02:49:42PM -0700, Junio C Hamano wrote: > [snip] Hello, I noticed a few minor typos in the changelog. > * The default abbreviation length, which has historically been 7, now >scales as the repository grows, using the approximate number of >objects in the

Re: [PATCH 3/4] trailer: have function to describe trailer layout

Jonathan Tan writes: > static char *separators = ":"; > > +static int configured = 0; Avoid initializing a static to 0 or NULL; instead let .bss take care of it. > static const char *token_from_item(struct arg_item *item, char *tok) > { > if

[PATCH v2 3/6] grep: add submodules as a grep source type

Add `GREP_SOURCE_SUBMODULE` as a grep_source type and cases for this new type in the various switch statements in grep.c. When initializing a grep_source with type `GREP_SOURCE_SUBMODULE` the identifier can either be NULL (to indicate that the working tree will be used) or a SHA1 (the REV of the

[PATCH v2 5/6] grep: enable recurse-submodules to work on objects

Teach grep to recursively search in submodules when provided with a object. This allows grep to search a submodule based on the state of the submodule that is present in a commit of the super project. When grep is provided with a object, the name of the object is prefixed to all output. In

[PATCH v2 1/6] submodules: add helper functions to determine presence of submodules

Add two helper functions to submodules.c. `is_submodule_initialized()` checks if a submodule has been initialized at a given path and `is_submodule_checked_out()` check if a submodule has been checked out at a given path. Signed-off-by: Brandon Williams --- submodule.c | 39

[PATCH v2 2/6] submodules: load gitmodules file from commit sha1

Teach submodules to load a '.gitmodules' file from a commit sha1. This enables the population of the submodule_cache to be based on the state of the '.gitmodules' file from a particular commit. Signed-off-by: Brandon Williams --- cache.h| 2 ++ config.c

[PATCH v2 4/6] grep: optionally recurse into submodules

Allow grep to recognize submodules and recursively search for patterns in each submodule. This is done by forking off a process to recursively call grep on each submodule. The top level --super-prefix option is used to pass a path to the submodule which can in turn be used to prepend to output

[PATCH v2 6/6] grep: search history of moved submodules

If a submodule was renamed at any point since it's inception then if you were to try and grep on a commit prior to the submodule being moved, you wouldn't be able to find a working directory for the submodule since the path in the past is different from the current path. This patch teaches grep

[PATCH v2 0/6] recursively grep across submodules

A few minor style issues have been taken care of from v1 of this series. I also added an additional patch to enable grep to function on history where the submodule has been moved. I also changed how tree grep performs pathspec checking against submodule entries in order to fix a test that was

[ANNOUNCE] Git v2.11.0-rc0

An early preview release Git v2.11.0-rc0 is now available for testing at the usual places. It is comprised of 617 non-merge commits since v2.10.0, contributed by 64 people, 14 of which are new faces. An updated, slightly slipped from the original, schedule is found at http://tinyurl.com/gitCal

What's cooking in git.git (Oct 2016, #09; Mon, 31)

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. Git v2.10.2, the second

Re: [PATCH 2/4] trailer: avoid unnecessary splitting on lines

Christian Couder writes: > On Sat, Oct 29, 2016 at 2:05 AM, Jonathan Tan > wrote: >> trailer.c currently splits lines while processing a buffer (and also >> rejoins lines when needing to invoke ignore_non_trailer). >> >> Avoid such line

Re: [PATCH] push: do not use potentially ambiguous default refspec

Dennis Kaarsemaker writes: > On Fri, Oct 28, 2016 at 12:25:30PM -0700, Junio C Hamano wrote: > >> * It is appreciated if somebody with spare cycles can add a test or >>two for this in t/t5523-push-upstream.sh or somewhere nearby. > > 5523 is for push

Re: [PATCH 2/4] trailer: avoid unnecessary splitting on lines

Jonathan Tan writes: > diff --git a/trailer.c b/trailer.c > index 6d8375b..d4d9e10 100644 > --- a/trailer.c > +++ b/trailer.c > @@ -102,12 +102,12 @@ static int same_trailer(struct trailer_item *a, struct > arg_item *b) > return same_token(a, b) && same_value(a,

Re: [PATCH] push: do not use potentially ambiguous default refspec

On Fri, Oct 28, 2016 at 12:25:30PM -0700, Junio C Hamano wrote: > * It is appreciated if somebody with spare cycles can add a test or >two for this in t/t5523-push-upstream.sh or somewhere nearby. 5523 is for push --set-upstream-to, 5528 seemed more appropriate. Here's something squashable

Re: [PATCH] rebase: add --forget to cleanup rebase, leave HEAD untouched

Duy Nguyen writes: > On Wed, Oct 26, 2016 at 11:51 PM, Junio C Hamano wrote: >> Nguyễn Thái Ngọc Duy writes: >> >>> There are occasions when you decide to abort an in-progress rebase and >>> move on to do something else but you forget

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

On Mon, Oct 31, 2016 at 10:55:32AM -0700, Junio C Hamano wrote: > > So I guess it's possible that it produces a noticeable effect in some > > cases, but I'm still somewhat doubtful. And actually repacking your > > repository had a greater effect in every case I measured (in addition to > >

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

Jeff King writes: > If you set a probe on touch_atime() in the kernel (which is called for > every attempt to smudge the atime, regardless of mount options, but is > skipped when the descriptor was opened with O_NOATIME), you can see the > impact. Here's a command I picked because

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

Linus Torvalds writes: > On Sat, Oct 29, 2016 at 1:25 AM, Johannes Schindelin > wrote: >> >> Correct. We cannot change an open file handle's state ("FD_CLOEXEC") on >> Windows, but we can ask open() to open said file handle with the

Re: Reporting Bug in Git Version Control System

W dniu 25.10.2016 o 10:51, Pranit Bauva pisze: > Hey Yash, > > Junio has explained the problem very well. Since you seem to be a > beginner (guessing purely by your email) I will tell you how to fix > it. > > Remember when you would have first installed git, you would have done > something like

Re: [git rebase -i] show time and author besides commit hash and message?

On Mon, Oct 31, 2016 at 11:27:33PM +0800, ryenus wrote: > > It is possible to change the format globally via config option > > rebase.instructionFormat: > > > > $ git config rebase.instructionFormat "%an (%ad): %s" > > > > The format is the same as for 'git log'. This one outputs author > >

Re: [git rebase -i] show time and author besides commit hash and message?

> It is possible to change the format globally via config option > rebase.instructionFormat: > > $ git config rebase.instructionFormat "%an (%ad): %s" > > The format is the same as for 'git log'. This one outputs author > name, date, and the first line of commit message. Thanks for the prompt

Re: [PATCH v3 2/3] sha1_file: open window into packfiles with O_CLOEXEC

On Fri, Oct 28, 2016 at 09:13:41AM -0700, Linus Torvalds wrote: > On Fri, Oct 28, 2016 at 4:11 AM, Johannes Schindelin > wrote: > > > > You guys. I mean: You guys! You sure make my life hard. A brief look at > > mingw.h could have answered your implicit question: > >

[no subject]

I am Mrs. Gu Kailai and i intend to make a DONATION. Contact my personal E-mail Via: mrsgukai...@post.cz for more details:

Re: Is the entire working copy “at one branch”?

Thanks Alexei! On Sat, Oct 29, 2016 at 12:47 PM, Alexei Lozovsky wrote: > Hi Stefan, > > Generally with git, your entire working copy will have the same > revision (set to current branch, aka HEAD). The idea behind this > is that your working copy of a repository should