On Sun, Jun 09, 2013 at 04:25:11PM -0700, Junio C Hamano wrote:
Michael S. Tsirkin m...@redhat.com writes:
With respect to this, and a bit off-topic, what's
the best way to revise patch series?
What I did, given series in patchvN-1/:
rm -fr patchvN #blow away old directory if
Ramkumar Ramachandra artag...@gmail.com writes:
Junio C Hamano wrote:
Revert 77c1305 and 3c3b46b
The core of the argument seems to be that
__git_complete_revlist_file() is a misleading name for the completion
done by archive and ls-tree, but __git_complete_file() is somehow a
less
Jeff King p...@peff.net writes:
It may be worth looking again for other places to use this over
commit_list, but even the caller you are introducing here justifies its
presence.
The next candidate is paint-down-to-common, probably.
Also, I wrote some basic tests to cover the priority queue
Jeff King p...@peff.net writes:
The performance enhancement of the priority queue came from replacing
commit_list_insert_by_date calls with insertion into a queue. That
drops O(n^2) behavior on the linked-list down to O(n log n), as we have
n insertions, each causing an O(log n) heapify
On Mon, Jun 10, 2013 at 09:53:24AM +0300, Michael S. Tsirkin wrote:
I vaguely remember there was some way to say
head of the remote I am tracking - but I could not find it.
Where are all the tricks like foo^{} documented?
gitrevisions(7) is what you're looking for here.
In this case I think
Jeff King p...@peff.net writes:
I'm not excited about introducing yet another place that parses commit
objects (mostly not for correctness, but because we have had
inconsistency in how malformed objects are treated). It is at least
using split_ident_line which covers the hard bits. I wonder
Junio C Hamano wrote:
But it turns out that in the context of these functions it refers to
what users consider paths in objects stored in the object database
(as opposed to working tree paths). That is what ls-tree would take
(i.e. tree-ish and tree-ish:path). And I do not offhand think
of
Once again, thanks a lot your feedback, we appreciate it a lot!
Le 2013-06-08 15:51, Ramkumar Ramachandra a écrit :
Mathieu Lienard--Mayor wrote:
@@ -170,30 +175,47 @@ static int check_local_mod(unsigned char
*head, int index_only)
* intent to add entry.
*/
Felipe Contreras wrote:
git-rebase.rb | 2056
+
1 file changed, 2056 insertions(+)
create mode 100755 git-rebase.rb
I suggest putting this in contrib/ and cooking it. As usual, my
mantra is: let the patches decide what to do. I'll
Michael S. Tsirkin m...@redhat.com writes:
Not needed with recent git format-patch -v4 option.
Unless I rerun with same vX :(
Would it make sense for it to check for vX existance and fail?
Same without -vX, when 000X exists ...
Could be an option.
Oh, instead of exact -v$N, trigger it with
Le 2013-06-08 16:01, Ramkumar Ramachandra a écrit :
Mathieu Lienard--Mayor wrote:
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)
would look like, with advice.rmHints=true:
error:
Mathieu Liénard--Mayor wrote:
I'm not so sure i understand. Do you mean rmHints should deactivate addHints
aswell, or do you mean that since we're introducing rmHints it would be
natural to introduce addHints ?
More the latter, but I'm tilting towards addRmHints (or something)
which affects
El 2013-06-08 17:25, Ramkumar Ramachandra escribió:
Jorge Juan Garcia Garcia wrote:
Some people always run 'git status -s'.
The configuration variable status.short allows to set it by default.
Good feature.
@@ -1112,6 +1112,15 @@ static int git_status_config(const char *k,
const char *v,
Ramkumar Ramachandra artag...@gmail.com writes:
Mathieu Liénard--Mayor wrote:
I'm not so sure i understand. Do you mean rmHints should deactivate addHints
aswell, or do you mean that since we're introducing rmHints it would be
natural to introduce addHints ?
More the latter, but I'm tilting
Matthieu Moy wrote:
I don't see why add and rm hints should be correlated, or I don't have
the same advice as you in mind.
Both have completely different meanings: the first is about .gitignore,
and the second about not loosing data.
Right, my bad. Please continue with rmHints, and
Célestin Matte celestin.ma...@ensimag.fr writes:
A split ' ' is turned into a split / /, which changes its behaviour: the
old method matched a run of whtespaces (/\s*/)
It case there's a v4: whtespaces - whitespaces.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from
Felipe Contreras felipe.contre...@gmail.com writes:
On Sun, Jun 9, 2013 at 4:39 PM, Junio C Hamano gits...@pobox.com wrote:
One example of killing the entire thread is when I see This patch
will not be applied by Felipe in a thread started with his patch.
I understand that it is his way to
Célestin Matte celestin.ma...@ensimag.fr writes:
@@ -1285,8 +1285,7 @@ sub get_mw_namespace_id {
# Look at configuration file, if the record for that namespace
is
# already cached. Namespaces are stored in form:
# Name_of_namespace:Id_namespace,
Junio C Hamano wrote:
I am not sure what you mean by artificial.
By artificial, I mean that the precondition is absolutely unnecessary
for the code following it to work. The precondition was introduced in
a separate commit, specifically denying one usecase because the author
(you) thought that
Eric Sunshine sunsh...@sunshineco.com writes:
On Sun, Jun 9, 2013 at 6:22 PM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
Changes with v2:
- Remove patch [02/22] about using the Readonly module
- Split commit [07/22] into 5 different ones
This was easier to review after being split.
On Mon, Jun 10, 2013 at 08:29:31AM +0100, John Keeping wrote:
On Mon, Jun 10, 2013 at 09:53:24AM +0300, Michael S. Tsirkin wrote:
I vaguely remember there was some way to say
head of the remote I am tracking - but I could not find it.
Where are all the tricks like foo^{} documented?
On 06/10/2013 07:15 AM, Felipe Contreras wrote:
On Sun, Jun 9, 2013 at 6:40 PM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
I do accuse Felipe's *attitude* to bring on and nourish such
unpleasantness toxicity. His technical merits and the possible
qualities of his patches do
First things first: Junio, please don't pick up this patch.
On Sun, Jun 09, 2013 at 05:09:54PM -0700, Jonathan Nieder wrote:
SZEDER Gábor wrote:
Fedore 9 shipped the gvfs package with a buggy Bash completion script:
it removed the ':' character from COMP_WORDBREAKS, thereby breaking
Ramkumar Ramachandra artag...@gmail.com writes:
I don't understand why upstream/ simple should _not_ push to a
different destination from the one being merged from. I'll repeat:
push source/ destination is orthogonal to push refspec, and
push.default modes dictate the refspec.
That is where
On Sun, Jun 09, 2013 at 03:41:54PM -0500, Felipe Contreras wrote:
There
will not be a need for test_string_must_be_empty() just like there's
no need for test_string_cmp().
Actually, if there were a test_string_cmp(), that would be the test
helper function I used most often.
--
To unsubscribe
Le 10/06/2013 02:50, Eric Sunshine a écrit :
Given this patch's intention to use ${} within strings, should this be
${credential{username}}?
(I don't have a preference, but it's a genuine question since it's not
clear if this was an oversight or intentional.)
The answer is simple: I didn't
Le 10/06/2013 10:37, Matthieu Moy a écrit :
Célestin Matte celestin.ma...@ensimag.fr writes:
@@ -1285,8 +1285,7 @@ sub get_mw_namespace_id {
# Look at configuration file, if the record for that namespace
is
# already cached. Namespaces are stored in form:
Le 08/06/2013 10:33, Mathieu Lienard--Mayor a écrit :
+ if (files_staged.len)
+ errs = error(_(the following files have staged content
+different from both the\nfileand the HEAD:%s\n
+(use -f to force removal)),
On Mon, Jun 10, 2013 at 7:48 AM, Johannes Sixt j.s...@viscovery.net wrote:
From: Erik Faye-Lund kusmab...@gmail.com
Returning the SIGALRM handler for SIGINT is not very useful.
Signed-off-by: Erik Faye-Lund kusmab...@gmail.com
Signed-off-by: Johannes Sixt j...@kdbg.org
---
Am 6/7/2013
On Mon, Jun 10, 2013 at 7:30 AM, Johannes Sixt j.s...@viscovery.net wrote:
Am 6/9/2013 22:31, schrieb Junio C Hamano:
Jeff King p...@peff.net writes:
I'm a little negative on handling just SIGTERM. That would make the test
pass, but does it really address the overall issue? To me, the
Junio C Hamano wrote:
The name under which the local branch is published needs a sensible
default (when branch.$name.push is not specified), and I agree that
you would get the name of the branch my work was forked from if you
reuse the upstream code. I am saying that it does not necessarily
[-CC: Duy, since he has left the community]
Junio: since Duy is no longer around to guide us, I will rely on your guidance.
Duy Nguyen wrote:
I'm starting to think this is a half-baked solution. It hides
problems, for example commit placeholders should produce empty string,
not the literal
On Sun, Jun 09, 2013 at 02:47:57PM +0200, Bernhard R. Link wrote:
* Ian Kumlien po...@vapor.com [130605 13:31]:
Yes, i agree, it's suboptimal but I for one would use getpwuid to get
the home directory of the executing user to avoid this - though i don't
know how portable it is (or if there
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
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)
Please ignore this, manipulation error while in the git send-email
command line.
Le 2013-06-10 14:51, Mathieu Lienard--Mayor a écrit :
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
Please ignore this, manipulation error while in the git send-email
command line.
Le 2013-06-10 14:51, Mathieu Lienard--Mayor a écrit :
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
Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :
0. You do not take offense, no matter what. If someone attacks you
irrationally, you do not respond. This is a public mailing list, and
we are all rational people: the attacker has already humiliated
herself in public, and everyone can see
Célestin Matte celestin.ma...@ensimag.fr writes:
Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :
0. You do not take offense, no matter what. If someone attacks you
irrationally, you do not respond. This is a public mailing list, and
we are all rational people: the attacker has already
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)
Most users seem to like having colors enabled, and colors can help
beginners to understand the output of some commands (e.g. notice
immediately the boundary between commits in the output of git log).
Many tutorials tell the users to set color.ui=auto as a very first step,
which tend to indicate
The meaning of get_colorbool_found and get_diff_color_found is the
config value if found, and -1 otherwise, but get_color_ui_found had a
slightly different meaning, as it has the value 0 (which corresponds to
the default value from the user point of view) when color.ui is unset.
Make
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
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 Lienard--Mayor mathieu.lienard--ma...@ensimag.imag.fr
Signed-off-by: Matthieu Moy
On Mon, Jun 10, 2013 at 8:44 AM, Célestin Matte
celestin.ma...@ensimag.fr wrote:
Since nobody answered you (publicly at least), I will try doing it myself:
I think the best thing to do if you want a feature to be added is to
come with a patch and request for comments on it. Then, people will
Jorge Juan Garcia Garcia jorge-juan.garcia-gar...@ensimag.imag.fr
writes:
+test_expect_success 'Setup of environment of test' '
Why these double quotes inside single quotes?
+test_expect_success 'Back to environment of test by default' '
Same.
test environment would sound better than
Hi,
using gitk (git 1.8.3), the program gets stuck when checking out a new
branch if the last checked-out branch was the bottom left branch. The
error occurs consistently in this repository, but unfortunately, I
cannot reproduce the error on another repository. The message reads:
invalid command
Some people often run 'git status -b'.
The config variable status.branch allows to set it by default.
Signed-off-by: Jorge Juan Garcia Garcia
jorge-juan.garcia-gar...@ensimag.imag.fr
Signed-off-by: Mathieu Lienard--Mayor mathieu.lienard--ma...@ensimag.imag.fr
Signed-off-by: Matthieu Moy
Le 2013-06-10 16:38, Matthieu Moy a écrit :
Mathieu Lienard--Mayor mathieu.lienard--ma...@ensimag.imag.fr
writes:
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
Mathieu Liénard--Mayor mathieu.lienard--ma...@ensimag.fr writes:
Well the current code is only using errs=error(...), using the same
variable errs over and over, no matter how many times it loops.
That's why i implemented it similarly.
OK, consistency is a good argument then.
--
Matthieu
SZEDER Gábor sze...@ira.uka.de writes:
On Sun, Jun 09, 2013 at 03:41:54PM -0500, Felipe Contreras wrote:
There
will not be a need for test_string_must_be_empty() just like there's
no need for test_string_cmp().
Actually, if there were a test_string_cmp(), that would be the test
helper
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)
Ramkumar Ramachandra artag...@gmail.com writes:
[-CC: Duy, since he has left the community]
Junio: since Duy is no longer around to guide us, I will rely on your
guidance.
Duy Nguyen wrote:
I'm starting to think this is a half-baked solution. It hides
problems, for example commit
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
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
Mathieu Lienard--Mayor mathieu.lienard--ma...@ensimag.imag.fr writes:
+static void print_eventual_error_files(struct string_list *files_list,
Too french ;-).
Eventual (en) = final, utlime (fr).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
--
To unsubscribe from this list: send the line
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)
Junio C Hamano wrote:
Only if I want to publish the result of the work forked from your
triangle as my triangle, but that is not the case. A fork to be
integrated by other is by definition more specialized than the
original, and I would publish my pushbranch subtopic as such, not
as
Hi,
So, this 'git checkout -' not working after a 'rebase -i' has annoyed
me to no end. This is the fix.
Unfortunately, some tests fail and I'm still tracking down what
exactly is going on.
Thanks.
Ramkumar Ramachandra (3):
t/checkout-last: checkout - doesn't work after rebase -i
The following command
$ git checkout -
does not work as expected after a 'git rebase -i'.
Add a failing test documenting this bug.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t2012-checkout-last.sh | 8
1 file changed, 8 insertions(+)
diff --git
Invoking 'git rebase -i' writes the following line to the reflog at the
start of the operation:
rebase -i (start)
This is not very useful. Make it more informative like:
rebase -i (start): checkout master
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
GIT_REFLOG_ACTION is an environment variable specifying the reflog
message to write after an action is completed. Other commands including
merge, reset, and commit respect it.
This incidentally fixes a bug in t/checkout-last. You can now expect
$ git checkout -
to work fine after an
On Mon, Jun 10, 2013 at 04:04:29PM +0200, Matthieu Moy wrote:
Célestin Matte celestin.ma...@ensimag.fr writes:
Le 10/06/2013 15:28, Ramkumar Ramachandra a écrit :
0. You do not take offense, no matter what. If someone attacks you
irrationally, you do not respond. This is a public
Matthieu Moy matthieu@grenoble-inp.fr writes:
Célestin Matte celestin.ma...@ensimag.fr writes:
@@ -1285,8 +1285,7 @@ sub get_mw_namespace_id {
# Look at configuration file, if the record for that namespace
is
# already cached. Namespaces are stored in form:
On Mon, Jun 10, 2013 at 3:32 AM, Junio C Hamano gits...@pobox.com wrote:
Felipe Contreras felipe.contre...@gmail.com writes:
On Sun, Jun 9, 2013 at 4:39 PM, Junio C Hamano gits...@pobox.com wrote:
One example of killing the entire thread is when I see This patch
will not be applied by Felipe
On Mon, Jun 10, 2013 at 11:53 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Jun 10, 2013 at 3:32 AM, Junio C Hamano gits...@pobox.com wrote:
E.g.
convincing people that it is not worth their time interacting with
you, especially when there are better things to do like tending
Mathieu Liénard--Mayor mathieu.lienard--ma...@ensimag.fr writes:
Please ignore this, manipulation error while in the git send-email
command line.
Here is what my mailbox looks like (the penultimate one with 252
lines is what I am responding to).
R. [ 146: Mathieu Lienard--Mayor ] [PATCH
On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
You need two sides to have an argument.
I disagree. Unless you mean than, whenever a part behaves in a
hostile and aggressive way, the other part should just silently
knuckle under.
You are wrong. If a
On Mon, Jun 10, 2013 at 10:56 AM, Junio C Hamano gits...@pobox.com wrote:
By the way, test_cmp() is a replacement for the cmp command and
that is why it does not have file in its name.
That's an irrelevant implementation detail. But if you want to be
driven the the implementation, call it
Mathieu Lienard--Mayor mathieu.lienard--ma...@ensimag.imag.fr
writes:
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
Well, I think next step would be to replace all those calls with
Git.pm `command`, `command_oneline` and `config``which take an array
of arguments after the command. In the preview tool we use those but
I don't know if we will find the time to clean that up too in
git-remote-mediawiki :) .
Don't
On Mon, Jun 10, 2013 at 2:48 AM, Ramkumar Ramachandra
artag...@gmail.com wrote:
Felipe Contreras wrote:
git-rebase.rb | 2056
+
1 file changed, 2056 insertions(+)
create mode 100755 git-rebase.rb
I suggest putting this in contrib/
Le 2013-06-10 18:57, Junio C Hamano a écrit :
Mathieu Liénard--Mayor mathieu.lienard--ma...@ensimag.fr writes:
Please ignore this, manipulation error while in the git send-email
command line.
Here is what my mailbox looks like (the penultimate one with 252
lines is what I am responding to).
Mathieu Lienard--Mayor mathieu.lienard--ma...@ensimag.imag.fr
writes:
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
On Mon, Jun 10, 2013 at 08:56:58AM -0700, Junio C Hamano wrote:
SZEDER Gábor sze...@ira.uka.de writes:
On Sun, Jun 09, 2013 at 03:41:54PM -0500, Felipe Contreras wrote:
There
will not be a need for test_string_must_be_empty() just like there's
no need for test_string_cmp().
Please, don't top-post. Quote the part of the message you're replying
to, and reply below.
Benoît Person benoit.per...@ensimag.fr writes:
Well, I think next step would be to replace all those calls with
Git.pm `command`, `command_oneline` and `config``which take an array
of arguments after
Felipe Contreras felipe.contre...@gmail.com writes:
It is not bad behavior. It is bad behavior *in your opinion*,
And in essentially everyone else on this list, it seems.
an opinion that wouldn't be shared by other projects, like the Linux
kernel.
Googling your name and LKML gives me this
Matthieu Moy matthieu@grenoble-inp.fr writes:
y...@ensimag.imag.fr writes:
To: y...@ensimag.imag.fr
Common mistake, but you're not supposed to answer y when you're
prompted for an email ;-).
Didn't we introduce safety against this in v1.7.12.1 and later? Is
the new release taking more
Matthieu Moy wrote:
https://lkml.org/lkml/2012/4/12/434
https://lkml.org/lkml/2012/4/15/112
We don't want things taken out of context now, do we? Follow up this
thread [1], if you're interested in that discussion. I did clip out
the quotes you chose on purpose, in the interest of presenting
On Mon, Jun 10, 2013 at 9:58 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Mon, Jun 10, 2013 at 4:05 AM, Stefano Lattarini
stefano.lattar...@gmail.com wrote:
You need two sides to have an argument.
I disagree. Unless you mean than, whenever a part behaves in a
hostile and
On Mon, Jun 10, 2013 at 12:21:00AM -0700, Junio C Hamano wrote:
It may be worth looking again for other places to use this over
commit_list, but even the caller you are introducing here justifies its
presence.
The next candidate is paint-down-to-common, probably.
Yeah, I don't think I
Jorge Juan Garcia Garcia jorge-juan.garcia-gar...@ensimag.imag.fr
writes:
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
Jorge Juan Garcia Garcia jorge-juan.garcia-gar...@ensimag.imag.fr
writes:
Some people often run 'git status -b'.
The config variable status.branch allows to set it by default.
Signed-off-by: Jorge Juan Garcia Garcia
jorge-juan.garcia-gar...@ensimag.imag.fr
Signed-off-by: Mathieu
On Mon, Jun 10, 2013 at 12:27:31AM -0700, Junio C Hamano wrote:
Around the same time, though, René wrote the linked-list merge sort that
powers commit_list_sort_by_date. And topo-sort learned to do O(1)
insertions into the unsorted list, and then one O(n log n) sort.
Yes, but that only
Junio C Hamano gits...@pobox.com writes:
test_expect_success '-c status.short=true == status -s' '
test_config status.showUntrackedFile no
That's an option, but having status.showUntrackedFile set in a separate
setup test makes the actual tests shorter. The setup test has
Ramkumar Ramachandra artag...@gmail.com writes:
The following command
$ git checkout -
does not work as expected after a 'git rebase -i'.
Add a failing test documenting this bug.
Signed-off-by: Ramkumar Ramachandra artag...@gmail.com
---
t/t2012-checkout-last.sh | 8
1
Ramkumar Ramachandra artag...@gmail.com writes:
GIT_REFLOG_ACTION is an environment variable specifying the reflog
message to write after an action is completed. Other commands including
merge, reset, and commit respect it.
This incidentally fixes a bug in t/checkout-last. You can now
Ramkumar Ramachandra artag...@gmail.com writes:
Invoking 'git rebase -i' writes the following line to the reflog at the
start of the operation:
rebase -i (start)
This is not very useful. Make it more informative like:
rebase -i (start): checkout master
Makes sense to me, at least
Signed-off-by: Richard Hartmann richih.mailingl...@gmail.com
---
Documentation/githooks.txt |3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/Documentation/githooks.txt b/Documentation/githooks.txt
index b9003fe..1276730 100644
--- a/Documentation/githooks.txt
+++
The other hooks use two whitespace for indentation instead of tabs
to signify code in the example/echo output.
Follow the same layout in templates/hooks--pre-rebase.sample
Signed-off-by: Richard Hartmann richih.mailingl...@gmail.com
---
templates/hooks--pre-rebase.sample | 10 +-
1
Now that the there's only one echo being spawned, the message can span
the full 80 chars.
Signed-off-by: Richard Hartmann richih.mailingl...@gmail.com
---
templates/hooks--pre-commit.sample |6 ++
1 file changed, 2 insertions(+), 4 deletions(-)
diff --git
The example assumes 8-char wide tabs and breaks for people with
4-char wide tabs.
Signed-off-by: Richard Hartmann richih.mailingl...@gmail.com
---
templates/hooks--pre-rebase.sample | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git
Signed-off-by: Richard Hartmann richih.mailingl...@gmail.com
---
templates/hooks--pre-commit.sample |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/templates/hooks--pre-commit.sample
b/templates/hooks--pre-commit.sample
index 7676c6e..a982d99 100755
---
Spawning a new subprocess for every line printed is inefficient.
Thus spawn only one instance of `echo`.
Signed-off-by: Richard Hartmann richih.mailingl...@gmail.com
---
templates/hooks--pre-commit.sample | 24
1 file changed, 12 insertions(+), 12 deletions(-)
diff
Dear all,
attached, you will find a series of small, obvious, and hopefully
uncontroversial patches for the hook templates and the manpage.
They are all tiny, but I still decided to submit distinct patches
to make modification/discussion easier.
Richard Hartmann (6):
templates: Fewer
Junio C Hamano wrote:
I am curious what breaks, though.
t/status-help. Looks seriously unrelated, and I'm breaking my head
over it. Any clues?
--- expected2013-06-10 17:16:42.276356867 +
+++ actual 2013-06-10 17:16:42.279690201 +
@@ -1,4 +1,4 @@
-# HEAD detached at 000106f
+#
Yes, sorry. I find this whole story quite amusing (albeit distracting
and unnecessary), but sorry for adding to the spam. I'll be quiet now.
On Mon, Jun 10, 2013 at 11:33 AM, Martin Langhoff
martin.langh...@gmail.com wrote:
On Mon, Jun 10, 2013 at 2:11 PM, Martin von Zweigbergk
On Mon, Jun 10, 2013 at 12:39:24AM -0700, Junio C Hamano wrote:
I'm not excited about introducing yet another place that parses commit
objects (mostly not for correctness, but because we have had
inconsistency in how malformed objects are treated). It is at least
using split_ident_line
Jeff King p...@peff.net writes:
On Mon, Jun 10, 2013 at 12:21:00AM -0700, Junio C Hamano wrote:
It may be worth looking again for other places to use this over
commit_list, but even the caller you are introducing here justifies its
presence.
The next candidate is paint-down-to-common,
On Mon, Jun 10, 2013 at 11:56:33AM -0700, Junio C Hamano wrote:
or similar. I didn't change the name, either. It may be silly to call it
commit_queue still since it is now more general. I simply called mine
queue (I wanted pqueue, but that conflicted with globals defined by
OpenSSL; yours
1 - 100 of 153 matches
Mail list logo