Re: [PATCH] commit: ensure correct permissions of the commit message

Hi Peff, On Wed, 6 Jan 2016, Jeff King wrote: > I think fopen_for_writing() is fine, or fopen_truncate(). I like fopen_for_writing() better than fopen_truncate() because it states the intention more clearly. Thanks! Dscho -- To unsubscribe from this list: send the line "unsubscribe git" in the

Re: Segmentation fault found while fuzzing .pack file under 2.7.0.rc3

W dniu 06.01.2016 o 01:23, Jonathan Nieder pisze: > Jeff King wrote: > >> Git packfiles come from two places: >> >> 1. Local maintenance repacks loose and already-packed objects into a >> new packfile. We trust the local repack process to generate a valid >> packfile (though the

Re: Git 2.7.0 gitignore behaviour regression

On Tue, Jan 5, 2016 at 10:06 PM, Jeff King wrote: > On Tue, Jan 05, 2016 at 02:40:16PM +, Mike McQuaid wrote: > >> Homebrew has a series of convoluted .gitignore rules due to our >> special/weird use-case of wanting to ignore everything in a working >> directory except a select

Re: [PATCH v3 11/15] ref-filter: convert variable 'width' to an unsigned int

On Wed, Jan 6, 2016 at 2:42 AM, Junio C Hamano wrote: > Karthik Nayak writes: > >> In align_atom_parser() the 'width' variable is an int, which requires >> an explicit type conversion when used in strtoul_ui(). Hence make it >> an unsigned int. >> >>

Re: [PATCH v3 08/15] ref-filter: introduce color_atom_parser()

On Wed, Jan 6, 2016 at 2:36 AM, Junio C Hamano wrote: > Karthik Nayak writes: > >> @@ -90,7 +105,7 @@ static struct { >> { "symref" }, >> { "flag" }, >> { "HEAD" }, >> - { "color" }, >> + { "color", FIELD_STR, color_atom_parser

Dear Sir or Madam, let the New Year be more successful for you! - please help our site - пожалуйста, помогите нашему сайту - будь ласка, допоможіть нашому сайту http://kyiv230school.pp.ua/

Dear Sir or Madam, let the New Year be more successful for you! good day, ask at the top of any page click once on the banner, so that we could pay for hosting our site, Thank you ad...@kyiv230school.pp.ua http://kyiv230school.pp.ua/ добрий день, просимо на будь-якій сторінці вгорі один раз

Re: [PATCH v4] reflog-walk: don't segfault on non-commit sha1's in the reflog

On Wed, Jan 6, 2016 at 4:13 PM, Dennis Kaarsemaker wrote: > On di, 2016-01-05 at 20:52 -0500, Eric Sunshine wrote: >> On Tue, Jan 5, 2016 at 8:28 PM, Eric Sunshine < >> sunsh...@sunshineco.com> wrote: >> > On Tue, Jan 5, 2016 at 8:20 PM, Dennis Kaarsemaker >> >

Re: [PATCH v4] reflog-walk: don't segfault on non-commit sha1's in the reflog

On di, 2016-01-05 at 20:52 -0500, Eric Sunshine wrote: > On Tue, Jan 5, 2016 at 8:28 PM, Eric Sunshine < > sunsh...@sunshineco.com> wrote: > > On Tue, Jan 5, 2016 at 8:20 PM, Dennis Kaarsemaker > > wrote: > > > On di, 2016-01-05 at 20:05 -0500, Eric Sunshine wrote: > > > >

Re: [PATCH 13/16] init: allow alternate backends to be set for new repos

On 01/05/2016 07:03 PM, Junio C Hamano wrote: > David Turner writes: > >> I'm working on the rest now, but wanted to comment on this first. I >> went ahead and made this change, but I'm not sure I like it. In the >> git codebase, the concept will continue to be called

Re: Git 2.7.0 gitignore behaviour regression

> On 6 Jan 2016, at 09:42, Duy Nguyen wrote: > > Yeah.. I think it's the only relevant commit in 2.7.0 cycle anyway. > These patterns "/a" followed by "!/a/*" were wrecking my head. But I > finally decided 2.7 output makes more sense. You asked to un-ignore > everything

Re: Git 2.7.0 gitignore behaviour regression

On Wed, Jan 6, 2016 at 4:50 PM, Mike McQuaid wrote: > it’s also a big area where libgit2 was inconsistent with Git’s behaviour on > either of those versions too. Yeah.. it looks like libgit2's gitignore support was written new, not imported from C Git, so behavior

Re: [PATCH] commit: ensure correct permissions of the commit message

On Wed, Jan 06, 2016 at 09:20:34AM +0100, Johannes Schindelin wrote: > Hi Junio, > > On Tue, 5 Jan 2016, Junio C Hamano wrote: > > > If we want to follow the X_or_Y() pattern, fopen_or_create() may > > describe what it does better. I do not have strong preference either > > way, but again I am

Re: Segmentation fault found while fuzzing .pack file under 2.7.0.rc3

On Tue, Jan 5, 2016 at 10:24 PM, Jeff King wrote: > If you can find a fuzzed packfile that crashes "index-pack", then _that_ > would be a big deal. I'm sure you know this, but if Jacek moves to break index-pack, then he/she should also try to break unpack-objects because sometimes

Re: [PATCH/RFC v2 0/2] add regex match flags to git describe

On Wed, Jan 6, 2016 at 8:08 AM, Mostyn Bramley-Moore wrote: > On 01/04/2016 06:46 PM, Junio C Hamano wrote: Magic pattern annotation like we do for pathspecs Duy raised may not be a bad idea, either, and would probably be easier to teach people. Just like in Perl

Re: [PATCH 13/16] init: allow alternate backends to be set for new repos

On Wed, Dec 23, 2015 at 8:34 PM, Michael Haggerty wrote: > On 12/03/2015 01:35 AM, David Turner wrote: >> diff --git a/Documentation/git-init.txt b/Documentation/git-init.txt >> index 8174d27..9ea6753 100644 >> --- a/Documentation/git-init.txt >> +++

Re: Segmentation fault found while fuzzing .pack file under 2.7.0.rc3

W dniu 06.01.2016 o 10:46, Duy Nguyen pisze: > On Tue, Jan 5, 2016 at 10:24 PM, Jeff King wrote: >> If you can find a fuzzed packfile that crashes "index-pack", then _that_ >> would be a big deal. > > I'm sure you know this, but if Jacek moves to break index-pack, then > he/she

[PATCH] interpret-trailers: add option for in-place editing

From: Tobias Klauser Add a command line option --in-place to support in-place editing akin to sed -i. This allows to write commands like the following: git interpret-trailers --trailer "X: Y" a.txt > b.txt && mv b.txt a.txt in a more concise way: git

[PATCH v2 1/2] commit: allow editing the commit message even in shared repos

It was pointed out by Yaroslav Halchenko that the file containing the commit message is writable only by the owner, which means that we have to rewrite it from scratch in a shared repository. Signed-off-by: Johannes Schindelin --- builtin/commit.c | 2 +-

[PATCH v2 2/2] Handle more file writes correctly in shared repos

In shared repositories, we have to be careful when writing files whose permissions do not allow users other than the owner to write them. In particular, we force the marks file of fast-export and the FETCH_HEAD when fetching to be rewritten from scratch. This commit does not touch the following

[PATCH v2 0/2] Correctly handle transient files in shared repositories

Transient files, e.g. commit messages, are writable only by the owner, even in shared repositories, to avoid interference between competing users working on the same files. These files are typically not deleted after use. As a consequence, we have to delete such files before writing when they are

Re: Questions on passing --depth to git-clone vs. git-fetch

On 1/6/2016 13:41, Duy Nguyen wrote: I think the culprit is the "git remote add" line. "git clone --depth" by default will fetch only one branch (aka --single-branch option in git-clone). But I suspect when you add a new remote, the default Now that you mention it I see this being documented

[PATCH] docs: clarify that passing --depth to git-clone implies --single-branch

It is confusing to document how --depth behaves as part of the --single-branch docs. Better move that part to the --depth docs, saying that it implies --single-branch by default. Signed-off-by: Sebastian Schuberth --- Documentation/git-clone.txt | 9 - 1 file

Re: [PATCH] interpret-trailers: add option for in-place editing

Tobias Klauser writes: > From: Tobias Klauser > > Add a command line option --in-place to support in-place editing akin to > sed -i. This allows to write commands like the following: Since -i is a common shortcut for --in-place (perl -i, sed

Questions on passing --depth to git-clone vs. git-fetch

Hi, I recently compared the results of doing $ git clone --depth=1 https://github.com/git/git.git git-clone-depth-1 versus $ mkdir git-fetch-depth-1 $ cd git-fetch-depth-1 $ git init $ git remote add origin https://github.com/git/git.git $ git fetch --depth=1 and

Re: Questions on passing --depth to git-clone vs. git-fetch

On Wed, Jan 6, 2016 at 7:30 PM, Sebastian Schuberth wrote: > Hi, > > I recently compared the results of doing > > $ git clone --depth=1 https://github.com/git/git.git git-clone-depth-1 > > versus > > $ mkdir git-fetch-depth-1 > $ cd git-fetch-depth-1 > $ git

Re: [PATCH] interpret-trailers: add option for in-place editing

Thanks for your feedback Matthieu! On 2016-01-06 at 15:19:45 +0100, Matthieu Moy wrote: > Tobias Klauser writes: > > > From: Tobias Klauser > > > > Add a command line option --in-place to support in-place editing

Re: [PATCH 0/2] git-candidate: git based patch tracking and review

On Tue, Dec 01, 2015 at 04:00:52PM -0500, Dave Borowitz wrote: > On Tue, Dec 1, 2015 at 3:55 PM, Jonathan Nieder wrote: > > Cc-ing dborowitz, who has been working on storing Gerrit's code review > > information in Git instead of a separate database (e.g., see [1]). > >

Re: [PATCH v3 14/15] ref-filter: introduce contents_atom_parser()

On Wed, Jan 6, 2016 at 2:52 AM, Junio C Hamano wrote: > Karthik Nayak writes: > >> Introduce contents_atom_parser() which will parse the '%(contents)' >> atom and store information into the 'used_atom' structure based on the >> modifiers used along with

Re: [PATCH v3 15/15] ref-filter: introduce objectname_atom_parser()

On Wed, Jan 6, 2016 at 3:01 AM, Junio C Hamano wrote: > Karthik Nayak writes: > >> @@ -467,15 +482,17 @@ static void *get_obj(const unsigned char *sha1, struct >> object **obj, unsigned lo >> } >> >> static int grab_objectname(const char *name, const

Re: Git 2.7.0 gitignore behaviour regression

On Wed, Jan 6, 2016 at 2:03 AM, Duy Nguyen wrote: > > On Wed, Jan 6, 2016 at 4:50 PM, Mike McQuaid wrote: > > it’s also a big area where libgit2 was inconsistent with Git’s behaviour on > > either of those versions too. > > Yeah.. it looks like libgit2's

Re: [PATCH] interpret-trailers: add option for in-place editing

On Wed, Jan 6, 2016 at 8:34 AM, Tobias Klauser wrote: > Add a command line option --in-place to support in-place editing akin to > sed -i. This allows to write commands like the following: > > git interpret-trailers --trailer "X: Y" a.txt > b.txt && mv b.txt a.txt >

Re: [PATCH] commit: ensure correct permissions of the commit message

Hi Junio, On Tue, 5 Jan 2016, Junio C Hamano wrote: > If we want to follow the X_or_Y() pattern, fopen_or_create() may > describe what it does better. I do not have strong preference either > way, but again I am not good at naming things (and I suspect you aren't > either), so... Heh... You

Re: Advice regarding inherited git repository

On Tue, Jan 05, 2016 at 05:42:15PM +, Danielle wrote: > I inherited a web site and a git repository. the git repository is cloned > to the website and a sandbox website (two clones). No commits have been > done in more than 6 months. The main site has been updated a lot of times, > the

Re: Initial git clone behaviour

On Wed, Jan 6, 2016 at 2:26 PM, Eric Curtin wrote: > > Often I do a standard git clone: > > git clone (name of repo) > > Followed by a depth=1 clone in parallel, so I can get building and > working with the code asap: > > git clone --depth=1 (name of repo) > > Could we

[PATCH/RFC v2 2/3] refs: resolve symbolic refs first

Before committing ref updates, split symbolic ref updates into two parts: an update to the underlying ref, and a log-only update to the symbolic ref. This ensures that both references are locked correctly while their reflogs are updated. It is still possible to confuse git by concurrent updates,

Re: [PATCH 12/16] refs: always handle non-normal refs in files backend

On Wed, 2015-12-23 at 09:02 +0100, Michael Haggerty wrote: > I very much like the idea of introducing special handling for > symbolic > reference updates within a transaction. In fact, I think I would go > even > farther: > > Let's take the example of an update to HEAD, which currently points >

Re: [PATCH] clone: use child_process for recursive checkouts

On Wed, 2015-12-23 at 12:30 +0100, Michael Haggerty wrote: > Signed-off-by: Michael Haggerty > --- > David, I think if you insert this patch before your > > 13/16 refs: allow ref backend to be set for clone > > , then the hunk in builtin/clone.c:checkout() of your patch

Re: Initial git clone behaviour

On 6 January 2016 at 23:14, Junio C Hamano wrote: > On Wed, Jan 6, 2016 at 2:26 PM, Eric Curtin wrote: >> >> Often I do a standard git clone: >> >> git clone (name of repo) >> >> Followed by a depth=1 clone in parallel, so I can get building and >>

Re: Git 2.7.0 gitignore behaviour regression

[+cc Carlos and Shawn for libgit2/JGit talk] On Wed, Jan 06, 2016 at 10:58:37AM -0800, Junio C Hamano wrote: > On Wed, Jan 6, 2016 at 2:03 AM, Duy Nguyen wrote: > > > > Yeah.. it looks like libgit2's gitignore support was written new, not > > imported from C Git, so behavior

Re: Git 2.7.0 gitignore behaviour regression

On Thu, Jan 7, 2016 at 9:04 AM, Jeff King wrote: >> Yup, an area that is reasonably isolated from the remainder of the system >> like >> this might be a good starting point. But I suspect that the invasion needs to >> happen in the opposite direction in this particular case before

Picking up old threads/patches

> If Will isn't interested in finishing these two patches I will pick them > up [ ($gmane/271213), ($gmane/272180) ] > > After that I will check look at some of the others for which you've > asked for help. I started work on both of this this evening. Since I do not have the original emails

Re: Picking up old threads/patches

> If Will isn't interested in finishing these two patches I will pick them > up [ ($gmane/271213), ($gmane/272180) ] > > After that I will check look at some of the others for which you've > asked for help. I started work on both of these rerolls this evening. Since I do not have the

[BUG?] worktree setup broken in subdirs with git alias

Hi there, sorry I can't dig deeper now, but the worktree code from next seems to get confused now as soon as you cd to a subdir of a worktree (other than the main worktree) and use an alias: git help ss `git ss' is aliased to `status -s -b' [mjg@skimbleshanks Biomath-WS15 (exam $)]✓ git status

Initial git clone behaviour

Hi Guys, I am not a git developer or a git expert but just a change I would love to see. When I clone a really large repository (like the linux kernel for example) initially on a brand new machine, it can take quite a while before I can start working with the code. Often I do a standard git

[PATCH/RFC v2 1/3] refs: allow log-only updates

The refs infrastructure learns about log-only ref updates, which only update the reflog. Later, we will use this to separate symbolic reference resolution from ref updating. Signed-off-by: David Turner --- refs/files-backend.c | 15 ++-

[PATCH/RFC v2 3/3] refs: always handle non-normal refs in files backend

Always handle non-normal (per-worktree or pseudo) refs in the files backend instead of alternate backends. Sometimes a ref transaction will update both a per-worktree ref and a normal ref. For instance, an ordinary commit might update refs/heads/master and HEAD (or at least HEAD's reflog).

Re: [PATCH 2/2] contrib/git-candidate: Add README

On 10.11.2015 13:56, Richard Ipsum wrote: +Existing tools such as Github's pull-requests and Gerrit are already +in wide use, why bother with something new? + +We are concerned that whilst git is a distributed version control +system the systems used to store comments and reviews for content

Re: [PATCH v3 00/15] ref-filter: use parsing functions

On Tue, Jan 5, 2016 at 3:02 AM, Karthik Nayak wrote: > Eric suggested that I make match_atom_name() not return a value [0]. I > haven't done that as we use match_atom_name() in [14/15] for matching > 'subject' and 'body' in contents_atom_parser() and although Eric >