Did some simple changing to the chain of if() statements in function
install_branch_config() of branch.c
This was a micro-project for GSOC 2014
>From aebfa60feb643280c89b54e5ab87f9d960cde452 Mon Sep 17 00:00:00 2001
From: Nemina Amarasinghe
Date: Mon, 10 Mar 2014 13:02:55 +0530
Subject: [PATCH]
Le dimanche 09 mars 2014 à 19:24 -0400, Andrew Keller a écrit :
> On Mar 7, 2014, at 7:50 PM, Henri GEIST wrote:
> > Le vendredi 07 mars 2014 à 15:37 -0800, Junio C Hamano a écrit :
> >> Henri GEIST writes:
> >>
> >>> This information is technical in nature but has some importance for
> >>> gene
Nemina Amarasinghe gmail.com> writes:
Sorry for the first patch. Something went wrong. This is the correct one
>From aebfa60feb643280c89b54e5ab87f9d960cde452 Mon Sep 17 00:00:00 2001
From: Nemina Amarasinghe
Date: Mon, 10 Mar 2014 13:02:55 +0530
Subject: [PATCH] simplified the chain if() state
Am 3/5/2014 1:10, schrieb Junio C Hamano:
> * nd/gitignore-trailing-whitespace (2014-02-10) 2 commits
> - dir: ignore trailing spaces in exclude patterns
> - dir: warn about trailing spaces in exclude patterns
>
> Warn and then ignore trailing whitespaces in .gitignore files,
> unless they are
Nemina Amarasinghe writes:
> Nemina Amarasinghe gmail.com> writes:
>
> Sorry for the first patch. Something went wrong. This is the correct one
Please, re-read Documentation/SubmittingPatches. In short, don't inline
patch headers and don't forget the sign-off.
> Subject: [PATCH] simplified the
On 03/09/2014 03:49 AM, Nguyễn Thái Ngọc Duy wrote:
> Prepare the todo list for you to edit/reword/delete the given commit.
>
> Signed-off-by: Nguyễn Thái Ngọc Duy
> ---
> Allowing multiple actions is a bit too much for my shell skills. I
> don't really need it so I won't push it, but if somebo
On 03/09/2014 02:54 AM, Kyle J. McKay wrote:
> On Mar 3, 2014, at 23:58, Michael Haggerty wrote:
>> list
>> regulars should FEEL ENCOURAGED to submit microprojects to add to the
>> list. (Either submit them as a pull request to the GitHub repository
>> that contains the text [1] or to the mailing
Matthieu Moy writes:
> Nemina Amarasinghe writes:
>
>> Nemina Amarasinghe gmail.com> writes:
>>
>> Sorry for the first patch. Something went wrong. This is the correct one
>
> Please, re-read Documentation/SubmittingPatches. In short, don't inline
> patch headers and don't forget the sign-off.
Michael Haggerty writes:
>> @@ -290,6 +294,7 @@ do
>> ;;
>> --autostash)
>> autostash=true
>> +explicit_autosquash=t
>
> Should that be "explicit_autostash"?
My guess is: no, but it should be below the --autoquash case, not this
one.
--
Matthieu Moy
h
>
> Nemina Amarasinghe gmail.com> writes:
>
> Is it me, or is (origin || !origin) a tautology?
>
Thanks for the advices Matthieu. I will go through the documentations again.
Is there anything wrong with my logic?
What I wanted to express is
((!remote_is_branch && origin) || (!remote_is_branch
Nemina Amarasinghe writes:
>>
>> Nemina Amarasinghe gmail.com> writes:
>>
>> Is it me, or is (origin || !origin) a tautology?
>>
> Thanks for the advices Matthieu. I will go through the documentations again.
> Is there anything wrong with my logic?
> What I wanted to express is
> ((!remote_
Nemina Amarasinghe writes:
>>
>> Nemina Amarasinghe gmail.com> writes:
>>
>> Is it me, or is (origin || !origin) a tautology?
>>
> Thanks for the advices Matthieu. I will go through the documentations again.
> Is there anything wrong with my logic?
> What I wanted to express is
> ((!remote_
Le samedi 08 mars 2014 à 00:00 +0100, Jens Lehmann a écrit :
> Am 06.03.2014 23:20, schrieb Henri GEIST:
> > Le jeudi 06 mars 2014 à 21:51 +0100, Jens Lehmann a écrit :
> >> Am 06.03.2014 21:15, schrieb Henri GEIST:
> >>> Le jeudi 06 mars 2014 à 20:48 +0100, Jens Lehmann a écrit :
> Am 06.03.2
> > ((!remote_is_branch && origin) || (!remote_is_branch || !origin))
>
> Is it?
>
> The above is the same as (!remote_is_branch || !origin). What you wrote
> before is the same as (!remote_is_branch).
>
> Maybe you should try copy&paste from the expressions you are trying to
> combine to make
Nemina Amarasinghe writes:
>> > ((!remote_is_branch && origin) || (!remote_is_branch || !origin))
>>
>> Is it?
>>
>> The above is the same as (!remote_is_branch || !origin). What you wrote
>> before is the same as (!remote_is_branch).
>>
>> Maybe you should try copy&paste from the expressions
Ilya Bobyr writes:
> There is a "git remote set-head" to manipulate HEAD in a remote repository.
This is misleading. The command does nothing on the remote side, it
only changes the refs/remote namespace in your repository. The purpose
is to change what branch the ref remote/ resolves to, ie.
according to these blog posts
http://www.infoq.com/news/2014/01/facebook-scaling-hg
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
mercurial "can" be faster then git
but i don't found any reply from the git community if it is a real problem
or if there a ongoing
On Mon, 10 Mar 2014, Dennis Luehring wrote:
according to these blog posts
http://www.infoq.com/news/2014/01/facebook-scaling-hg
https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
mercurial "can" be faster then git
but i don't found any reply from the git community
I accidentially deleted a directory using git clean. I would think
this is a bug, but I'm not sure. Was using 1.8.1, but upgraded to
1.9.0 just to see if it was still reproducable, and it was.
Here's a minimal way to reproduce:
$ git init
$ mkdir foo foobar
$ git clean -df foobar
Removing foo/
Re
I have started working on pluggable ref backends. In this email I
would like to share my plans and solicit feedback.
(This morning I removed this project from the GSoC ideas page, because
it is unfair to ask a student to shoot at a moving target.)
Why?
Currently, the reference- and reflog-
On 10 March 2014 11:07, Dennis Luehring wrote:
> according to these blog posts
>
> http://www.infoq.com/news/2014/01/facebook-scaling-hg
> https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
>
> mercurial "can" be faster then git
>
> but i don't found any reply from the
Am 10.03.2014 12:28, schrieb demerphq:
I had the impression, and I would not be surprised if they had the
impression that the git development community is relatively
unconcerned about performance issues on larger repositories.
so the question is if the git community is interested in beeing
com
On Mon, Mar 10, 2014 at 12:00 PM, Michael Haggerty wrote:
> I have started working on pluggable ref backends. In this email I
> would like to share my plans and solicit feedback.
No comments or useful feedback yet, except that I enthusiastically
approve of the objective and the plan you have for
On Mon, Mar 10, 2014 at 12:42 PM, Dennis Luehring wrote:
> Am 10.03.2014 12:28, schrieb demerphq:
>
>> I had the impression, and I would not be surprised if they had the
>> impression that the git development community is relatively
>> unconcerned about performance issues on larger repositories.
>
Given that these constants are only being used when updating
references, it is inappropriate to give them such generic names as
"DIE_ON_ERR". So prefix their names with "UPDATE_REFS_".
Signed-off-by: Michael Haggerty
---
builtin/checkout.c | 2 +-
builtin/clone.c
Add a docstring to the function incorporating the comments that were
formerly within the function plus some added information. Test that
the argument is properly terminated by either whitespace or a NUL
character, even if it is quoted, to be consistent with the non-quoted
case. Adjust the tests t
The test
stdin -z create ref fails with zero new value
actually passes an empty new value, not a zero new value. So rename
the test s/zero/empty/, and change the expected error from
fatal: create $c given zero new value
to
fatal: create $c missing
Of course, this makes the test
I just sent an email to the list [1] describing how I want to
decouple reference-handling code from the rest of Git, and implement
pluggable reference storage backends. This patch series is the first
movement in that direction.
update_refs() and "update-ref --stdin" implement the beginning of
tra
This should be done via reference transactions now. This also means
that struct ref_update can become private.
Signed-off-by: Michael Haggerty
---
refs.c | 31 ---
refs.h | 20
2 files changed, 20 insertions(+), 31 deletions(-)
diff --git a/refs
This change is mostly clerical: the parse_cmd_*() functions need to
use local variables rather than a struct ref_update to collect the
arguments needed for each update, and then call queue_*_ref() to queue
the change rather than building up the list of changes at the caller
side.
Signed-off-by: Mi
If an invalid value is passed to "update-ref --stdin" as or
, include the command and the name of the reference at the
beginning of the error message. Update the tests accordingly.
Signed-off-by: Michael Haggerty
---
builtin/update-ref.c | 24 +---
t/t1400-update-ref.sh |
Decouple the parsing code from the input source (the old parsing code
had to read new data even in the middle of commands). This might also
be a tad faster, but that is inconsequential. Add docstrings for the
parsing functions.
Signed-off-by: Michael Haggerty
---
builtin/update-ref.c | 170 +++
Distinguish this error from the error that an argument is missing for
another reason. Update the tests accordingly.
Signed-off-by: Michael Haggerty
---
builtin/update-ref.c | 4 ++--
t/t1400-update-ref.sh | 10 +-
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/builtin/
Instead of, for example,
fatal: update refs/heads/master missing [] NUL
emit
fatal: update refs/heads/master missing
Update the tests accordingly.
Signed-off-by: Michael Haggerty
---
builtin/update-ref.c | 6 +++---
t/t1400-update-ref.sh | 6 +++---
2 files changed, 6 insertions(+)
The old version was passing (among other things)
update SP refs/heads/c NUL NUL 0{40} NUL
to "git update-ref -z --stdin" to test whether the old-value check for
c is working. But the is empty, which is not allowed for
the "update" command.
So, to be sure that we are testing what we want to
The old error messages emitted for invalid input sometimes said
""/"" and sometimes said "old value"/"new value".
Convert them all to the former. Update the tests accordingly.
Signed-off-by: Michael Haggerty
---
builtin/update-ref.c | 8
t/t1400-update-ref.sh | 14 +++---
2 f
Build out the API for dealing with a bunch of reference checks and
changes within a transaction. Define an opaque ref_transaction type
that is managed entirely within refs.c. Introduce functions for
starting a transaction, adding updates to a transaction, and
committing a transaction.
This API w
Replace three functions, update_store_new_sha1(),
update_store_old_sha1(), and parse_next_arg(), with a single function,
parse_next_sha1(). The new function takes care of a whole argument,
including checking whether it is there, converting it to an SHA-1, and
emitting errors on EOF or for invalid
Use temporary variables in the for-loop blocks to simplify expressions
in the rest of the loop.
Signed-off-by: Michael Haggerty
---
refs.c | 25 -
1 file changed, 16 insertions(+), 9 deletions(-)
diff --git a/refs.c b/refs.c
index 335d0e2..ec638e9 100644
--- a/refs.c
+++
Now that we free the transaction when we are done, there is no need to
make a copy of transaction->updates before working with it.
Signed-off-by: Michael Haggerty
---
refs.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index d83fc7b..ea33adc 100644
---
Previously there were no good tests of C-quoted arguments.
Signed-off-by: Michael Haggerty
---
t/t1400-update-ref.sh | 26 +-
1 file changed, 25 insertions(+), 1 deletion(-)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index 5836842..627aaaf 100755
--- a/t/
There is no reason to obscure the fact that parse_first_arg() always
parses refnames. Form the new function by combining parse_first_arg()
and update_store_ref_name().
Signed-off-by: Michael Haggerty
---
builtin/update-ref.c | 90
1 file chan
Since full const correctness is beyond the ability of C's type system,
just put the const where it doesn't do any harm. A (struct ref_update
**) can be passed to a (struct ref_update * const *) argument, but not
to a (const struct ref_update **) argument.
Signed-off-by: Michael Haggerty
---
bui
This is consistent with the usual nomenclature.
Signed-off-by: Michael Haggerty
---
refs.c | 18 +-
refs.h | 2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/refs.c b/refs.c
index 91af0a0..5d08cdf 100644
--- a/refs.c
+++ b/refs.c
@@ -3274,7 +3274,7 @@ stati
Aside from avoiding work, this makes it transparently obvious that
old_sha1 and new_sha1 are identical.
Signed-off-by: Michael Haggerty
---
builtin/update-ref.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/update-ref.c b/builtin/update-ref.c
index 5f197fe..51adf2d
Make (most of) the error messages for invalid input have the same
format [1]:
$COMMAND [SP $REFNAME]: $MESSAGE
Update the tests accordingly.
[1] A few error messages still have their old form, because $COMMAND
and $REFNAME aren't passed all the way down the call stack.
Signed-off-by: Michae
Change commit_ref_transaction() to also free the associated data, to
absolve the caller from having to do it.
Signed-off-by: Michael Haggerty
---
builtin/update-ref.c | 1 -
refs.c | 1 +
refs.h | 11 ++-
3 files changed, 7 insertions(+), 6 deletions(-)
dif
This is temporary space for commit_ref_transaction()
Signed-off-by: Michael Haggerty
---
refs.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/refs.c b/refs.c
index 73aec88..1fd38b0 100644
--- a/refs.c
+++ b/refs.c
@@ -3279,6 +3279,7 @@ struct ref_update {
in
This test is trying to test a few ways to delete references using "git
update-ref -z --stdin". The third line passed in is
update SP /refs/heads/c NUL NUL NUL
, which is not a correct way to delete a reference according to the
documentation (the new value should be zeros, not empty). Pass
Is there any update on this patch?
Le 2014-03-03 09:55, Sandy Carter a écrit :
Separate message from command examples to avoid translation issues
such as a dash being omitted in a translation.
Signed-off-by: Sandy Carter
---
builtin/branch.c | 10 ++
1 file changed, 6 insertions(+),
Hi,
Le vendredi 07 mars 2014 à 11:43 -0800, Junio C Hamano a écrit :
> Andreas Schwab writes:
>
> > Yann Droneaud writes:
> >
> >> But I'd like to know if there's a specific reason for git merge to not
> >> support --date and --author ?
> >
> > It's rather unusual that a merge is performed on b
Signed-off-by: Michael Haggerty
---
refs.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/refs.c b/refs.c
index 5d08cdf..335d0e2 100644
--- a/refs.c
+++ b/refs.c
@@ -3274,11 +3274,11 @@ static int update_ref_write(const char *action, const
char *refname,
*
Now that we manage ref_update objects internally, we can use them to
hold some of the scratch space we need when actually carrying out the
updates. Store the (struct ref_lock *) there.
Signed-off-by: Michael Haggerty
---
refs.c | 32
1 file changed, 16 insertion
On Mon, Mar 10, 2014 at 1:46 PM, Michael Haggerty wrote:
> Previously there were no good tests of C-quoted arguments.
>
> Signed-off-by: Michael Haggerty
FWIW, the first 5 patches seem trivially correct to me. Feel free to add:
Reviewed-by: Johan Herland
--
Johan Herland,
www.herland.net
--
Am 10.03.2014 12:42, schrieb Dennis Luehring:
> Am 10.03.2014 12:28, schrieb demerphq:
>> I had the impression, and I would not be surprised if they had the
>> impression that the git development community is relatively
>> unconcerned about performance issues on larger repositories.
>
> so the que
On Mon, Mar 10, 2014 at 4:00 AM, Michael Haggerty wrote:
> I have started working on pluggable ref backends. In this email I
> would like to share my plans and solicit feedback.
Yay!
JGit already has pluggable ref backends, so it is good to see this
starting in git-core.
FWIW the Gerrit Code R
On 03/10/2014 01:10 PM, Johan Herland wrote:
> It should be possible to teach Git to do similar things, and IINM
> there are (and have previously been) several attempts to do similar
> things in Git, e.g.:
>
> - http://thread.gmane.org/gmane.comp.version-control.git/240339
>
> - http://thread.g
Julian Brost writes:
> On 07.03.2014 22:04, Jeff King wrote:
>>
>> If you want to work on it, I think it's an interesting area. But
>> any development would need to think about the transition plan for
>> existing sites that will be broken.
>
> I can understand the problem with backward compatibi
Duy Nguyen writes:
> On Sat, Mar 8, 2014 at 1:27 AM, Junio C Hamano wrote:
On the receive-pack side, the comment at the bottom of
preprare_shallow_update() makes it clear that, if we wanted to use
hooks, we cannot avoid having the proposed new shallow-file in a
temporary file
Øystein Walle writes:
> Junio C Hamano pobox.com> writes:
>
>>
>> ...
>>
>> is easier to read and maintain if written like so (with using HT
>> properly---our MUAs may damage it and turn the indentation into
>> spaces):
>>
>> ... &&
>> sed -e "s/ Z$/ /" >>expect <<-\EOF &&
>>
Andrew Keller writes:
> On Mar 7, 2014, at 7:50 PM, Henri GEIST wrote:
> ...
>> To give one of my project to someone else I have copied it on a USB key.
>> By a simple drag and drop with the mouse.
>> And I am quite sure I am not alone doing this way.
>>
>> I have done those kind of things lot o
Rohit Mani writes:
> Avoid scanning strings twice, once with strchr() and then with
> strlen(), by using strchrnul().
Thanks. The patch looks good.
--
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
On 10.03.2014, at 15:30, Shawn Pearce wrote:
> On Mon, Mar 10, 2014 at 4:00 AM, Michael Haggerty
> wrote:
>> I have started working on pluggable ref backends. In this email I
>> would like to share my plans and solicit feedback.
>
> Yay!
Yay, too!
> JGit already has pluggable ref backends,
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
> > * Store references in a SQLite database, to get correct transaction
> > handling.
>
> No to SQLLite in git-core. Using it from JGit requires building
> SQLLite and a JNI wrapper, which makes JGit significantly less
> portable. I
Jeff King writes:
> On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
>
>> > * Store references in a SQLite database, to get correct transaction
>> > handling.
>>
>> No to SQLLite in git-core. Using it from JGit requires building
>> SQLLite and a JNI wrapper, which makes JGit signi
On Mon, 10 Mar 2014, David Kastrup wrote:
Jeff King writes:
On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
* Store references in a SQLite database, to get correct transaction
handling.
No to SQLLite in git-core. Using it from JGit requires building
SQLLite and a JNI wrapp
On 03/10/2014 08:46 AM, Michael Haggerty wrote:
> This test is trying to test a few ways to delete references using "git
> update-ref -z --stdin". The third line passed in is
>
> update SP /refs/heads/c NUL NUL NUL
>
> , which is not a correct way to delete a reference according to the
> do
On 03/10/2014 01:08 PM, Brad King wrote:
>> -die("update %s missing [] NUL", update->ref_name);
>> +die("update %s missing ", update->ref_name);
>
> The reason for the original wording is that the is indeed
> optional. This can only occur at end-of-input, and it is actual
On 03/10/2014 08:46 AM, Michael Haggerty wrote:
> Instead of, for example,
>
> fatal: update refs/heads/master missing [] NUL
>
> emit
>
> fatal: update refs/heads/master missing
[snip]
> - die("update %s missing [] NUL", update->ref_name);
> + die("update %s mis
git-clean uses read_directory to fill in a `struct dir` with
potential hits. However, read_directory does not actually
check against our pathspec. It uses a simplified version
that may turn up false positives. As a result, we need to
check that any hits match our pathspec. We do so reliably
for non
On Mon, Mar 10, 2014 at 01:20:02PM -0400, Jeff King wrote:
> On Mon, Mar 10, 2014 at 11:31:37AM +0100, Robin Pedersen wrote:
>
> > I accidentially deleted a directory using git clean. I would think
> > this is a bug, but I'm not sure. Was using 1.8.1, but upgraded to
> > 1.9.0 just to see if it w
On Mon, Mar 10, 2014 at 01:20:02PM -0400, Jeff King wrote:
> git-clean uses read_directory to fill in a `struct dir` with
> potential hits. However, read_directory does not actually
> check against our pathspec. It uses a simplified version
> that may turn up false positives. As a result, we need
Hi Michael,
This is excellent work.
I haven't reviewed every line of logic in detail but the changes
look correct at a high level. The only exception is that the empty
is supposed to be accepted and treated as zero even in
"--stdin -z" mode. See my response to that individual change.
On 03/10
Jeff King writes:
> On Mon, Mar 10, 2014 at 07:30:45AM -0700, Shawn Pearce wrote:
>
>> > * Store references in a SQLite database, to get correct transaction
>> > handling.
>>
>> No to SQLLite in git-core. Using it from JGit requires building
>> SQLLite and a JNI wrapper, which makes JGit signi
On Mon, Mar 10, 2014 at 10:46:01AM -0700, Junio C Hamano wrote:
> >> No to SQLLite in git-core. Using it from JGit requires building
> >> SQLLite and a JNI wrapper, which makes JGit significantly less
> >> portable. I know SQLLite is pretty amazing, but implementing
> >> compatibility with it from
On Mon, 10 Mar 2014, Ondřej Bílka wrote:
On Mon, Mar 10, 2014 at 03:13:45AM -0700, David Lang wrote:
On Mon, 10 Mar 2014, Dennis Luehring wrote:
according to these blog posts
http://www.infoq.com/news/2014/01/facebook-scaling-hg
https://code.facebook.com/posts/218678814984400/scaling-mercuri
On Mon, Mar 10, 2014 at 03:13:45AM -0700, David Lang wrote:
> On Mon, 10 Mar 2014, Dennis Luehring wrote:
>
> >according to these blog posts
> >
> >http://www.infoq.com/news/2014/01/facebook-scaling-hg
> >https://code.facebook.com/posts/218678814984400/scaling-mercurial-at-facebook/
> >
> >mercuri
Don't set GIT_EDITOR to ":" when calling prepare-commit-msg hook if the
editor is going to be called (e.g. with "merge -e").
Signed-off-by: Benoit Pierre
---
builtin/merge.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 67f312d..b11a5
---
run-command.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/run-command.h b/run-command.h
index 88460f9..3653bfa 100644
--- a/run-command.h
+++ b/run-command.h
@@ -51,6 +51,7 @@ extern int run_hook_le(const char *const *env, const char
*name, ...);
extern int run_hook_ve(const char *co
Signed-off-by: Benoit Pierre
---
t/t7505-prepare-commit-msg-hook.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t7505-prepare-commit-msg-hook.sh
b/t/t7505-prepare-commit-msg-hook.sh
index 1c95652..5531abb 100755
--- a/t/t7505-prepare-commit-msg-hook.sh
+++ b/t/t7505
This patch fixes the fact that hunk editing with 'commit -p -m' does not work:
GIT_EDITOR is set to ':' to indicate to hooks that no editor will be launched,
which result in the 'hunk edit' option not launching the editor (and selecting
the whole hunk).
The fix consists in deferring the GIT_EDITOR
- update 'no editor' hook test and add 'editor' hook test
- make sure the tree is reset to a clean state after running a test
(using test_when_finished) so later tests are not impacted
Signed-off-by: Benoit Pierre
---
t/t7505-prepare-commit-msg-hook.sh | 27 +--
1 file
Add (failing) test: with commit changing the environment to let hooks
now that no editor will be used (by setting GIT_EDITOR to ":"), the
"edit hunk" functionality does not work (no editor is launched and the
whole hunk is committed).
Signed-off-by: Benoit Pierre
---
t/t7513-commit_-p_-m_hunk_ed
Don't change git environment: move the GIT_EDITOR=":" override to the
hook command subprocess, like it's already done for GIT_INDEX_FILE.
Signed-off-by: Benoit Pierre
---
builtin/checkout.c| 8 +++
builtin/clone.c | 4 ++--
builtin/commit.c
Signed-off-by: Benoit Pierre
---
t/t7505-prepare-commit-msg-hook.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t7505-prepare-commit-msg-hook.sh
b/t/t7505-prepare-commit-msg-hook.sh
index 3573751..1c95652 100755
--- a/t/t7505-prepare-commit-msg-hook.sh
+++ b/t/t7505-pre
Le lundi 10 mars 2014 à 08:31 -0700, Junio C Hamano a écrit :
> Andrew Keller writes:
>
> > On Mar 7, 2014, at 7:50 PM, Henri GEIST wrote:
> > ...
> >> To give one of my project to someone else I have copied it on a USB key.
> >> By a simple drag and drop with the mouse.
> >> And I am quite sure
Signed-off-by: TamerTas
---
branch.c | 31 ---
1 file changed, 8 insertions(+), 23 deletions(-)
diff --git a/branch.c b/branch.c
index 723a36b..397edd3 100644
--- a/branch.c
+++ b/branch.c
@@ -50,6 +50,9 @@ static int should_setup_rebase(const char *origin)
void i
I inspected branch.c:install_branch_config() and since
the conditionals cover all the possibilities, I decided
that making the code table-driven would be much cleaner
and shorter. I've ran the tests and they all passed.
Reimplementation using "git am" also didn't have any problems.
Please let me k
Useful for calling status_printf only to change/reset the color (and
output an additional '\n' with status_vprintf_ln).
Signed-off-by: Benoit Pierre
---
wt-status.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index 4e55810..17f63a4 100644
--- a
Those happens with "gcc -Wformat-zero-length". Since passing NULL does not
generate a warning (as __attribute__((printf())) does not imply nonull), modify
status_printf/status_printf_ln to allow a NULL format and update calls with an
empty string.
Benoit Pierre (2):
status: allow NULL fmt for st
Those happens with "gcc -Wformat-zero-length".
Change empty strings to NULL now that it's allowed.
Signed-off-by: Benoit Pierre
---
builtin/commit.c | 2 +-
wt-status.c | 20 ++--
2 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/builtin/commit.c b/builtin/c
Henri GEIST writes:
> Le lundi 10 mars 2014 à 08:31 -0700, Junio C Hamano a écrit :
> ...
>> This is not limited to submodules. There are multiple lower-level
>> mechanisms for a $path/.git to borrow the repository data from
>> elsewhere outside of $path and a cloned submodule uses only one of
>
On Mon, Mar 10, 2014 at 05:14:02PM +0100, David Kastrup wrote:
> [storing refs in sqlite]
>
> Of course, the basic premise for this feature is "let's assume that our
> file and/or operating system suck at providing file system functionality
> at file name granularity". There have been two histori
Nguyễn Thái Ngọc Duy writes:
> After squashing or fixing up, you may want to have a final look at the
> commit, edit some more if needed or even do some testing. --postedit
> enables that. This is (to me) a paranoid mode so either I enable it
> for all squashes and fixups, or none. Hence a new o
On Mon, Mar 10, 2014 at 08:27:25PM +0100, Benoit Pierre wrote:
> Those happens with "gcc -Wformat-zero-length". Since passing NULL does not
> generate a warning (as __attribute__((printf())) does not imply nonull),
> modify
> status_printf/status_printf_ln to allow a NULL format and update calls
Ilya Bobyr writes:
> On 3/4/2014 11:22 AM, Junio C Hamano wrote:
>> Ilya Bobyr writes:
>>> @@ -333,6 +339,7 @@ h,helpshow the help
>>> foo some nifty option --foo
>>> bar= some cool option --bar with an argument
>>> +baz=arg another cool option --baz with an argument named
Jeff King writes:
> On Mon, Mar 10, 2014 at 05:14:02PM +0100, David Kastrup wrote:
>
>> [storing refs in sqlite]
>>
>> Of course, the basic premise for this feature is "let's assume that our
>> file and/or operating system suck at providing file system functionality
>> at file name granularity".
Johannes Sixt writes:
> Am 3/5/2014 1:10, schrieb Junio C Hamano:
>> * nd/gitignore-trailing-whitespace (2014-02-10) 2 commits
>> - dir: ignore trailing spaces in exclude patterns
>> - dir: warn about trailing spaces in exclude patterns
>>
>> Warn and then ignore trailing whitespaces in .giti
On Mon, Mar 10, 2014 at 01:22:15PM -0400, Jeff King wrote:
> +test_expect_success 'git clean -d respects pathspecs' '
> + mkdir foo &&
> + mkdir foobar &&
> + git clean -df foobar &&
> + test_path_is_dir foo &&
> + test_path_is_missing foobar
> +'
> +
> test_done
I think we sh
On Mon, Mar 10, 2014 at 07:49:34PM +0100, Benoit Pierre wrote:
> Don't change git environment: move the GIT_EDITOR=":" override to the
> hook command subprocess, like it's already done for GIT_INDEX_FILE.
>
> Signed-off-by: Benoit Pierre
> ---
> builtin/checkout.c| 8 +++
>
1 - 100 of 137 matches
Mail list logo