Am 4/7/2014 1:34, schrieb Michael Haggerty:
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects are often reused (but are never removed from
On Sun, Apr 06, 2014 at 11:54:59PM +0200, Michael Haggerty wrote:
I didn't reproduce it experimentally, though. We should be able to just
lk-owner = 0;
before the initial strcpy to fix it, I would think.
I think that using the owner field to avoid this problem is a bit
On Sat, Apr 5, 2014 at 12:42 AM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Christian Couder christian.cou...@gmail.com writes:
The following features are planned but not yet implemented:
- add more tests related to commands
- add
On 04/07/2014 08:16 AM, Johannes Sixt wrote:
Am 4/7/2014 1:34, schrieb Michael Haggerty:
Because remove_lock_file() can be called any time by the signal
handler, it is important that any lock_file objects that are in the
lock_file_list are always in a valid state. And since lock_file
objects
Am 4/7/2014 13:13, schrieb Michael Haggerty:
On 04/07/2014 08:16 AM, Johannes Sixt wrote:
Am 4/7/2014 1:34, schrieb Michael Haggerty:
So, instead of encoding part of the lock_file state in the filename
field, add a new bit LOCK_FLAGS_LOCKFILE_ACTIVE to flags, and use
this bit to distinguish
On 04/07/2014 02:12 PM, Johannes Sixt wrote:
Am 4/7/2014 13:13, schrieb Michael Haggerty:
On 04/07/2014 08:16 AM, Johannes Sixt wrote:
Am 4/7/2014 1:34, schrieb Michael Haggerty:
So, instead of encoding part of the lock_file state in the filename
field, add a new bit
'git p4 rebase' fails with the following message if there is a file
named HEAD in the current directory:
fatal: ambiguous argument 'HEAD': both revision and filename
Use '--' to separate paths from revisions, like this:
'git command [revision...] -- [file...]'
Take the
Read the whole input into a strbuf at once, and then parse it from
there. This might also be a tad faster, but that is not the point.
The point is to decouple the parsing code from the input source (the
old parsing code had to read new data even in the middle of commands).
Add docstrings for the
The old parse_arg(), when fed an argument
refs/heads/amaster
parsed 'refs/heads/a' off of the front of the argument and considered
itself successful. It was only when parse_next_arg() tried to parse
the *next* argument that a problem was noticed. But in fact, the
definition of the input
Here is v3. It is also available on GitHub [1].
Thanks to Junio and Brad for their comments about v2. I think I have
addressed all of your comments (except for Junio's regrets that the
series didn't include a transactional receive-pack).
See the mailing list threads about v1 [2] and v2 [3] and
The old signature of update_refs() required a
(const struct ref_update **) for its updates_orig argument. The
const is presumably there to promise that the function will not
modify the contents of the structures.
But this declaration does not permit the function to be called with a
(struct
Aside from avoiding a tiny bit of work, this makes it transparently
obvious that old_sha1 and new_sha1 are identical. It is arguably a
bit silly to have to set new_sha1 in order to verify old_sha1, but
that is a problem for another day.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
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 mhag...@alum.mit.edu
---
builtin/update-ref.c | 90
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 mhag...@alum.mit.edu
---
builtin/checkout.c | 2 +-
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 newvalue
Of course, this makes
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 newvalue is empty, which is a bit off the
beaten track.
So, to be sure that we are testing what we want to
Previously there were no good tests of C-quoted arguments.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
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
In the original version of this command, for the single case of the
update command's newvalue, the empty string was interpreted as
being equivalent to 40 0s. This shorthand is unnecessary (binary
input will usually be generated programmatically anyway), and it
complicates the parser and the
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 mhag...@alum.mit.edu
---
refs.c | 36 +++-
1
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 15 ++-
1 file changed, 6 insertions(+), 9 deletions(-)
diff --git a/refs.c b/refs.c
index b6778aa..2ff195f 100644
--- a/refs.c
+++ b/refs.c
@@ -3274,11 +3274,11 @@ static int update_ref_write(const char *action, const
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 are left with their old form, because
$COMMAND and $REFNAME aren't passed all the way down the call
stack. Maybe
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
beginning a transaction, adding updates to a transaction, and
committing/rolling back a
This is the (slightly inconsistent) status quo; make sure it doesn't
change by accident.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
t/t1400-update-ref.sh | 7 +++
1 file changed, 7 insertions(+)
diff --git a/t/t1400-update-ref.sh b/t/t1400-update-ref.sh
index a2015d0..208f56e
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 mhag...@alum.mit.edu
---
refs.c | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/refs.c b/refs.c
index
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
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 ref_transaction_*() to
queue the change rather than building up the list of changes at the
caller side.
This is consistent with the usual nomenclature.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 18 +-
refs.h | 2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/refs.c b/refs.c
index 6984ff0..b6778aa 100644
--- a/refs.c
+++ b/refs.c
@@
It has been superseded by reference transactions. This also means
that struct ref_update can become private.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 33 -
refs.h | 20
2 files changed, 20 insertions(+), 33
This case wants to test passing a bad refname to the update command.
But it also passes too few arguments to update, which muddles the
situation: which error should be diagnosed? So split this test into
two:
* One that passes too few arguments to update
* One that passes all three arguments to
Distinguish this error from the error that an argument is missing for
another reason. Update the tests accordingly.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/update-ref.c | 4 ++--
t/t1400-update-ref.sh | 12 ++--
2 files changed, 8 insertions(+), 8 deletions(-)
Instead of, for example,
fatal: update refs/heads/master missing [oldvalue] NUL
emit
fatal: update refs/heads/master missing oldvalue
Update the tests accordingly.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/update-ref.c | 6 +++---
t/t1400-update-ref.sh | 6
If an invalid value is passed to update-ref --stdin as oldvalue or
newvalue, 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 mhag...@alum.mit.edu
---
builtin/update-ref.c | 24
It used to be that ref_transaction_commit() allocated a temporary
array to hold the types of references while it is working. Instead,
add a type field to ref_update that ref_transaction_commit() can use
as its scratch space.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
refs.c | 8
The old error messages emitted for invalid input sometimes said
oldvalue/newvalue and sometimes said old value/new value.
Convert them all to the former. Update the tests accordingly.
Signed-off-by: Michael Haggerty mhag...@alum.mit.edu
---
builtin/update-ref.c | 8
This commit contains the squashed changes from the upstream
git-multimail repository since the last code drop. Highlights:
* Fix encoding of non-ASCII email addresses in email headers.
* Fix backwards-compatibility bugs for older Python 2.x versions.
* Fix a backwards-compatibility bug for Git
Michael Haggerty mhag...@alum.mit.edu writes:
The first use of a lock_file object necessarily passes through
lock_file(). The only precondition for that function is that the
on_list field is zero, which is satisfied by a xcalloc()ed object.
Subsequent uses of a lock_file object must *not*
Johannes Sixt j...@kdbg.org writes:
Am 04.04.2014 22:58, schrieb Junio C Hamano:
* sz/mingw-index-pack-threaded (2014-03-19) 1 commit
- Enable index-pack threading in msysgit.
What is the status of this topic? A failure report exists
($gmane/245170), and I am aware of Duy's
Christian Couder christian.cou...@gmail.com writes:
On Sat, Apr 5, 2014 at 12:42 AM, Junio C Hamano gits...@pobox.com wrote:
Junio C Hamano gits...@pobox.com writes:
Christian Couder christian.cou...@gmail.com writes:
The following features are planned but not yet implemented:
- add
Duy Nguyen pclo...@gmail.com writes:
Or even better to show an error message when the error code is
unexpected? The unkown tag '!' says there are problems but if it
shows up sort of permanently, '!' won't help much, I think.
I am OK with that approach, but then one question remains: should
Jeff King p...@peff.net writes:
On Fri, Apr 04, 2014 at 03:28:48PM -0700, Junio C Hamano wrote:
...
OK, together with the fact that only ancient versions of fetcher
would trigger this do not reuse codepath, I agree that we should
go the simplest route this patch takes.
By the way, we may
Kirill Smelkov k...@navytux.spb.ru writes:
The following
...
maybe looks a bit simpler, but calls tree_entry_pathcmp twice more times.
Besides for important nparent=1 case we were not calling
tree_entry_pathcmp at all and here we'll call it once, which would slow
execution down a bit, as
Kirill Smelkov k...@navytux.spb.ru writes:
+ if (!DIFF_OPT_TST(opt, FIND_COPIES_HARDER)) {
+ for (i = 0; i nparent; ++i)
+ if (tp[i].entry.mode S_IFXMIN_NEQ)
+ goto
Lewis Diamond g...@lewisdiamond.com writes:
'git fetch foo develop' would result in:
fatal: Couldn't find remote ref test2 //Not OK, (case 1)
I have no idea where the test2 comes from, as it does not appear
anywhere in the above write-up, and it could be a bug.
'git fetch foo master' would
Am 05.04.2014 11:19, schrieb Johannes Sixt:
Am 04.04.2014 22:58, schrieb Junio C Hamano:
* sz/mingw-index-pack-threaded (2014-03-19) 1 commit
- Enable index-pack threading in msysgit.
What is the status of this topic? A failure report exists
($gmane/245170), and I am aware of Duy's
This patch series implements a new command:
git interpret-trailers
and an infrastructure to process trailers that can be reused,
for example in commit.c.
1) Rationale:
This command should help with RFC 822 style headers, called
trailers, that are found at the end of commit messages.
This patch adds the process_trailers() function that
calls all the previously added processing functions
and then prints the results on the standard output.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
trailer.c | 49
Let the user specify a command that will give on its standard output
the value to use for the specified trailer.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
trailer.c | 64
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
t/t7513-interpret-trailers.sh | 12 +++-
trailer.c | 26 ++
2 files changed, 29 insertions(+), 9 deletions(-)
diff --git a/t/t7513-interpret-trailers.sh b/t/t7513-interpret-trailers.sh
Read trailers from stdin, parse them and put the result into a doubly linked
list.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
trailer.c | 76 +++
1 file changed, 76
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t7513-interpret-trailers.sh | 351 ++
1 file changed, 351 insertions(+)
create mode 100755 t/t7513-interpret-trailers.sh
diff --git
Parse the trailer command line arguments and put
the result into an arg_tok doubly linked list.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
trailer.c | 117 ++
1 file
And add a few other tests for some special cases.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Junio C Hamano gits...@pobox.com
---
t/t7513-interpret-trailers.sh | 116 ++
1 file changed, 116 insertions(+)
diff --git
We will use a doubly linked list to store all information
about trailers and their configuration.
This way we can easily remove or add trailers to or from
trailer lists while traversing the lists in either direction.
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
Signed-off-by: Junio C
Implement the logic to process trailers from stdin and arguments.
At the beginning trailers from stdin are in their own in_tok
doubly linked list, and trailers from arguments are in their own
arg_tok doubly linked list.
The lists are traversed and when an arg_tok should be applied,
it is removed
On Mon, Apr 7, 2014 at 2:23 PM, Junio C Hamano gits...@pobox.com wrote:
Lewis Diamond g...@lewisdiamond.com writes:
'git fetch foo develop' would result in:
fatal: Couldn't find remote ref test2 //Not OK, (case 1)
I have no idea where the test2 comes from, as it does not appear
anywhere in
On Mon, Apr 07, 2014 at 01:33:43AM +0200, Michael Haggerty wrote:
+unable_to_lock_error::
+
+ Emit an error describing that there was an error locking the
+ specified path. The err parameter should be the errno of the
+ problem that caused the failure.
+
+unable_to_lock_die::
On Mon, Apr 07, 2014 at 01:33:44AM +0200, Michael Haggerty wrote:
This function is used for other things besides the index, so rename it
accordingly.
Oh, and here it is. I should really have just read ahead before
responding to patch 1.
We can either re-order these first two, or just not
Michael Haggerty mhag...@alum.mit.edu writes:
...
Contributions-by: Raphaël Hertzog hert...@debian.org
Contributions-by: Eric Berberich eric.berber...@gmail.com
Contributions-by: Michiel Holtkamp g...@elfstone.nl
Contributions-by: Malte Swart msw...@devtation.de
Signed-off-by: Michael
From: Junio C Hamano gits...@pobox.com
Christian Couder christian.cou...@gmail.com writes:
First accepting both ':' and '=' means one can see the git
interpret-trailers as acting on trailers only. Not just on trailers
from the intput message and option parameters from the command line.
Am 06.04.2014 23:18, schrieb Michal Sojka:
On Sun, Apr 06 2014, Jens Lehmann wrote:
Am 02.04.2014 23:52, schrieb Michal Sojka:
Hello,
I needed to convert a subdirectory of a repo to a submodule and have the
histories of both repos linked together. I found that this was discussed
few years
Michael Haggerty mhag...@alum.mit.edu writes:
+void ref_transaction_create(struct ref_transaction *transaction,
+ const char *refname,
+ unsigned char *new_sha1,
+ int flags)
+{
+ struct ref_update *update =
On Mon, Apr 07, 2014 at 01:33:59AM +0200, Michael Haggerty wrote:
It was previously a bug to call commit_lock_file() with a lock_file
object that was not active (an illegal access would happen within the
function). It was presumably never done, but this would be an easy
programming error to
Christian Couder chrisc...@tuxfamily.org writes:
I do not see these two as valid arguments to make the command line
more complex to the end users
I don't think that it makes the command more complex to the end users.
---who now need to know that only this
command treats its command line in
On Mon, Apr 07, 2014 at 03:12:49PM +0200, Michael Haggerty wrote:
How far *do* you want to go? I'm certainly not opposed to field-test your
current changeset (plus and adjustment to use sig_atomic_t) -- overall it
is an improvement. And then we will see how it works.
For now I think I'd
Unicode 6.3 defines the following code as combining or accents,
git_wcwidth() should return 0.
Earlier unicode standards had defined these code point as reserved:
358 COMBINING DOT ABOVE RIGHT
359 COMBINING ASTERISK BELOW
35A COMBINING DOUBLE RING BELOW
35B COMBINING ZIGZAG ABOVE
35C COMBINING
Unicode 6.3 defines the following code as combining or accents,
git_wcwidth() should return 0.
Earlier unicode standards had defined these code point as reserved:
358 COMBINING DOT ABOVE RIGHT
359 COMBINING ASTERISK BELOW
35A COMBINING DOUBLE RING BELOW
35B COMBINING ZIGZAG ABOVE
35C COMBINING
Unicode 6.3 defines the following code as combining or accents,
git_wcwidth() should return 0.
Earlier unicode standards had defined these code point as reserved:
358 COMBINING DOT ABOVE RIGHT
359 COMBINING ASTERISK BELOW
35A COMBINING DOUBLE RING BELOW
35B COMBINING ZIGZAG ABOVE
35C COMBINING
Unicode 6.3 defines the following code as combining or accents,
git_wcwidth() should return 0.
Earlier unicode standards had defined these code point as reserved:
358 COMBINING DOT ABOVE RIGHT
359 COMBINING ASTERISK BELOW
35A COMBINING DOUBLE RING BELOW
35B COMBINING ZIGZAG ABOVE
35C COMBINING
On Mon, Apr 07, 2014 at 01:33:42AM +0200, Michael Haggerty wrote:
This is a second attempt at renovating the lock file code. Thanks to
Peff, Junio, Torsten, and Eric for their helpful reviews of v1.
v1 of this patch series [1] did some refactoring and then added a new
feature to the
On 07/04/14 19:35, Johannes Sixt wrote:
Am 05.04.2014 11:19, schrieb Johannes Sixt:
Am 04.04.2014 22:58, schrieb Junio C Hamano:
* sz/mingw-index-pack-threaded (2014-03-19) 1 commit
- Enable index-pack threading in msysgit.
What is the status of this topic? A failure report exists
Hi,
Torsten Bögershausen wrote:
Unicode 6.3 defines the following code as combining or accents,
git_wcwidth() should return 0.
Earlier unicode standards had defined these code point as reserved:
Thanks for the update. Could the commit message also explain how this
was noticed and what the
On Mon, Apr 07, 2014 at 10:29:46AM -0700, Junio C Hamano wrote:
Kirill Smelkov k...@navytux.spb.ru writes:
The following
...
maybe looks a bit simpler, but calls tree_entry_pathcmp twice more times.
Besides for important nparent=1 case we were not calling
tree_entry_pathcmp at all
I’ve started using notes recently, and I have notes.rewriteRef set so that
when I rebase, my notes will be kept. Unfortunately, it turns out that if a
rebase deletes my local commit because it already exists in upstream, it
doesn’t copy the note to the upstream commit. It seems perfectly
Kevin Ballard ke...@sb.org writes:
I’ve started using notes recently, and I have notes.rewriteRef set so that
when I rebase, my notes will be kept. Unfortunately, it turns out that if a
rebase deletes my local commit because it already exists in upstream, it
doesn’t copy the note to the
Christian Couder chrisc...@tuxfamily.org writes:
Signed-off-by: Christian Couder chrisc...@tuxfamily.org
---
Hmph, this is more fixing a mistake made earlier in the series at
the end than adding a new feature or something. Can you start from
a version that does not have the mistake from the
On 6. 4. 2014 18:28, Jens Lehmann wrote:
Am 02.04.2014 21:56, schrieb Ronald Weiss:
On 2. 4. 2014 20:53, Jens Lehmann wrote:
Am 01.04.2014 23:59, schrieb Ronald Weiss:
On 1. 4. 2014 22:23, Jens Lehmann wrote:
Am 01.04.2014 01:35, schrieb Ronald Weiss:
On 1. 4. 2014 0:50, Ronald Weiss wrote:
On Apr 7, 2014, at 2:33 PM, Junio C Hamano gits...@pobox.com wrote:
Kevin Ballard ke...@sb.org writes:
I’ve started using notes recently, and I have notes.rewriteRef set so that
when I rebase, my notes will be kept. Unfortunately, it turns out that if a
rebase deletes my local commit
Christian Couder chrisc...@tuxfamily.org writes:
From: Junio C Hamano gits...@pobox.com
A different way to sell a colon, e.g.
Consider the instruction sed takes on its command line.
(e.g. sed 's/frotz/nitfol/' xyzzy). In the most general
form, you would always give it as the
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'.
You can find the changes described here in the integration branches
of the repositories listed at
vdog...@ixiacom.com wrote on Mon, 07 Apr 2014 16:19 +0300:
'git p4 rebase' fails with the following message if there is a file
named HEAD in the current directory:
fatal: ambiguous argument 'HEAD': both revision and filename
Use '--' to separate paths from revisions, like this:
Pete Wyckoff p...@padd.com writes:
vdog...@ixiacom.com wrote on Mon, 07 Apr 2014 16:19 +0300:
'git p4 rebase' fails with the following message if there is a file
named HEAD in the current directory:
fatal: ambiguous argument 'HEAD': both revision and filename
Use '--' to separate
Allow overriding the ignore setting from config, using the command line
parameter like diff and status have. Git add currently doesn't honor
ignore from .gitmodules, but it does honor it from .git/config. And
support for .gitmodules will come in another patch.
Useful when values are 'none' and
Git commit honors the 'ignore' setting from .gitmodules or .git/config,
but didn't allow to override it from command line, like other commands do.
Useful when values for commit are 'all' (default) or 'none'. The others
('dirty' and 'untracked') have same effect as 'none', as commit is only
On Tue, Apr 8, 2014 at 1:35 AM, Johannes Sixt j...@kdbg.org wrote:
Am 05.04.2014 11:19, schrieb Johannes Sixt:
Am 04.04.2014 22:58, schrieb Junio C Hamano:
* sz/mingw-index-pack-threaded (2014-03-19) 1 commit
- Enable index-pack threading in msysgit.
What is the status of this topic? A
Hi all,
I withdraw this proposal because I realize that I won't be eligible to
work in July and August as an F-1 student.
Good luck to other applicants!
Guanglin
2014-03-20 23:37 GMT+08:00 Guanglin Xu mzguang...@gmail.com:
Hello,
My name is Guanglin Xu. I am a second-year master student at
85 matches
Mail list logo