diff options
| author | Junio C Hamano <gitster@pobox.com> | 2016-06-06 13:11:02 -0700 |
|---|---|---|
| committer | Junio C Hamano <gitster@pobox.com> | 2016-06-06 13:11:02 -0700 |
| commit | a7d4c49a8201f75699bf59852ef8e345f41a12b6 (patch) | |
| tree | 6d4762540c46b687a0a9f4801548fc2abaac03c4 | |
| parent | a1bc3dd46433c6e7e6f1ca5f3bd5429858a60078 (diff) | |
| download | git-cc/apply-introduce-state.tar.gz | |
builtin/apply: remove misleading comment on lock_file fieldcc/apply-introduce-state
Just like pointer field like prefix, the piece of memory pointed at
by lock_file field is not owned by the apply_state structure. It is
true that the caller needs to be careful about the lifetime rule for
lockfile instances, but that is none of this API's business.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
| -rw-r--r-- | builtin/apply.c | 5 |
1 files changed, 1 insertions, 4 deletions
diff --git a/builtin/apply.c b/builtin/apply.c index 7338ee6b68..b3eb704725 100644 --- a/builtin/apply.c +++ b/builtin/apply.c @@ -52,10 +52,7 @@ struct apply_state { const char *prefix; int prefix_length; - /* - * Since lockfile.c keeps a linked list of all created - * lock_file structures, it isn't safe to free(lock_file). - */ + /* These are lock_file related */ struct lock_file *lock_file; int newfd; |