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 -s
> 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
origin
> 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
On Wed, Jan 6, 2016 at 4:52 AM, Duy Nguyen wrote:
> 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-ini
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 it happens.
>>
[+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 differences (especia
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 ++-
refs/refs-internal.h | 2 ++
2 files changed,
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).
Updat
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,
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
> at
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 becomes
> trivial:
>
>
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
>> working with the code asap:
>>
>> git clone --de
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 change the default behavior
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 clon
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
> suggested I use strcmp() instea
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
+un
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
>
> in a more concise way:
>
>
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 gitignore support was written new, not
>
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 unsigned char *sha1,
>> -
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 the atom.
>>
>> Helped-by: Ramsay Jones
>>
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]).
>
> Thanks, we actually already
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 akin to
> > sed -i. This allows to write commands like the following:
>
> Sinc
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 -i), it
probably makes sense to have it here too. OT
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 interpret-trailers --trailer "X: Y" --
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
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 +-
git-compat-util.h | 1 +
wrapper.c
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 u
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 changed, 4 insertions(+), 5
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 a
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 should also try to
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
>> +++ b/Documentation/git-init.txt
>> @@ -12,7 +12,7
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 init
> $ git remote
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 notice
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 "(?i)$any_pattern"
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 "backend"; there
>> are al
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.
>>
>> Helped-by: Eric Sunshine
>> Signed-off-by: Ka
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 },
>> { "align" },
>> { "end" }
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 differences (especially in corn
> 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 inside 'a' so we can't tr
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 we
use that com
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 few files/direc
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
>> > wrote:
>> > > On di, 2016-01-05 at
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 conten
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/
добрий день,
просимо на будь-якій сторінці вгорі один раз нати
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:
> > > > Hmm, this test is succes
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
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
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 got
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 sand
49 matches
Mail list logo
