On Mon, Jun 10, 2013 at 11:41 PM, Michael Haggerty mhag...@alum.mit.edu wrote:
On 06/10/2013 03:28 PM, Ramkumar Ramachandra wrote:
I've tried to write down a bare minimum, without restating the obvious.
Thank you for drafting a proposed CommunityGuidelines document; I think
such a document
On Mon, Jun 10, 2013 at 04:23:31PM -0700, Junio C Hamano wrote:
OK, I pushed out a result of some renaming and rebasing. Notable
changes are:
- The data and API is called prio-queue and they live in prio-queue.[ch];
- The test script is also named test-prio-queue.c, to leave the
y...@ensimag.imag.fr wrote:
[...]
Good change.
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 9a07f15..958617a 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
I expected one test. Two, at most. This is a bit overzealous. I
don't mind leaving it as it is, but as a note
Ramkumar Ramachandra artag...@gmail.com writes:
y...@ensimag.imag.fr wrote:
[...]
Good change.
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index 9a07f15..958617a 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
I expected one test. Two, at most. This is a bit
On Mon, Jun 10, 2013 at 11:47 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
This is not my first patch that gets rejected, but it's the first one
that gets rejected by Junio without even looking at it. What is
anybody supposed to think about that?
My very humble opinion: submit again
Junio C Hamano wrote:
The intent behind the document might be a noble one, but I am afraid
that the text is too broad and vague and does not address the real
issue to be of practical use.
Drafting something like this is shit work, which explains why nobody
has attempted it yet. I have no
On 2013-06-09 13:01:30 -0500, Felipe Contreras wrote:
You don't agree that 1) a collegial work environment is overrated, 2)
that the Linux kernel doesn't put an emphasis on being collegial, or
3) that it's the most successful software project in history?
Point 1.
Good, so we agree
On Tue, Jun 11, 2013 at 4:18 AM, Andres Freund and...@anarazel.de wrote:
On 2013-06-09 13:01:30 -0500, Felipe Contreras wrote:
You don't agree that 1) a collegial work environment is overrated, 2)
that the Linux kernel doesn't put an emphasis on being collegial, or
3) that it's the most
Michael Haggerty wrote:
Thank you for drafting a proposed CommunityGuidelines document; I think
such a document would be helpful. But I don't like the overall flavor
of your proposal; frankly, it sounds to me more like
Felipe Contreras wrote:
I think there's an even more important number 0:
Always assume good faith. When discussing through digital mediums,
it's very easy to misconstrue the tone and intentions of other
parties, so it's better to err on the side of caution, and if one is
mistaken, assuming
On Tue, Jun 11, 2013 at 5:45 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Whether or not you were justified in being offended is nobody's
business.
In a parallel with law, there is no concept of justly offended,
precisely because there is no way to determine what that even means.
People
githooks(5) says that [...]the .sample files are executable by default
which was not true.
Signed-off-by: Wieland Hoffmann themi...@gmail.com
---
templates/hooks--pre-push.sample | 0
1 file changed, 0 insertions(+), 0 deletions(-)
mode change 100644 = 100755 templates/hooks--pre-push.sample
Ramkumar Ramachandra artag...@gmail.com writes:
Michael Haggerty wrote:
Thank you for drafting a proposed CommunityGuidelines document; I think
such a document would be helpful. But I don't like the overall flavor
of your proposal; frankly, it sounds to me more like
(Got the idea from:
https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_rebase_--status)
When in the middle of a rebase, users can be easily confused about
what to do, or where they are in the rebase process.
All the information is available in .git/rebase-merge/, but I believe
it
Mathieu Liénard--Mayor mathieu.lienard--ma...@ensimag.fr writes:
(Got the idea from:
https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_rebase_--status)
When in the middle of a rebase, users can be easily confused about
what to do, or where they are in the rebase process.
All the
So, do I send a last version of the patch? What is left is quick fix:
- removing whitespace in [18/28]
- typo in [09/28]
- better line split in [22/28]
I already fixed first two problems, so it would be done rapidly.
--
Célestin Matte
--
To unsubscribe from this list: send the line unsubscribe
John Keeping j...@keeping.me.uk writes:
The one piece of information that I often want is the SHA1 of the commit
that is currently being applied. Currently I have to look through my
scrollback for the stopping message or poke around in .git/.
Having that in the output of git status would be
From: Jorge Juan Garcia Garcia jorge-juan.garcia-gar...@ensimag.imag.fr
Some people always run 'git status -s'.
The configuration variable status.short allows to set it by default.
Signed-off-by: Jorge Juan Garcia Garcia
jorge-juan.garcia-gar...@ensimag.imag.fr
Signed-off-by: Mathieu
Thomas Rast wrote:
It has become clear, also in discussion on IRC, that your preferred
approach is to fight the fires, attempting to extinguish flames as they
happen.
Incorrect. I am interested in minimizing occurrences, which is why I
started this thread: to calmly and rationally discuss how
jorge-juan.garcia-gar...@ensimag.imag.fr writes:
+test_expect_success 'status.branch=true different from --no-branch' '
+ git -c status.branch=true status -s actual
+ git status -s --no-branch expected_nobranch
Two nitpicks:
There are two spaces before , there should be one.
If
Célestin Matte celestin.ma...@ensimag.fr writes:
Users may be confused when they run the perl script directly.
A good way to detect this is to check the number of parameters used to call
the
script, which is never different from 2 in a normal use.
Display a proper error message to avoid any
Users may be confused when they run the perl script directly.
A good way to detect this is to check the number of parameters used to call the
script, which is never different from 2 in a normal use.
Display a proper error message to avoid any confusion.
Signed-off-by: Célestin Matte
The nesting was getting a bit out of hand, and it's about to get
worse.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 55 ++-
1 file changed, 34 insertions(+), 21 deletions(-)
diff --git a/refs.c b/refs.c
index
On 06/11/2013 03:40 PM, Ramkumar Ramachandra wrote:
Is it because you have realized deep down that you have absolutely no
rational argument...Why are you incapable of
using your words to counter my arguments rationally?Are you so blind
that you cannot see the consequences of acting without
Introduce advice.rmHints to choose whether to display advice or not
when git rm fails. Defaults to true, in order to preserve current behavior.
As an example, the message:
error: 'foo.txt' has changes staged in the index
(use --cached to keep the file, or -f to force removal)
When 'git rm' fails, it now displays a single message
with the list of files involved, instead of displaying
a list of messages with one file each.
As an example, the old message:
error: 'foo.txt' has changes staged in the index
(use --cached to keep the file, or -f to force
Célestin Matte celestin.ma...@ensimag.fr writes:
Subroutines' parameters should be affected to variable before doing anything
else
Besides, existing instruction affected a variable inside a if, which break
Git's coding style
I think s/affect/assign/g is what you meant.
By the way, I often
On Tue, Jun 11, 2013 at 7:33 AM, Thomas Rast tr...@inf.ethz.ch wrote:
My approach -- and in my perception also that preferred by most of the
regulars who have spoken in this whole mess -- is that since there is a
fire hazard, it would be more effective firefighting to just remove the
hazard,
Hi,
Before going to your arguments, can you stop conveniently *ignoring*
my argument and answer this questions?
When two children fight, who has the blame? The one that threw the
first punch? Or the one that returned it?
On Tue, Jun 11, 2013 at 9:40 AM, Michael Haggerty mhag...@alum.mit.edu
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Jun 11, 2013 at 7:33 AM, Thomas Rast tr...@inf.ethz.ch wrote:
My approach -- and in my perception also that preferred by most of the
regulars who have spoken in this whole mess -- is that since there is a
fire hazard, it would be
Célestin Matte celestin.ma...@ensimag.fr writes:
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 50
+--
1 file changed, 31 insertions(+), 19
On Tue, Jun 11, 2013 at 10:41 AM, Thomas Rast tr...@inf.ethz.ch wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Jun 11, 2013 at 7:33 AM, Thomas Rast tr...@inf.ethz.ch wrote:
My approach -- and in my perception also that preferred by most of the
regulars who have spoken in
Michael Haggerty mhag...@alum.mit.edu writes:
* Accept reviewers' comments gratefully and take them very seriously.
Show that you appreciate the help by giving the reviewer the benefit of
the doubt. If, after careful consideration, you find that you cannot
agree with a reviewer's suggestion,
Fredrik Gustafsson iv...@iveqy.com writes:
Here we have two sh-scripts (git rebase
and git am) interacting with each other.
Both uses GIT_QUIET,
Correct.
so if GIT_QUIET already is set by the caller (git rebase) the
callee doesn't have to set it to.
Incorrect. git rebase invokes git am,
On Tue, Jun 11, 2013 at 11:10 AM, Thomas Rast tr...@inf.ethz.ch wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
* Accept reviewers' comments gratefully and take them very seriously.
Show that you appreciate the help by giving the reviewer the benefit of
the doubt. If, after careful
Is there any official documentation of tree objets format? Are tree
objects encoded specially in some way? How can I parse the inflated
contents of a tree object?
We're suspecting that there is some kind of special format or
encoding, because the command git cat-file -p sha show me the
expected
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi,
I'm trying to setup a workflow to track vendor releases (upstream).
Each new release are provided as an archive of source code, data,
documentation, etc.
For each vendor releases, fixes need to be applied before making them
available to users (downstream).
Seems to be a rather common use
On 11 June 2013 06:19, Matthieu Moy matthieu@grenoble-inp.fr wrote:
John Keeping j...@keeping.me.uk writes:
The one piece of information that I often want is the SHA1 of the commit
that is currently being applied. Currently I have to look through my
scrollback for the stopping message or
On Tue, Jun 11, 2013 at 12:09:32PM -0500, Felipe Contreras wrote:
It's not removed. It's simply moved.
Sorry about that, I wasn't paying enough attention. But why are you
moving it?
All other arguments to git am is set in git-rebase.sh, why just set
-q just before the invokation in
On Tue, Jun 11, 2013 at 10:18 AM, Hilco Wijbenga
hilco.wijbe...@gmail.com wrote:
Having git status display (even more) context sensitive
information during git rebase or git merge would be very welcome.
Please, if at all possible, don't make that a separate command.
I agree. The rebase state
On Tue, Jun 11, 2013 at 12:24 PM, Fredrik Gustafsson iv...@iveqy.com wrote:
On Tue, Jun 11, 2013 at 12:09:32PM -0500, Felipe Contreras wrote:
It's not removed. It's simply moved.
Sorry about that, I wasn't paying enough attention. But why are you
moving it?
All other arguments to git am is
I'm trying to setup a workflow to track vendor releases (upstream).
Each new release are provided as an archive of source code, data,
documentation, etc.
I've been doing more or less this. A few comments:
I suggest that you not view CRLF-LF as a patch. I would do EOL
hygiene as a
Felipe Contreras felipe.contre...@gmail.com writes:
- There may be pieces of usefully reusable code buried in
builtin/*.o;
- By definition, any code (piece of data or function definition) in
builtin/*.o cannot be used in standalone binaries, because all of
builtin/*.o expect to
On Tue, Jun 11, 2013 at 12:26:42PM -0500, Felipe Contreras wrote:
On Tue, Jun 11, 2013 at 12:24 PM, Fredrik Gustafsson iv...@iveqy.com wrote:
On Tue, Jun 11, 2013 at 12:09:32PM -0500, Felipe Contreras wrote:
It's not removed. It's simply moved.
Sorry about that, I wasn't paying enough
On Tue, Jun 11, 2013 at 12:33 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
- There may be pieces of usefully reusable code buried in
builtin/*.o;
- By definition, any code (piece of data or function definition) in
builtin/*.o cannot
On Tue, Jun 11, 2013 at 12:41 PM, Fredrik Gustafsson iv...@iveqy.com wrote:
On Tue, Jun 11, 2013 at 12:26:42PM -0500, Felipe Contreras wrote:
On Tue, Jun 11, 2013 at 12:24 PM, Fredrik Gustafsson iv...@iveqy.com wrote:
On Tue, Jun 11, 2013 at 12:09:32PM -0500, Felipe Contreras wrote:
It's not
Felipe Contreras felipe.contre...@gmail.com writes:
What are the examples you have in mind, code that we want to forbid
standalone from using?
init_copy_notes_for_rewrite(). Nothing outside the 'git' binary would
need that. If you disagree, show me an example.
Nothing would need that, if
On Tue, Jun 11, 2013 at 12:58 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
What are the examples you have in mind, code that we want to forbid
standalone from using?
init_copy_notes_for_rewrite(). Nothing outside the 'git' binary would
need
Mathieu Lienard--Mayor mathieu.lienard--ma...@ensimag.imag.fr
writes:
+static void print_error_files(struct string_list *files_list,
+ const char *main_msg,
+ const char *hints_msg,
+ int *errs)
+{
+ if
Matthieu Moy matthieu@grenoble-inp.fr writes:
my ($namespace) = @_;
my $namespace = shift;
My impression has been that both are equally common,
The second is the most common in git-remote-mediawiki (but I don't have
any preference nor know what is recommended elsewhere).
I
On Tue, Jun 11, 2013 at 11:06 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Moreover, if you are going to argue that we shouldn't be closing the
door [...]
Felipe, you saying if you are going to argue ... to anybody else is
kind of ironic.
Why is it every thread I see you in, you're
This is an exercise. I can easily be more tactful (as evidenced by
other threads), but I'm choosing not to be. I want you to focus on
the argument, and not the tone.
Michael Haggerty wrote:
Ram, you are insulting Thomas the human being rather than addressing his
points. Please stop.
He
Felipe Contreras felipe.contre...@gmail.com writes:
Moreover, if you are going to argue that we shouldn't be closing the
door, then why not link ./builtin/*.o to libgit.a?
Huh? It does not make any sense. builtin/*.o files have cmd_foo()
that are expected to be called from git.c::main(), but
On 06/11/2013 07:00 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
[...]
* When reviewing other peoples' code, be tactful and constructive. Set
high expectations, but do what you can to help the submitter achieve
them. Don't demand changes based only on your
Am 11.06.2013 19:06, schrieb Yann Droneaud:
Hi,
I'm trying to setup a workflow to track vendor releases (upstream).
Each new release are provided as an archive of source code, data,
documentation, etc.
For each vendor releases, fixes need to be applied before making them
available to
On Tue, Jun 11, 2013 at 10:00:56AM -0700, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
* When reviewing other peoples' code, be tactful and constructive. Set
high expectations, but do what you can to help the submitter achieve
them. Don't demand changes based only
I was reasonably sure that I've seen this patch before, and checked
to see everybody else in that directory has executable bit, but it
seems that I forgot to apply it.
Thanks. Applied.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to
On Tue, Jun 11, 2013 at 01:25:14PM -0300, Chico Sokol wrote:
Is there any official documentation of tree objets format? Are tree
objects encoded specially in some way? How can I parse the inflated
contents of a tree object?
Tree object consists of entries, each concatenation of:
- Octal mode
Chico Sokol chico.so...@gmail.com writes:
Is there any official documentation of tree objets format? Are tree
objects encoded specially in some way? How can I parse the inflated
contents of a tree object?
We're suspecting that there is some kind of special format or
encoding, because the
git rebase -i --autosquash does not handle a fixup! of a fixup!, such as
the history:
aaa fix nasty bug
...
bbb fixup! fix nasty bug
...
ccc fixup! fixup! fix nasty bug
--autosquash produces:
pick aaa fix nasty bug
fixup bbb fixup! fix nasty bug
On 06/11/2013 08:16 PM, Ramkumar Ramachandra wrote:
This is an exercise. I can easily be more tactful (as evidenced by
other threads), but I'm choosing not to be. I want you to focus on
the argument, and not the tone.
I stopped reading your email here. I've read enough tactless emails
over
From: Yann Droneaud ydrone...@opteya.com
Sent: Tuesday, June 11, 2013 6:06 PM
Hi,
I'm trying to setup a workflow to track vendor releases (upstream).
Each new release are provided as an archive of source code, data,
documentation, etc.
For each vendor releases, fixes need to be applied before
John Keeping wrote:
Ugh, why this roundabout-passive-past tone? Use imperative tone
like this:
...
vs.
We normally use the imperative in commit messages, perhaps like
this?
...
As my mother would say, politeness costs nothing ;-)
The review is being
On 06/11/2013 08:29 PM, John Keeping wrote:
On Tue, Jun 11, 2013 at 10:00:56AM -0700, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
* When reviewing other peoples' code, be tactful and constructive. Set
high expectations, but do what you can to help the submitter achieve
Michael Haggerty wrote:
I stopped reading your email here. I've read enough tactless emails
over the last few days, but to be asked to read an email that was
*intentionally* written tactlessly is too detrimental to my quality of life.
I'm sorry, but the problem has no solution then.
The
Andrew Pimlott and...@pimlott.net writes:
git rebase -i --autosquash does not handle a fixup! of a fixup!, such as
the history:
aaa fix nasty bug
...
bbb fixup! fix nasty bug
...
ccc fixup! fixup! fix nasty bug
--autosquash produces:
pick aaa
On Tue, Jun 11, 2013 at 1:17 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Moreover, if you are going to argue that we shouldn't be closing the
door, then why not link ./builtin/*.o to libgit.a?
Huh? It does not make any sense. builtin/*.o
Ramkumar Ramachandra artag...@gmail.com writes:
Michael Haggerty wrote:
I stopped reading your email here. I've read enough tactless emails
over the last few days, but to be asked to read an email that was
*intentionally* written tactlessly is too detrimental to my quality of life.
I'm
On Tue, Jun 11, 2013 at 1:14 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Tue, Jun 11, 2013 at 11:06 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
Moreover, if you are going to argue that we shouldn't be closing the
door [...]
Felipe, you saying if you are going to
On Tue, Jun 11, 2013 at 08:52:05PM +0200, Michael Haggerty wrote:
That's a very good point (and a good illustration, too). How do you
like the new second and third sentences below?
* When reviewing other peoples' code, be tactful and constructive.
Remember that submitting patches for public
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Jun 11, 2013 at 1:17 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Moreover, if you are going to argue that we shouldn't be closing the
door, then why not link ./builtin/*.o to
On Tue, Jun 11, 2013 at 1:29 PM, John Keeping j...@keeping.me.uk wrote:
I realise that we shouldn't take offence to review comments, but we are
all human and it is sometimes hard not to take things personally.
In the examples above, the first makes it feel like the submitter is
fighting to
On Tue, Jun 11, 2013 at 2:06 PM, Junio C Hamano gits...@pobox.com wrote:
Ramkumar Ramachandra artag...@gmail.com writes:
I'm sorry, but the problem has no solution then.
The problem we are dealing with is irrational and/or out-of-tone
emails. Unless you possess some mind-control mechanism
From: Michael Haggerty mhag...@alum.mit.edu
Sent: Tuesday, June 11, 2013 7:52 PM
[...]
That's a very good point (and a good illustration, too). How do you
like the new second and third sentences below?
* When reviewing other peoples' code, be tactful and constructive.
Remember that submitting
On Tue, Jun 11, 2013 at 2:24 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Tue, Jun 11, 2013 at 1:17 PM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
Moreover, if you are going to argue that
On Wed, Jun 12, 2013 at 12:16:28AM +0530, Ramkumar Ramachandra wrote:
John Keeping wrote:
Ugh, why this roundabout-passive-past tone? Use imperative tone
like this:
...
vs.
We normally use the imperative in commit messages, perhaps like
this?
On Tue, Jun 11, 2013 at 7:40 AM, Michael Haggerty mhag...@alum.mit.edu wrote:
At the risk of being
presumptuous myself, I suggest that you show a copy of your email to
somebody whom you know and respect in the real world, somebody who is
not immersed in the Git community meltdown. For
Linus Torvalds torva...@linux-foundation.org writes:
This whole thread has been one long argument about totally pointless
things that wouldn't improve anything one way or the other. It's
bikeshedding of the worst kind. Just let it go.
The proposal to move sequencer.c to builtins/sequencer.c
On Tue, Jun 11, 2013 at 2:59 PM, Junio C Hamano gits...@pobox.com wrote:
Linus Torvalds torva...@linux-foundation.org writes:
This whole thread has been one long argument about totally pointless
things that wouldn't improve anything one way or the other. It's
bikeshedding of the worst kind.
Le 11/06/2013 20:09, Junio C Hamano a écrit :
Matthieu Moy matthieu@grenoble-inp.fr writes:
my ($namespace) = @_;
my $namespace = shift;
My impression has been that both are equally common,
The second is the most common in git-remote-mediawiki (but I don't have
any
It is convenient for the user to be able to customize the path to perl if they
do not want to use the system perl. This may be the case, for example, if the
user wants to use the plackup httpd but its extra dependencies are not
installed in the system perl; they can set the perl path to a perl
On Tue, Jun 11, 2013 at 10:00:56AM -0700, Junio C Hamano wrote:
* Accept reviewers' comments gratefully and take them very seriously.
Show that you appreciate the help by giving the reviewer the benefit of
the doubt. If, after careful consideration, you find that you cannot
agree with a
Jeff King p...@peff.net writes:
So there are no hard rules, and this is not a democracy[1]. For the most
part the community runs itself in an open and collective fashion, and
the dictator's job is easy; but ultimately, he or she is in charge of
what gets applied and what doesn't. Rules like
I've read the series while on a bus and found all of them sensible.
I do share the worry of retry storm you expressed in the last one,
and I agree that giving up after N times is a reasonable way out,
when it becomes necessary.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe
The V2 is on the launchpad but I am still struggling with the code
factoring between git-mw.perl and git-remote-mediawiki.perl :/ .
On 9 June 2013 08:08, Jeff King p...@peff.net wrote:
You could make a Git::MediaWiki.pm module, but installing that would
significantly complicate the build
On Tue, Jun 11, 2013 at 11:31:31PM +0200, Benoît Person wrote:
I've implemented this one for now but after a real-life meeting with
Matthieu Moy we discussed the possibility to build a GitMediawiki.pm
module. It seems more clean than the concatenation of perl scripts.
Plus, it would force
jorge-juan.garcia-gar...@ensimag.imag.fr writes:
diff --git a/t/t7508-status.sh b/t/t7508-status.sh
index e2ffdac..3c0818b 100755
--- a/t/t7508-status.sh
+++ b/t/t7508-status.sh
@@ -1335,4 +1335,39 @@ test_expect_failure '.git/config ignore=all suppresses
submodule summary' '
git
Add public functions fill_stat_data() and match_stat_data() to work
with it. This infrastructure will later be used to check the validity
of other types of file.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
I'm not too familiar with this part of the code, so please make sure
that
From: Jeff King p...@peff.net
Once we read the packed-refs file into memory, we cache it
to save work on future ref lookups. However, our cache may
be out of date with respect to what is on disk if another
process is simultaneously packing the refs. Normally it
is acceptable for us to be a little
Split pack_refs() into multiple passes:
* Iterate over loose refs. For each one that can be turned into a
packed ref, create a corresponding entry in the packed refs cache.
* Write the packed refs to the packed-refs file.
This change isolates the mutation of the packed-refs file to a single
From: Jeff King p...@peff.net
If we are iterating through the refs using for_each_ref (or
any of its sister functions), we can get into a race
condition with a simultaneous pack-refs --prune that looks
like this:
0. We have a large number of loose refs, and a few packed
refs.
Increment the packed_ref_cache reference count while it is locked to
prevent its being freed.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index d8e8ce2..92c8e97 100644
--- a/refs.c
+++
Handle simple transactions for the packed-refs file at the
packed_ref_cache level via new functions lock_packed_refs(),
commit_packed_refs(), and rollback_packed_refs().
Only allow the packed ref cache to be modified (via add_packed_ref())
while the packed refs file is locked.
Change clone to
It can sometimes be useful to know whether a path in the
filesystem has been updated without going to the work of
opening and re-reading its content. We trust the stat()
information on disk already to handle index updates, and we
can use the same trick here.
This patch introduces a stat_validity
This function calls a user-supplied callback function which could do
something that causes the packed refs cache to be invalidated. So
acquire a reference count on the data structure to prevent our copy
from being freed while we are iterating over it.
Signed-off-by: Michael Haggerty
Célestin Matte celestin.ma...@ensimag.fr writes:
Le 11/06/2013 20:09, Junio C Hamano a écrit :
Matthieu Moy matthieu@grenoble-inp.fr writes:
my ($namespace) = @_;
my $namespace = shift;
My impression has been that both are equally common,
The second is the most common in
New (and hopefully last version) of my series of patches to follow perlcritic's
recommandations
Changes with v3:
- Remove whitespace in [18/28]
- Typo in [09/28]
- Better line split in [22/28]
- A part of the file @@ -610,9 +610,9 @@ had escaped patches [22/31] and
[23/31] for some reason. This
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
contrib/mw-to-git/git-remote-mediawiki.perl | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/contrib/mw-to-git/git-remote-mediawiki.perl
Such a file allows to configure perlcritic.
Here, it is used to prevent to remove many unwanted rules and configure one to
remove unwanted warnings.
Signed-off-by: Célestin Matte celestin.ma...@ensimag.fr
Signed-off-by: Matthieu Moy matthieu@grenoble-inp.fr
---
1 - 100 of 147 matches
Mail list logo
