Cody Sehl writes:
> The first few paragraphs in the git-rebase.txt documentation lay out the
> steps git takes during a rebase:
> 1. everything from `..HEAD` is saved to a temporary area
> 2. `HEAD` is set to ``
> 3. the changes held in the temporary area are applied one by one in order on
> to
Junio C Hamano writes:
> Johannes Sixt writes:
>
>>> As many codepaths may not even need access to the attributes, I
>>> doubt that would be a very productive direction to go.
>>
>> So, what is productive then? Pessimizing one (not exactly minor) platform?
>
> Lazy on-demand initialization as ne
Am 27.10.2016 um 08:21 schrieb Junio C Hamano:
Johannes Sixt writes:
As many codepaths may not even need access to the attributes, I
doubt that would be a very productive direction to go.
So, what is productive then? Pessimizing one (not exactly minor) platform?
Lazy on-demand initializati
The first few paragraphs in the git-rebase.txt documentation lay out the steps
git takes during a rebase:
1. everything from `..HEAD` is saved to a temporary area
2. `HEAD` is set to ``
3. the changes held in the temporary area are applied one by one in order on
top of the new `HEAD`
The second
Johannes Sixt writes:
>> As many codepaths may not even need access to the attributes, I
>> doubt that would be a very productive direction to go.
>
> So, what is productive then? Pessimizing one (not exactly minor) platform?
Lazy on-demand initialization as needed, perhaps? The on-demand
initi
Am 27.10.2016 um 08:02 schrieb Junio C Hamano:
Johannes Sixt writes:
Am 26.10.2016 um 23:57 schrieb Stefan Beller:
In Windows it is not possible to have a static initialized mutex as of
now, but that seems to be painful for the upcoming refactoring of the
attribute subsystem, as we have no go
Johannes Sixt writes:
> Am 26.10.2016 um 23:57 schrieb Stefan Beller:
>> In Windows it is not possible to have a static initialized mutex as of
>> now, but that seems to be painful for the upcoming refactoring of the
>> attribute subsystem, as we have no good place to put the initialization
>> of
Junio C Hamano writes:
> Peter Williams writes:
>
>> However, for git commands such as diff/status whose job is to display
>> information it would be nice if they had a --recursive option to
>> override the default submodule diff/status and show details of the
>> changes in the submodules. Some
Am 26.10.2016 um 23:57 schrieb Stefan Beller:
In Windows it is not possible to have a static initialized mutex as of
now, but that seems to be painful for the upcoming refactoring of the
attribute subsystem, as we have no good place to put the initialization
of the attr global lock.
Please rewr
Peter Williams writes:
> However, for git commands such as diff/status whose job is to display
> information it would be nice if they had a --recursive option to
> override the default submodule diff/status and show details of the
> changes in the submodules. Sometimes you want to see the big pi
Junio C Hamano writes:
> Stefan Beller writes:
>
>> Yeah, I can make it work without exposing struct git_attr.
>
> You completely misunderstood me. "struct git_attr" MUST be visible
> to the users so that they can ask for the name in git_check.attr[0].
>
> What would be nice to hide if you can
On 27/10/16 09:59, Junio C Hamano wrote:
Stefan Beller writes:
- We have to make separate commits and manage corresponding topic
branches for the superproject and subprojects.
Well yeah, that is how submodule work on a conceptual level.
While having multiple commits may seem like overhead, n
Stefan Beller writes:
> Yeah, I can make it work without exposing struct git_attr.
You completely misunderstood me. "struct git_attr" MUST be visible
to the users so that they can ask for the name in git_check.attr[0].
What would be nice to hide if you can is the function to intern a
string in
On Wed, 2016-10-26 at 19:03 -0700, Stefan Beller wrote:
> On Wed, Oct 26, 2016 at 6:52 PM, Matt McCutchen
> wrote:
> > 4. I pushed several dangling submodule pointers before I learned I
> > could set push.recurseSubmodules = check. This isn't the default; each
> > developer has to do it manually
> The use case for this is where I did not write my own rules, but I want
> to keep them updated. https://github.com/github/gitignore is a damn good
> resource, but I want to pull it and include relevant bits project by
> project and/or system wide. I don't want to have to update many projects
> ma
On Wed, Oct 26, 2016 at 5:49 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> extern struct git_attr *git_attr(const char *);
>> ...
>> +extern void git_attr_check_append(struct git_attr_check *,
>> + const struct git_attr *);
>
> Another thing. Do we still n
On Wed, Oct 26, 2016 at 6:52 PM, Matt McCutchen wrote:
> Hi Stefan,
>
> I appreciate the effort to remove obstacles to the use of submodules!
> It looks like a custom tool is probably still our best option at this
> time, though we can always switch back to submodules later.
>
> On Wed, 2016-10-2
Hi Stefan,
I appreciate the effort to remove obstacles to the use of submodules!
It looks like a custom tool is probably still our best option at this
time, though we can always switch back to submodules later.
On Wed, 2016-10-26 at 16:23 -0700, Stefan Beller wrote:
> On Wed, Oct 26, 2016 at 4:0
Stefan Beller writes:
> To explain, you can either have:
> struct git_attr_result result[2];
> or
> struct git_attr_result *result = git_attr_result_alloc(check);
> and both are running just fine in a thread. However you should not
> make that variable static. But maybe that is too much c
Stefan Beller writes:
> extern struct git_attr *git_attr(const char *);
> ...
> +extern void git_attr_check_append(struct git_attr_check *,
> + const struct git_attr *);
Another thing. Do we still need to expose git_attr() to the outside
callers? If we change git
I want a feature. It may be a bad-idea(tm). Advice appreciated.
I want git to be able to include, in its gitignore files, sub-files of
ignores or have it understand a directory of ignore files. Or both.
The use case for this is where I did not write my own rules, but I want
to keep them updated.
On Wed, Oct 26, 2016 at 5:16 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> +* Allocate an array of `struct git_attr_result` either on the stack
>> + or via `git_attr_result_alloc` on the heap when the result size
>> + is not known at compile time. The call to initialize
>>the resul
Stefan Beller writes:
> +* Allocate an array of `struct git_attr_result` either on the stack
> + or via `git_attr_result_alloc` on the heap when the result size
> + is not known at compile time. The call to initialize
>the result is not thread safe, because different threads need their
>
On Wed, Oct 26, 2016 at 4:14 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> @@ -53,19 +57,32 @@ value of the attribute for the path.
>> Querying Specific Attributes
>>
>>
>> -* Prepare `struct git_attr_check` using git_attr_check_initl()
>> +* Prepare a `str
Stefan Beller writes:
>> - We have to make separate commits and manage corresponding topic
>> branches for the superproject and subprojects.
>
> Well yeah, that is how submodule work on a conceptual level.
> While having multiple commits may seem like overhead, note
> the subtle difference for th
On Wed, Oct 26, 2016 at 4:07 PM, Matt McCutchen wrote:
> I'm the lead developer of a research software application (https://bitb
> ucket.org/objsheets/objsheets) that uses modified versions of two
> third-party libraries, which we need to version and distribute along
> with our application. For b
Stefan Beller writes:
> @@ -53,19 +57,32 @@ value of the attribute for the path.
> Querying Specific Attributes
>
>
> -* Prepare `struct git_attr_check` using git_attr_check_initl()
> +* Prepare a `struct git_attr_check` using `git_attr_check_initl()`
>functio
On Sun, Oct 23, 2016 at 8:10 AM, Ramsay Jones
wrote:
>> +
>> +struct hashmap all_attr_stacks;
>> +int all_attr_stacks_init;
>
> Mark symbols 'all_attr_stacks' and 'all_attr_stacks_init' with
> the static keyword. (ie. these are file-local symbols).
>
> ATB,
> Ramsay Jones
>
This fix will appear i
I'm the lead developer of a research software application (https://bitb
ucket.org/objsheets/objsheets) that uses modified versions of two
third-party libraries, which we need to version and distribute along
with our application. For better or for worse, we haven't made it a
priority to upstream ou
Jonathan Tan writes:
> On 10/26/2016 03:29 PM, Junio C Hamano wrote:
>> * jt/trailer-with-cruft (2016-10-21) 8 commits
>> - trailer: support values folded to multiple lines
>> - trailer: forbid leading whitespace in trailers
>> - trailer: allow non-trailers in trailer block
>> - trailer: clar
This revamps the API of the attr subsystem to be thread safe.
Before we had the question and its results in one struct type.
The typical usage of the API was
static struct git_attr_check *check;
if (!check)
check = git_attr_check_initl("text", NULL);
git_check_attr(path, chec
On 10/26/2016 03:29 PM, Junio C Hamano wrote:
* jt/trailer-with-cruft (2016-10-21) 8 commits
- trailer: support values folded to multiple lines
- trailer: forbid leading whitespace in trailers
- trailer: allow non-trailers in trailer block
- trailer: clarify failure modes in parse_trailer
-
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.
You can find the changes described
On Wed, Oct 26, 2016 at 2:57 PM, Stefan Beller wrote:
> In Windows it is not possible to have a static initialized mutex as of
> now, but that seems to be painful for the upcoming refactoring of the
> attribute subsystem, as we have no good place to put the initialization
> of the attr global lock
In Windows it is not possible to have a static initialized mutex as of
now, but that seems to be painful for the upcoming refactoring of the
attribute subsystem, as we have no good place to put the initialization
of the attr global lock.
The trick is to get a named mutex as CreateMutex[1] will ret
From: Junio C Hamano
Export invalid_attr_name_message() function that returns the
message to be given when a given pair
is not a good name for an attribute.
We could later update the message to exactly spell out what the
rules for a good attribute name are, etc.
We do not need to export the va
Eric Wong writes:
> Eric Wong wrote:
>> +Cc Jakub since gitweb could probably take advantage of get_record
>> from the first patch, too. I'm not completely sure about the API
>> for this, though.
>
> Jakub: ping?
>
> +Cc: Junio, too. I'm hoping to have this in 2.11.
I somehow was hoping that
Jeff King writes:
> On Wed, Oct 26, 2016 at 10:52:41AM -0700, Junio C Hamano wrote:
>
>> > I actually wonder if it is worth carrying around the O_NOATIME hack at
>> > all.
>>
>> Yes, I share the thought. We no longer have too many loose objects
>> to matter.
>>
>> I do not mind flipping the or
On Wed, Oct 26, 2016 at 1:37 PM, Anatoly Borodin
wrote:
> are there plans to add submodules support to git-archive?
plans by whom?
Git is a project with contributors from all over the place. (different
time zones,
people motivated by different means, i.e. we have the hobbiest that
scratches thei
On Wed, Oct 26, 2016 at 1:40 PM, Johannes Sixt wrote:
> Am 26.10.2016 um 22:26 schrieb Jeff King:
>>
>> On Wed, Oct 26, 2016 at 10:25:38PM +0200, Johannes Sixt wrote:
>>
>>> Am 26.10.2016 um 21:51 schrieb Stefan Beller:
it is
very convenient to not have to explicitly initialize mute
On Wed, Oct 26, 2016 at 1:26 PM, Jeff King wrote:
> On Wed, Oct 26, 2016 at 10:25:38PM +0200, Johannes Sixt wrote:
>
>> Am 26.10.2016 um 21:51 schrieb Stefan Beller:
>> > it is
>> > very convenient to not have to explicitly initialize mutexes?
>>
>> Not to initialize a mutex is still wrong for pth
Am 26.10.2016 um 22:26 schrieb Jeff King:
On Wed, Oct 26, 2016 at 10:25:38PM +0200, Johannes Sixt wrote:
Am 26.10.2016 um 21:51 schrieb Stefan Beller:
it is
very convenient to not have to explicitly initialize mutexes?
Not to initialize a mutex is still wrong for pthreads.
I think Stefan w
Hi All,
are there plans to add submodules support to git-archive?
--
Mit freundlichen Grüßen,
Anatoly Borodin
On Wed, Oct 26, 2016 at 10:25:38PM +0200, Johannes Sixt wrote:
> Am 26.10.2016 um 21:51 schrieb Stefan Beller:
> > it is
> > very convenient to not have to explicitly initialize mutexes?
>
> Not to initialize a mutex is still wrong for pthreads.
I think Stefan was being loose with his wording. T
Am 26.10.2016 um 21:51 schrieb Stefan Beller:
it is
very convenient to not have to explicitly initialize mutexes?
Not to initialize a mutex is still wrong for pthreads.
-- Hannes
On Wed, Oct 26, 2016 at 12:51:02PM -0700, Stefan Beller wrote:
> > I seem to recall this does not work on Windows, where the pthread
> > functions are thin wrappers over CRITICAL_SECTION. Other threaded code
> > in git does an explicit setup step before entering threaded sections.
> > E.g., see st
On Wed, Oct 26, 2016 at 10:52:41AM -0700, Junio C Hamano wrote:
> > I actually wonder if it is worth carrying around the O_NOATIME hack at
> > all.
>
> Yes, I share the thought. We no longer have too many loose objects
> to matter.
>
> I do not mind flipping the order, but I'd prefer to cook th
Eric Wong wrote:
> +Cc Jakub since gitweb could probably take advantage of get_record
> from the first patch, too. I'm not completely sure about the API
> for this, though.
Jakub: ping?
+Cc: Junio, too. I'm hoping to have this in 2.11.
> The following changes since commit 3cdd5d19178a54d2e51b
On Wed, Oct 26, 2016 at 5:15 AM, Jeff King wrote:
> On Wed, Oct 26, 2016 at 11:35:58AM +0200, Simon Ruderich wrote:
>
>> > static pthread_mutex_t attr_mutex;
>> > -#define attr_lock()pthread_mutex_lock(&attr_mutex)
>> > +static inline void attr_lock(void)
>> > +{
>> > + static int initialized;
Tao Peng wrote:
> Hi there,
>
> I met a bug of the "git svn show-externals” command. If a subdirectory item
> has a svn:externals property, and the format of the property is “URL first,
> then the local path”, running "git svn show-externals” command at the root
> level will result in an unus
Michael J Gruber writes:
> That one is difficult to discover but super useful, so document it:
> Specifying 3 or more commits makes git diff switch to combined diff.
>
> Signed-off-by: Michael J Gruber
> ---
>
> Notes:
> Note that we have the following now:
> ...
> 'git diff A..B' equiva
René Scharfe writes:
> Actually I didn't sign-off on purpose originally. But OK, let's keep
> the version below. I just feel strangely sad seeing that concise magic
> go. Nevermind.
I actually share the sadness, too, but let's be stupid and obvious
here.
Thanks.
>
> Signed-off-by: Rene Scha
Jeff King writes:
> Of the two flags, I would say CLOEXEC is the more important one to
> respect because it may actually impact correctness (e.g., leaking
> descriptors to sub-processes). Whereas O_NOATIME is purely a performance
> optimization.
I tend to agree.
> I actually wonder if it is wor
Am 25.10.2016 um 20:28 schrieb Junio C Hamano:
Jeff King writes:
On Mon, Oct 24, 2016 at 04:53:50PM -0700, Junio C Hamano wrote:
So how about this? It gets rid of magic number 3 and works for array
size that's not a power of two. And as a nice side effect it can't
trigger a signed overflow
Duy Nguyen writes:
> Interestingly the thread/bug that resulted in that commit started with
> "report this bug to git" [2]. Something about git-stash. I quote the
> original mail here in case anyone wants to look into it (not sure if
> it's actually reported here before, I don't pay much attentio
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 to do "git rebase --abort"
> first. Or the rebase has been in progress for so long you forgot about
> it. By the time you realize that (e.g. by star
On Wed, Oct 26, 2016 at 09:23:21AM -0700, Junio C Hamano wrote:
> >> + /* Might the failure be due to O_NOATIME? */
> >> + if (errno != ENOENT && (sha1_file_open_flag & O_NOATIME)) {
> >> + sha1_file_open_flag &= ~O_NOATIME;
> >> + continue;
> >>
Jeff King writes:
>> +/* Try again w/o O_CLOEXEC: the kernel might not support it */
>> +if ((sha1_file_open_flag & O_CLOEXEC) && errno == EINVAL) {
>> +sha1_file_open_flag &= ~O_CLOEXEC;
>> continue;
>> }
>
> So if we
Duy Nguyen writes:
> On Wed, Oct 26, 2016 at 12:21 AM, Junio C Hamano wrote:
>
> Even if we ignore user index files (by forcing them all to be stored
> in one piece), there is a problem with the special temporary file
> index.lock, which must use split-index because it will become the new
> inde
Duy Nguyen writes:
> I don't object the alias.. approach though. It's
> definitely a cleaner one in my opinion. It just needs people who can
> spend time to follow up until the end. But if someone decides to do
> that now, I'll drop the "(properties)!command" and try to support
> him/her.
I don'
On Tue, Oct 25, 2016 at 2:18 AM, Stefan Beller wrote:
> On Mon, Oct 24, 2016 at 11:55 AM, Junio C Hamano wrote:
>
>>
>> Make that a double-asterisk. The same problem appears in an updated
>> example in technical/api-gitattributes.txt doc, but the example in
>> the commit log message (below) is c
On Sun, Oct 23, 2016 at 6:32 AM, Stefan Beller wrote:
> This revamps the API of the attr subsystem to be thread safe.
> Before we had the question and its results in one struct type.
> The typical usage of the API was
>
> static struct git_attr_check *check;
>
> if (!check)
> check
(sorry if this should have been answered if I went through the series
patch by patch, I wanted to do a proper review but finally have to
admit to myself I won't, so I just skim through a single giant diff
instead)
On Sun, Oct 23, 2016 at 6:32 AM, Stefan Beller wrote:
> +attr;;
> +After `attr:` co
On Tue, Oct 11, 2016 at 10:01 PM, Jeff King wrote:
> On Tue, Oct 11, 2016 at 11:44:50AM +0200, Johannes Schindelin wrote:
>
>> > Yeah, that's reasonable, too. So:
>> >
>> > [alias]
>> > d2u = "!dos2unix"
>> >
>> > acts exactly as if:
>> >
>> > [alias "d2u"]
>> > command = dos2unix
>> >
Adding Cc: git list, Junio.
2016-10-26 15:55 GMT+03:00 Dmitry Safonov <0x7f454...@gmail.com>:
> Hi,
>
> Is there any way to specify git-log or git-rev-list which root tree to use?
> I mean, I got the following situation:
> I saw the commit a67dd266adf4 ("netfilter: xtables: prepare for
> on-demand
On Wed, Oct 26, 2016 at 07:26:20PM +0700, Duy Nguyen wrote:
> > I'm not sure this is really any convenience over dumping a corefile
> > and using gdb to pull out the
> > symbols after the fact.
>
> So are we back to forcing core files? I'm ok with that! The only
> inconvenience I see is pointing
On Wed, Oct 26, 2016 at 7:10 PM, Jeff King wrote:
> On Wed, Oct 26, 2016 at 05:29:21PM +0700, Duy Nguyen wrote:
>
>> > I think you could conditionally make git_path() and all of its
>> > counterparts macros, similar to the way the trace code works. It seems
>> > like a pretty maintenance-heavy sol
On Wed, Oct 26, 2016 at 11:35:58AM +0200, Simon Ruderich wrote:
> > static pthread_mutex_t attr_mutex;
> > -#define attr_lock()pthread_mutex_lock(&attr_mutex)
> > +static inline void attr_lock(void)
> > +{
> > + static int initialized;
> > +
> > + if (!initialized) {
> > + pthread_m
On Wed, Oct 26, 2016 at 05:29:21PM +0700, Duy Nguyen wrote:
> > I think you could conditionally make git_path() and all of its
> > counterparts macros, similar to the way the trace code works. It seems
> > like a pretty maintenance-heavy solution, though. I'd prefer
> > conditionally compiling bac
On Tue, Oct 25, 2016 at 11:15:25AM -0400, Jeff King wrote:
> > The "once we've identified" part could be tricky though. This message
> > alone will not give us any clue where it's called since it's buried
> > deep in git_path() usually, which is buried deep elsewhere. Without
> > falling back to co
There are occasions when you decide to abort an in-progress rebase and
move on to do something else but you forget to do "git rebase --abort"
first. Or the rebase has been in progress for so long you forgot about
it. By the time you realize that (e.g. by starting another rebase)
it's already too la
On Wed, Oct 26, 2016 at 10:52:23AM +0200, Johannes Schindelin wrote:
> diff --git a/attr.c b/attr.c
> index d5a6aa9..6933504 100644
> --- a/attr.c
> +++ b/attr.c
> @@ -50,7 +50,16 @@ static struct git_attr *(git_attr_hash[HASHSIZE]);
> #ifndef NO_PTHREADS
>
> static pthread_mutex_t attr_mutex;
>
On Wed, Oct 26, 2016 at 6:28 AM, Junio C Hamano wrote:
> Somebody with a bright idea decided that vc-git-resolve-conflicts
> variable should be on by default in Emacs 25.1 X-<,
Oh good, I have an excuse to stick to 24.5.1 for a while longer then.
> which causes
> "save" after resolving conflict
On Wed, Oct 26, 2016 at 12:21 AM, Junio C Hamano wrote:
>> Timestamps allow us to say, ok this base index file has not been read
>> by anybody for N+ hours (or better, days), it's most likely not
>> referenced by any temporary index files (including
>> $GIT_DIR/index.lock) anymore because those fi
That one is difficult to discover but super useful, so document it:
Specifying 3 or more commits makes git diff switch to combined diff.
Signed-off-by: Michael J Gruber
---
Notes:
Note that we have the following now:
'git diff A B' displays 'B minus A'
'git diff A B C' displays
Hi Stefan,
On Sat, 22 Oct 2016, Stefan Beller wrote:
> @@ -46,6 +47,19 @@ struct git_attr {
> static int attr_nr;
> static struct git_attr *(git_attr_hash[HASHSIZE]);
>
> +#ifndef NO_PTHREADS
> +
> +static pthread_mutex_t attr_mutex;
> +#define attr_lock() pthread_mutex_lock(&attr_mu
76 matches
Mail list logo
