Am 4/14/2014 15:54, schrieb Michael Haggerty:
> The function remove_lock_file_on_signal() is used as a signal handler.
> It is not realistic to make the signal handler conform strictly to the
> C standard, which is very restrictive about what a signal handler is
> allowed to do. But let's increase
Am 4/14/2014 15:54, schrieb Michael Haggerty:
> diff --git a/lockfile.c b/lockfile.c
> index 664b0c3..1453a7a 100644
> --- a/lockfile.c
> +++ b/lockfile.c
> @@ -292,6 +292,9 @@ int commit_lock_file(struct lock_file *lk)
> if (lk->fd >= 0 && close_lock_file(lk))
> return -1;
>
On 04/14/2014 08:29 PM, Ronnie Sahlberg wrote:
> refs.c:ref_transaction_commit() intermingles doing updates and checks with
> actually applying changes to the refs in loops that abort on error.
> This is done one ref at a time and means that if an error is detected that
> will fail the operation pa
On Sat, Apr 12, 2014 at 10:05:15AM -0500, Felipe Contreras wrote:
> As you can see; some branches are published, others are not. The ones that are
> not published don't have a @{publish}, and `git branch -v` doesn't show them.
> Why is that hard to understand?
Do you ever push the unpublished bra
On 04/14/2014 11:25 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> I forgot to confirm that the callers *do* verify that they don't pass
>> incorrect values to ref_transaction_create() and
>> ref_transaction_delete(). But if they wouldn't, then die("BUG:") would
>> not be appropriate
"Kyle J. McKay" writes:
> For convenience, here are the diffs using -w:
>
> |--- a/git-rebase--am.sh
> |+++ b/git-rebase--am.sh
> |@@ -4,6 +4,7 @@
> # Copyright (c) 2010 Junio C Hamano.
> #
>
> +git_rebase__am() {
> case "$action" in
> continue)
> git am --resolved -
Matthieu Moy writes:
> "Kyle J. McKay" writes:
>
>> So I suggest that in the interest of fixing rebase on FreeBSD in an
>> expeditious fashion, patches 1/3 and 2/3 get picked up (see note
>> below) now and that the follow-on patch below, after being enhanced to
>> pass all tests, be submit
On Sat, Apr 12, 2014 at 09:12:57AM -0400, Jason Pyeron wrote:
> Is it me or is the only way to clear a single invalid password out of the
> credential-cache is by "git credential-cache exit"?
Try the "reject" action:
$ : remember a credential
$ url() { echo url=https://example.com; }
$ (ur
Christian Couder writes:
>> However, I am wondering if the current "everything on the command
>> line is instruction to the command" is too limiting to allow the use
>> of the tool both as a filter and as a tool that can work on one or
>> more files named on the command line. If we start from th
Felipe Contreras writes:
> When a remote helper crashes while pushing we should revert back to the
> state before the push, however, it's possible that `git fast-export`
> already finished its job, and therefore has exported the marks already.
>
> This creates a synchronization problem because fr
Michael Haggerty writes:
> I forgot to confirm that the callers *do* verify that they don't pass
> incorrect values to ref_transaction_create() and
> ref_transaction_delete(). But if they wouldn't, then die("BUG:") would
> not be appropriate either, would it? It would have to be die("you silly
Ronald Weiss writes:
> On 14. 4. 2014 20:30, Junio C Hamano wrote:
>> Ronald Weiss writes:
>>
>>> On 8. 4. 2014 20:43, Jens Lehmann wrote:
> Useful values for commit are 'all' (default) or 'none'. The others
> ('dirty' and 'untracked') have same effect as 'none', as commit is only
Felipe Contreras writes:
> It's simpler to store the file names directly, and form the fast-export
> arguments only when needed, and re-use the same strbuf with a format.
>
> Signed-off-by: Felipe Contreras
> ---
> transport-helper.c | 23 +++
> 1 file changed, 11 insertions
Felipe Contreras writes:
> These patches add support for remote helpers --force, --dry-run, and reporting
> forced update.
>
> Changes since v8:
>
> --- a/transport-helper.c
> +++ b/transport-helper.c
> @@ -734,7 +734,7 @@ static int push_update_ref_status(struct strbuf *buf,
> }
>
>
Felipe Contreras writes:
> zsh seems to have a bug while redirecting the stderr of the 'read'
> command:
>
> % read foo 2> /dev/null < foo
> zsh: no such file or directory: foo
>
> Which causes errors to be displayed when certain files are missing.
> Let's add a convenience function to manually
Thanks; will queue.
--
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
Dave Borowitz writes:
> curl-config should always be installed alongside a curl distribution,
> and its purpose is to provide flags for building against libcurl, so
> use it instead of guessing flags and dependent libraries.
>
> Allow overriding CURL_CONFIG to a custom path to curl-config, to
> c
Gábor Szeder writes:
> words[] is just fine, we never modify it after it is filled by
> _get_comp_words_by_ref() at the very beginning.
Hmph. I would have understood if the latter were "we never look at
it (to decide what to do)". "we never modify it" does not sound
like an enough justificatio
On 14. 4. 2014 20:30, Junio C Hamano wrote:
> Ronald Weiss writes:
>
>> On 8. 4. 2014 20:43, Jens Lehmann wrote:
Useful values for commit are 'all' (default) or 'none'. The others
('dirty' and 'untracked') have same effect as 'none', as commit is only
interested in whether the sub
Brian Gesiak writes:
> The output from a successful invocation of the shorthand command
> "git rebase -" is something like "Fast-forwarded HEAD to @{-1}",
> which includes a relative reference to a revision. Other commands
> that use the shorthand "-", such as "git checkout -", typically
> displa
Change the function write_ref_sha1() to just write the ref but not
commit the ref or the lockfile.
Add a new function commit_ref_lock() that will commit the change done by
a previous write_ref_sha1().
Update all callers of write_ref_sha1() to call commit_ref_lock().
The new pattern for updating a
Duy Nguyen writes:
> On Sat, Apr 12, 2014 at 11:19 AM, Junio C Hamano wrote:
>
>> In the spectrum between useful and insane, there is a point where we
>> should just tell the insane: don't do it then.
>
> ... A process' dying is a
> way of telling people "this is insane" without having to draw a
refs.c:ref_transaction_commit() intermingles doing updates and checks with
actually applying changes to the refs in loops that abort on error.
This is done one ref at a time and means that if an error is detected that
will fail the operation partway through the list of refs to update we
will end up
During a transaction commit we will both update and delete refs.
Since both update and delete now use the same pattern
lock = lock_ref_sha1_basic() (or varient of)
write_ref_sha1(lock)/delete_ref_loose(lock)
unlock_ref(lock) | commit_ref_lock(lock)
we can now simplify ref_transaction_
Ronald Weiss writes:
> On 8. 4. 2014 20:43, Jens Lehmann wrote:
>>> Useful values for commit are 'all' (default) or 'none'. The others
>>> ('dirty' and 'untracked') have same effect as 'none', as commit is only
>>> interested in whether the submodule's HEAD differs from what is commited
>>> in t
Change delete_ref_loose()) to just flag that a ref is to be deleted but do
not actually unlink the files.
Change commit_ref_lock() so that it will unlink refs that are flagged for
deletion.
Change all callers of delete_ref_loose() to explicitely call commit_ref_lock()
to commit the deletion.
The n
On Mon, Apr 14, 2014 at 5:14 PM, Johannes Schindelin
wrote:
> Dear friends of Git for Windows,
>
> it was very delightful to be on the show, hosted by Thomas Ferris
> Nicolaisen:
>
> http://episodes.gitminutes.com/2014/04/gitminutes-28-johannes-schindelin-on.html
Really enjoyable, thanks!
--
To u
On Wed, 09 Apr 2014 20:50:57 +, Mahmoud Asshole wrote:
...
> This was raised previously[1], but none of the responses are convincing.
Please go directly to the special hell of debugging timezone-related stuff
in customer data, for which this extra bit of information is heaven-sent.
Do not coll
Dear friends of Git for Windows,
it was very delightful to be on the show, hosted by Thomas Ferris
Nicolaisen:
http://episodes.gitminutes.com/2014/04/gitminutes-28-johannes-schindelin-on.html
Enjoy,
Johannes
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
Hi Michael, Ævar,
Thank you very much for your answers.
Each of 'git show-ref’ and ‘git for-each-ref’ is 2 times faster than ‘git log
--branches --tags --remotes’ on “warmed up" FS caches, but take the same time
on “cold” FS.
It seems that all these approaches internally walk down from all re
If the call to adjust_shared_perm() fails, lock_file returns -1, which
to the caller looks like any other failure to lock the file. So in
this case, roll back the lockfile before returning so that the lock
file is deleted immediately and the lockfile object is left in a
predictable state (namely,
Document a couple more functions and the flags argument as used by
hold_lock_file_for_update() and hold_lock_file_for_append().
Signed-off-by: Michael Haggerty
---
Documentation/technical/api-lockfile.txt | 36 +---
1 file changed, 33 insertions(+), 3 deletions(-)
di
It is only necessary to clear the lock_file's filename field if it was
not already clear.
Signed-off-by: Michael Haggerty
---
lockfile.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/lockfile.c b/lockfile.c
index d4bfb3f..7701267 100644
--- a/lockfile.c
+++ b/lockfile.c
@@
Declare the return value to be const to make it clear that we aren't
giving callers permission to write over the string that it points at.
(The return value is the filename field of a struct lock_file, which
can be used by a signal handler at any time and therefore shouldn't be
tampered with.)
Sig
Document the valid states of lock_file objects, how they get into each
state, and how the state is encoded in the object's fields.
Signed-off-by: Michael Haggerty
---
lockfile.c | 51 +++
1 file changed, 51 insertions(+)
diff --git a/lockfile.c b/
Avoid relying on the filename length restrictions that are currently
checked by lock_file().
Signed-off-by: Michael Haggerty
---
lockfile.c | 12 +++-
1 file changed, 7 insertions(+), 5 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index fce53f1..0aa2998 100644
--- a/lockfile.c
+++
Even the one lockfile object needn't be allocated each time the
function is called. Instead, define one statically-allocated
lock_file object and reuse it for every call.
Suggested-by: Jeff King
Signed-off-by: Michael Haggerty
---
builtin/merge.c | 14 +++---
1 file changed, 7 insertio
This is a bit easier to read than the old version, which nested part
of the non-error code in an "if" block.
Signed-off-by: Michael Haggerty
---
lockfile.c | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 1ce0e87..ba791d5 100644
Change resolve_symlink() to take a strbuf rather than a string as
parameter. This simplifies the code and removes an arbitrary pathname
length restriction. It also means that lock_file's filename field no
longer needs to be initialized to a large size.
Signed-off-by: Michael Haggerty
---
lockf
It does just what we need.
Signed-off-by: Michael Haggerty
---
lockfile.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index ba791d5..477bf4b 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -63,12 +63,8 @@ static void remove_lock_file(void)
The function remove_lock_file_on_signal() is used as a signal handler.
It is not realistic to make the signal handler conform strictly to the
C standard, which is very restrictive about what a signal handler is
allowed to do. But let's increase the likelihood that it will work:
The lock_file_list
It used to be that if locking failed, lock_file() usually did not
register the lock_file object in lock_file_list but sometimes it did.
This confusion was compounded if lock_file() was called via
hold_lock_file_for_append(), which has its own failure modes.
The ambiguity didn't have any ill effect
It's bad manners. Especially since, if unlink_or_warn() failed, the
memory wasn't restored to its original contents.
So make our own copy to work with.
Signed-off-by: Michael Haggerty
---
refs.c | 15 +--
1 file changed, 9 insertions(+), 6 deletions(-)
diff --git a/refs.c b/refs.c
Rewrite last_path_elm() to take a strbuf parameter and to trim off the
last path name element in place rather than returning a pointer to the
beginning of the last path name element. This simplifies the function
a bit and makes it integrate better with its caller, which is also
strbuf-based. Rena
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 lock_file_list),
that means we have to be careful
Signed-off-by: Michael Haggerty
---
lockfile.c | 8 +---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/lockfile.c b/lockfile.c
index 477bf4b..664b0c3 100644
--- a/lockfile.c
+++ b/lockfile.c
@@ -288,12 +288,14 @@ int close_lock_file(struct lock_file *lk)
int commit_lock_file(
When rolling back the lockfile, call close_lock_file() so that the
lock_file's fd field gets set back to -1. This keeps the lock_file
object in a valid state, which is important because these objects are
allowed to be reused.
Signed-off-by: Michael Haggerty
---
lockfile.c | 2 +-
1 file changed
This makes it obvious that we have no plans to change the integer
pointed to, which is actually the fd field from a struct lock_file.
Signed-off-by: Michael Haggerty
---
refs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/refs.c b/refs.c
index 20c483b..cb2f825 100644
--- a
If there is an error copying the old contents to the lockfile, roll
back the lockfile before exiting so that the lockfile is not held
until process cleanup.
Signed-off-by: Michael Haggerty
---
lockfile.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/lockfile.c b/lockfil
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 overlook. So before continuing, do a consistency
check that the lock_fi
There are a few places that use these values, so define constants for
them.
Signed-off-by: Michael Haggerty
---
If I were confident that it would always be inlined, I would have
used
#define LOCK_SUFFIX_LEN strlen(LOCK_SUFFIX)
Or maybe even have omitted this constant and write strlen(LOCK_S
By the time the "if" block is entered, the lock_file instance from the
main function block is no longer in use, so re-use that one instead of
allocating a second one.
Note that the "lock" variable in the "if" block shadowed the "lock"
variable at function scope, so the only change needed is to rem
For now, we still make sure to allocate at least PATH_MAX characters
for the strbuf because resolve_symlink() doesn't know how to expand
the space for its return value. (That will be fixed in a moment.)
Another alternative would be to just use a strbuf as scratch space in
lock_file() but then sto
Aside from shortening and simplifying the code, this removes another
place where the path name length is arbitrarily limited.
Signed-off-by: Michael Haggerty
---
lockfile.c | 33 -
1 file changed, 12 insertions(+), 21 deletions(-)
diff --git a/lockfile.c b/lockfi
This function is used for other things besides the index, so rename it
accordingly.
Suggested-by: Jeff King
Signed-off-by: Michael Haggerty
---
builtin/update-index.c | 2 +-
cache.h| 2 +-
lockfile.c | 6 +++---
refs.c | 2 +-
4 files changed, 6 inse
Round v3. Thanks to Johannes Sixt and Peff for feedback on v2. This
version addresses all issues raised for v1 [1] and v2 [2].
Changes since v2:
* Instead of keeping track of whether a lock_file object is active via
a new bit in a flags bitmask, store it in a separate volatile
sig_atomic_t
On Fri, Apr 11, 2014 at 9:25 PM, Junio C Hamano wrote:
> The motion is about this:
>
> Outside people, like the party who approached us about putting
> our logo on their trinket, seem to associate that logo we see on
> git-scm.com today with our project, but we never officially said
>
On 04/07/2014 09:13 PM, Junio C Hamano wrote:
> Michael Haggerty writes:
>
>> +void ref_transaction_create(struct ref_transaction *transaction,
>> +const char *refname,
>> +unsigned char *new_sha1,
>> +int flags)
>> +{
>> +
So this is really bikeshedding at its finest.
I'd personally do agree on the logo proposed in the first mail by Junio.
However who is the core community, who am I to judge?
So maybe the decision process on this issue may need a more centrally
steered opinion,
so why not call for votes and weight
"Kyle J. McKay" writes:
> So I suggest that in the interest of fixing rebase on FreeBSD in an
> expeditious fashion, patches 1/3 and 2/3 get picked up (see note
> below) now and that the follow-on patch below, after being enhanced to
> pass all tests, be submitted separately at some future
On 04/07/2014 09:31 PM, Jeff King wrote:
> 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
61 matches
Mail list logo
