TIAL
.git/NOTES_MERGE_WORKTREE
you would have (assuming NOTES_MERGE_REF == refs/notes/foo):
.git/NOTES_MERGE/refs/notes/foo/REF
.git/NOTES_MERGE/refs/notes/foo/PARTIAL
.git/NOTES_MERGE/refs/notes/foo/WORKTREE
and then a simultaneous notes-merge on a different notes ref
(refs/notes/bar) woul
On Wed, Jul 29, 2015 at 12:12 AM, Junio C Hamano wrote:
> David Turner writes:
>> Prevent merges to the same notes branch from different worktrees.
>> Before creating NOTES_MERGE_REF, check NOTES_MERGE_REF using the same
>> code we use to check that two HEADs in different worktrees don't point
>>
On Wed, Jul 29, 2015 at 12:52 AM, Junio C Hamano wrote:
> Johan Herland writes:
>> However, in any case, notes merges are always per _repo_ and never per
>> _worktree_, so this is all unrelated to the current patch/discussion
>> AFAICS.
>
> Thanks for chiming in, b
On Wed, Jul 29, 2015 at 2:56 AM, Michael Haggerty wrote:
> Johan Herland writes:
>> Here is where we start to differ. I would say that starting a notes
>> merge is completely unrelated to your worktree. Consider this:
>
> It sounds like what a notes merge really wants is
On Wed, Jul 29, 2015 at 2:33 AM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> Here is where we start to differ. I would say that starting a notes
>> merge is completely unrelated to your worktree. Consider this:
>> ...
>> This is not the case for notes merges.
linked worktree effort, so this language is new to me. My apologies).
...Johan
--
Johan Herland,
www.herland.net
--
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
lso trying to do: David's topic should not
have to deal with NOTES_MERGE_* at all. Simply leave it all as
something that belongs in $GIT_COMMON_DIR, and let's solve concurrent
unrelated notes merges as a wholly independent, separate topic.
...Johan
--
Johan Herland,
www.herland.net
--
On Wed, Jul 29, 2015 at 7:01 AM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> I believe it is a bad compromise. It complicates the code, and it
>> provides a concurrent notes merges that is unnecessarily tied to (and
>> dependent on) worktrees. For example,
On Wed, Jul 29, 2015 at 7:58 PM, David Turner wrote:
> + specially by git. Psuedorefs both have names that are all-caps,
s/Psuedo/Pseudo/
...Johan
--
Johan Herland,
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a mess
On Wed, Jul 29, 2015 at 6:37 PM, Junio C Hamano wrote:
> Johan Herland writes:
>> On Wed, Jul 29, 2015 at 7:01 AM, Junio C Hamano wrote:
>>> Johan Herland writes:
>>>
>>>> I believe it is a bad compromise. It complicates the code, and it
>>
d workflow is
to base your patch series on master or next, as those do not jump
around quite as much as pu does.
>
> Jacob Keller (2):
> notes: document cat_sort_uniq rewriteMode
> notes: add notes.merge option to select default strategy
Both patches Acked-by: Johan Her
in-progress
> for" err
> + ) &&
> + test_path_is_missing .git/worktrees/worktree/NOTES_MERGE_REF
> +'
> +
> +test_expect_success 'merge z into x while mid-merge on y succeeds' '
> + (
> + cd worktree2 &&
> +
r
Still looks good to me, AFAICS. Feel free to add my Reviewed-by.
...Johan
--
Johan Herland,
www.herland.net
--
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
s(git_notes_merge_usage, options);
> }
Do you need to look at the notes.merge config variable at all if
-s/--strategy is given?
I'd expect the above to rather look something like:
if (strategy) {
if (parse_notes_strategy(strategy, &o.strategy)) {
error(&
tegy instead? Or even better,
take inspiration from branch..mergeoptions, and provide
notes..mergeoptions instead, which you can then set like:
git config notes.foo.mergeoptions "--strategy=cat_sort_uniq"
Even though 'git notes merge' don't yet accept any other options that
should
On Tue, Aug 11, 2015 at 10:57 PM, Jacob Keller wrote:
> From: Jacob Keller
>
> Add new tests to ensure that --commit, --abort, and --strategy are
> mutually exclusive.
>
> Signed-off-by: Jacob Keller
Reviewed-by: Johan Herland
--
Johan Herland,
www.herland.net
--
To uns
On Tue, Aug 11, 2015 at 10:57 PM, Jacob Keller wrote:
> From: Jacob Keller
>
> Teach documentation about the cat_sort_uniq rewriteMode that got added
> at the same time as the equivalent merge strategy.
>
> Signed-off-by: Jacob Keller
Reviewed-by: Johan Herland
On Wed, Aug 12, 2015 at 4:26 AM, Junio C Hamano wrote:
> Johan Herland writes:
>> I know that we don't yet have a "proper" place to put remote notes refs,
>> but the in notes..merge _must_ be a "local" notes ref (you even
>> use the notation in t
gt; enforce these values always are fully qualified and begin with refs.
> Otherwise, use of --refs and the environment variable don't allow the
> same formats.
Agreed.
...Johan
> Regards,
> Jake
>
> [1] 8ef313e1ec3b ("builtin/notes.c: Split notes ref DWIMm
t; think we can maintain expectations for the general user but I feel
> that any change here will break *someones* scripts.
As I said above: Punt on tags for now, and you might be able to not
break anyone's scripts (and if you do, it's probably a poorly written
script). Provided that y
ergestrategy::
Same here.
> + Which merge strategy to choose by default when resolving notes
> + conflicts. Must be one of `manual`, `ours`, `theirs`, `union`,
> + or `cat_sort_uniq`. Defaults to `manual`. See "NOTES MERGE
> + STRATEGIES" section a
seful here, methinks:
must be the short name of a ref under refs/notes/, e.g. for
configuring
the merge strategy for refs/notes/commits, notes.commits.mergeStrategy must
be set.
Otherwise, the patch looks good to me.
...Johan
--
Johan Herland,
www.herland.net
--
To unsubscribe f
le the "overwrite", which
> is basically a synonym of, I think "theirs" depending on the direction
> of the "merge".
Correct.
> I don't know if re-write actually supports manual mode at all!
It doesn't.
> Maybe we could make merge support
..Johan
> Add tests for the new synonyms.
>
> Teaching rewrite how to understand merge terminology is left for a
> following patch.
>
> Signed-off-by: Jacob Keller
--
Johan Herland,
www.herland.net
--
To unsubscribe from this list: send the line "unsubscribe git&quo
more general
"notes.mergeStrategy".
Otherwise, the series (except possibly #4/#5, see separate discussion)
looks good to me.
...Johan
--
Johan Herland,
www.herland.net
--
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
re are no notes whatsoever, this variable is still
> `NULL`, even after initialization.
>
> So let's be graceful and just return if that data structure is `NULL`.
>
> Reported in https://github.com/msysgit/git/issues/363.
>
> Signed-off-by: Johannes Schindelin
Ac
side the
notes.h API (see commit_notes() in notes-utils.h/c), so there might be
room for more consolidation/refactoring here...
...Johan
--
Johan Herland,
www.herland.net
--
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
er
> the notes tree is intended to be used for reads only, or will be updated,
> a flag is added.
>
> This has the side effect of enabling the use of committish as notes refs
> in commands allowing them, e.g. git log --notes=foo@{1}.
>
> Signed-off-by: Mike Hommey
Reviewed-by: J
patch comes
with no tests. I'd like at least a couple of tests thrown in there to verify
correctness; e.g. reading notes from refs/notes/commits^{tree} shall
succeed, and trying to write notes to refs/notes/commits^{tree} shall fail.
...Johan
--
Johan Herland,
www.herland.net
--
To unsubscri
behaviour happens when using the filemodify command to import
> subdirectories.
>
> This change makes do_change_note_fanount call load_tree() whenever the
> tree_entry it is given has no tree loaded, making all cases handled
> equally.
>
> Signed-off-by: Mike Hommey
Acked-by: Johan Herland
ect` option for this.
>From git-config(1):
branch..description
Branch description, can be edited with git branch
--edit-description. Branch description is automatically added
in the format-patch cover letter or request-pull summary.
...Johan
--
Johan Herland,
www.herland.net
warn or die nowadays if this option is in the
> config, but I had some old config of mine use this option, I'd
> forgotten that it was a synonym, and nothing in git's documentation
> mentioned that.
>
> That's bad, either we shouldn't support it at all, or we shou
On Fri, Apr 1, 2016 at 2:16 PM, Johan Herland wrote:
> for notes_ref in $(git for-each-ref refs/notes | cut -c 49-)
> do
> echo "--- $notes_ref ---"
> for annotated_obj in $(git notes --ref=$notes_ref list | cut -c 41-)
> do
> type=$(git
test "$type" != "commit"
then
echo "$annotated_obj: $type"
fi
done
done
Can probably be made even faster by using the --batch option to cat-file...
...Johan
--
Johan Herland,
www.herland.net
--
To unsubscribe from this
On Mon, Apr 4, 2016 at 9:46 AM, Sebastian Schuberth
wrote:
> On Fri, Apr 1, 2016 at 2:16 PM, Johan Herland wrote:
>>> 3) Recursively list all blobs / trees (git-ls-tree) and look whether an
>>> object's hash is conatined in our table to get its notes.
>>>
>
should also become possible, although I
haven't thoroughly examined all implications.
...Johan
--
Johan Herland,
www.herland.net
--
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
On Mon, Nov 16, 2015 at 12:23 AM, Jacob Keller wrote:
> On Sun, Nov 15, 2015 at 2:14 PM, Johan Herland wrote:
>> A related topic that has been discussed (although I cannot remember if
>> any conclusion was reached) is whether to allow more notes operations
>> - spe
eems ok enough to
> me.
Yes, given $whatever, we should first lookup $whatever, and only
failing that, we should try refs/notes/$whatever. Maybe it's also
worth trying refs/$whatever (before refs/notes/$whatever), since that
would be consistent with what's currently done for o
Signed-off-by: Carlo Marcelo Arenas Belón
Signed-off-by: Johan Herland
> ---
> builtin/notes.c | 4 +---
> 1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/builtin/notes.c b/builtin/notes.c
> index c05cd004ab..68062f7475 100644
> --- a/builtin/notes.c
> +++
ET_PTR_TYPE(p) == PTR_TYPE_INTERNAL))
+ return -2; /* Cannot move int_nodes within the tree. */
for a more optimal handling of subtree nodes in this scenario.
Have fun! :)
...Johan
> /* replace tree with p in parent[index] */
> parent->a[index] = p;
> free(tree);
> --
> 2.12.1.dirty
>
--
Johan Herland,
www.herland.net
On Sat, Aug 26, 2017 at 10:28 AM, Michael Haggerty wrote:
[...]
> plenty that could be cleaned up in the area:
>
> * Make macro `GIT_NIBBLE` safer by adding some parentheses
> * Remove some dead code
> * Fix some memory leaks
> * Fix some obsolete and incorrect comments
> * Reject "notes" that are
ed a commit with these changes and confirmed the
> test suite passes, in case we get an ACK from Johan.
ACK :-)
Error messages should go to stderr, and redirection in the tests
should be fixed.
...Johan
--
Johan Herland,
www.herland.net
On Tue, Nov 14, 2017 at 5:17 PM, Todd Zullinger wrote:
> All other error messages from notes use stderr. Do the same when
> alerting users of an unresolved notes merge.
>
> Fix the output redirection in t3310 and t3320 as well. Previously, the
> tests directed output to a file, but stderr was ei
ot;where we pull from", and "where we push to". As
such, "@{push}" should have a corresponding "@{pull}" (which I believe
should function as an alias of "@{upstream}"). [1]
...Johan
[1]: I don't think there is a reason not to reuse the &
g uncharted
territory...
So for now (and in lieu of a convincing use case for
notes-as-commits), I suggest you only look at notes-as-trees. The
first consequence of this is probably that your added -o/--object
option should be renamed. -t/--tree is not taken, AFAICS...
> Johan Herland wrot
On Wed, Feb 19, 2014 at 12:10 AM, Duy Nguyen wrote:
> On Tue, Feb 18, 2014 at 9:46 PM, Johan Herland wrote:
>> On Mon, Feb 17, 2014 at 11:48 AM, wrote:
>>> The recent "git-note -C changes commit type?" thread
>>> (http://thread.gmane.org/gmane.comp.version
On Mon, Feb 24, 2014 at 11:27 AM, wrote:
> Johan Herland wrote on 02/24/2014 02:29:10:
>> I've been thinking about this for a while now, and I find myself
>> agreeing more and more with Junio's argument in the linked thread.
>>
>> I think notes are fundamen
u use
double instead of single quotes?
...Johan
--
Johan Herland,
www.herland.net
--
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
On Tue, Mar 4, 2014 at 3:57 PM, Matthijs Kooijman wrote:
> On Tue, Mar 04, 2014 at 03:53:24PM +0100, Johan Herland wrote:
>> What would you expect echo '$name' to do?
> If I run git submodule foreach each '$name', then my shell eats the
> single quotes (whic
u have for how to get there.
...Johan
--
Johan Herland,
www.herland.net
--
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
why Git shouldn't be able to leverage
Watchman the same way Mercurial does.
...Johan
--
Johan Herland,
www.herland.net
--
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
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.he
25e48f5ead73c9ce233986f90791abec9f1e8 (W.
Trevor King: submodule: explicit local branch creation in
module_clone). Looking at the patch, it seems to introduce an implicit
assumption on the submodule origin having a "master" branch. Is this
an intended change in behaviour?
...Johan
--
Joha
> On Thu, Mar 27, 2014 at 06:31:27PM +0100, Jens Lehmann wrote:
>> >> Am 27.03.2014 18:16, schrieb Junio C Hamano:
>> >> > Johan Herland writes:
>> >> >> I just found a failure to checkout a project with submodules where
>> >> >> the
misconfiguration on the superproject's part that warrants an
> error. But I may be wrong here as I only use 'checkout' together
> with a detached HEADs myself. Comments welcome.
I believe unset 'branch' and 'update' != 'checkout' is somewhat
analogous
, 2014 at 7:21 PM, W. Trevor King wrote:
> On Wed, Apr 16, 2014 at 02:54:48AM +0200, Johan Herland wrote:
>> This is a work-in-progress to flesh out (and promote discussion about)
>> the expected behaviors for all possible scenarios in which
>> 'git submodule update
or "git svn" (as announced in Documentation/git-svn.txt and
the release notes for v1.8.5 and v1.9.0).
For reference, it was posted as patch 3/3 back in October:
http://thread.gmane.org/gmane.comp.version-control.git/232761/focus=235900
Very sorry for not discovering this earlier.
...Joh
Add a description of <=1.9 behavior in the manpage. Users on
long-term-support systems are likely to continue using ancient
git installations for some time (5-10 years, even?), but may
come across the current documentation online.
Suggested-by: Eric Wong
Signed-off-by: Johan Herland
---
&
On Sat, Aug 30, 2014 at 9:56 PM, Alex Henrie wrote:
> Hi, I submitted this patch a week ago and got no reply, so I'm sending
> it again and CC'ing the original authors this time...
>
> Signed-off-by: Alex Henrie
Looks good to me.
Acked-by: Johan Herland
--
Johan Her
Add --no-verify to the revert and cherry-pick man pages. Also mention
revert and cherry-pick in the corresponding documentation for the
pre-commit and commit-msg hooks.
Signed-off-by: Johan Herland
---
Documentation/git-cherry-pick.txt | 4
Documentation/git-revert.txt | 4
lated options.
This fixes the failing t7503/t7504 test cases added previously.
Signed-off-by: Johan Herland
---
builtin/revert.c | 1 +
sequencer.c| 7 +++
sequencer.h| 1 +
t/t7503-pre-commit-hook.sh | 4 ++--
t/t7504-commit-msg-hook.sh | 4 ++--
5 file
-verify
option is supposed when it is added to revert and cherry-pick
(in the next patch).
Signed-off-by: Johan Herland
---
t/t7503-pre-commit-hook.sh | 24
t/t7504-commit-msg-hook.sh | 24
2 files changed, 48 insertions(+)
diff --git a/t/t7503-pre
A colleague of mine noticed that cherry-pick does not accept the
--no-verify option to skip running the pre-commit/commit-msg hooks.
Here's a first attempt at adding --no-verify to the revert/cherry-pick.
Have fun! :)
...Johan
Johan Herland (3):
t7503/4: Add failing testcases for r
On Wed, Sep 3, 2014 at 9:32 PM, Junio C Hamano wrote:
> Johan Herland writes:
>> diff --git a/builtin/revert.c b/builtin/revert.c
>> index f9ed5bd..831c2cd 100644
>> --- a/builtin/revert.c
>> +++ b/builtin/revert.c
>> @@ -91,6 +91,7 @@ static void parse_args(in
sguided. Please drop it, Junio, and I'm very sorry for the noise.
Hopefully, I will learn not to blindly follow my assumptions.
...Johan
--
Johan Herland,
www.herland.net
--
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
otes/commits:refs/notes/commits
> +
> +
> +or
> +
> +
> +$ git push origin refs/notes/commits
> +
> +
> +
> EXAMPLES
>
>
> --
> 2.1.0.127.g0c72b98
>
> --
> To unsubscribe from this list: send the line &q
amp;
test_must_fail git notes merge foo^{bar
Additionally, I suggest adding another test demonstrating your use
case as well. Something like setting up a small scenario for notes
collaboration, and walking through the various steps:
- Creating a couple of repos where notes are added/edited
-
On Fri, Sep 19, 2014 at 8:22 PM, Junio C Hamano wrote:
> Johan Herland writes:
>> On Fri, Sep 19, 2014 at 11:39 AM, Jeff King wrote:
>>> On Fri, Sep 19, 2014 at 09:39:45AM +0200, Scott Chacon wrote:
>>>> Currently if you try to merge notes, the notes code ensu
add" is modeled: Empty input
is interpreted as an intent to abort, which, in the notes case is to
simply not create the note at all.
> I was surprised to see that this behavior was deliberately introduced:
>
> > git log -1 a0b4dfa
> commit a0b4dfa9b35a2ebac578ea5547b041bb78
it notes add -C $empty_blob".
Reported-by: James H. Fisher
Signed-off-by: Johan Herland
---
builtin/notes.c | 16 +++-
notes.c | 3 +--
t/t3301-notes.sh | 19 +++
3 files changed, 31 insertions(+), 7 deletions(-)
diff --git a/builtin/notes.c b/b
On Sun, Sep 21, 2014 at 10:53 AM, Torsten Bögershausen wrote:
> On 2014-09-21 05.00, Johan Herland wrote:
[...]
>> +cat > expect << EOF
> Git style for shell scripts: Plase put no space between < or > or >> and the
> file name:
> cat >expect <> +
ying disk
drive) is a good idea at all. Finally, this syncing step will have to
bypass Git's usual reachability analysis (which easily skips fetching
a corrupt blob from otherwise-reachable history), is more involved
than simply calling out to "git fetch"...
...Johan
--
Johan
On Thu, Oct 16, 2014 at 2:25 PM, Jeff King wrote:
> On Thu, Oct 16, 2014 at 11:04:04AM +0200, Johan Herland wrote:
>> I simply copied the packfile containing the good copy into the
>> corrupted repo, and then ran a "git gc", which "happened" to use the
>&
Add test cases documenting the current behavior when trying to
add/append/edit empty notes. This is in preparation for adding
--allow-empty; to allow empty notes to be stored.
Signed-off-by: Johan Herland
---
t/t3312-notes-empty.sh | 58 ++
1 file
altogether.
Introduce the --allow-empty option to the add/append/edit subcommands,
to explicitly allow an empty note to be stored into the notes tree.
Also update the documentation, and add test cases for the new option.
Reported-by: James H. Fisher
Improved-by: Kyle J. McKay
Signed-off-by: Joh
given (e.g. using -m "" or -F /dev/null).
The next patch contains a test that verifies the fixed behavior.
Found-by: Eric Sunshine
Signed-off-by: Johan Herland
---
builtin/notes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/notes.c b/builtin/notes.c
ind
> Each -c/-C case fails for me when trying to read $empty_object. For example:
>
> fatal: Failed to read object 'e69de29bb2d1d6434b8b29ae775ad8c2e48c5391'.
> not ok 5 - 'git notes add -c "$empty_blob"' removes empty note
These are all fixed in the re-r
Add test cases documenting the current behavior when trying to
add/append/edit empty notes. This is in preparation for adding
--allow-empty; to allow empty notes to be stored.
Improved-by: Eric Sunshine
Signed-off-by: Johan Herland
---
t/t3312-notes-empty.sh | 48
altogether.
Introduce the --allow-empty option to the add/append/edit subcommands,
to explicitly allow an empty note to be stored into the notes tree.
Also update the documentation, and add test cases for the new option.
Reported-by: James H. Fisher
Improved-by: Kyle J. McKay
Signed-off-by: Joh
On Wed, Nov 5, 2014 at 8:00 PM, Junio C Hamano wrote:
> Johan Herland writes:
>> +verify_missing() {
>> + git log -1 > actual &&
>
> Hmph, it was unclear what exactly you are trying to check with this
> one and the other "git log -1 >expect_missin
follow-up patch (#4)
- Add a final (optional) patch with some whitespace and other
cleanups in t3301. Feel free to drop this if it's too much
churn.
Have fun! :)
...Johan
Johan Herland (5):
builtin/notes: Fix premature failure when trying to add the empty blob
t3301: Verify tha
o C Hamano
Signed-off-by: Johan Herland
---
Documentation/git-notes.txt | 12
builtin/notes.c | 23 ++-
t/t3301-notes.sh| 10 +-
3 files changed, 31 insertions(+), 14 deletions(-)
diff --git a/Documentation/git-notes.txt b/Documen
Add test cases documenting the current behavior when trying to
add/append/edit empty notes. This is in preparation for adding
--allow-empty; to allow empty notes to be stored.
Improved-by: Eric Sunshine
Improved-by: Junio C Hamano
Signed-off-by: Johan Herland
---
t/t3301-notes.sh | 27
given (e.g. using -m "" or -F /dev/null).
The next patch contains a test that verifies the fixed behavior.
Found-by: Eric Sunshine
Signed-off-by: Johan Herland
---
builtin/notes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/notes.c b/builtin/notes.c
ind
If the user has gone through the trouble of explicitly adding an empty
note, then "git log" should not silently skip it (as if it didn't exist).
Signed-off-by: Johan Herland
---
notes.c | 3 +--
t/t3301-notes.sh | 12
2 files changed, 13 insertions(
Signed-off-by: Johan Herland
---
Drop this if it's too much churn.
...Johan
t/t3301-notes.sh | 254 +++
1 file changed, 126 insertions(+), 128 deletions(-)
diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh
index f5d8193..80caee0 100755
fun! :)
...Johan
Johan Herland (9):
builtin/notes: Fix premature failure when trying to add the empty blob
t3301: Verify that 'git notes' removes empty notes by default
builtin/notes: Improve naming
builtin/notes: Refactor note file path into struct note_data
builtin/notes: S
given (e.g. using -m "" or -F /dev/null).
The next patch contains a test that verifies the fixed behavior.
Found-by: Eric Sunshine
Signed-off-by: Johan Herland
---
builtin/notes.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/notes.c b/builtin/notes.c
ind
_edit()), keeping the logic for writing the actual note
object in a separate function: write_note_data().
Suggested-by: Junio C Hamano
Signed-off-by: Johan Herland
---
builtin/notes.c | 103 +---
1 file changed, 54 insertions(+), 49 deletions(-)
On Fri, Nov 7, 2014 at 7:04 PM, Junio C Hamano wrote:
> Johan Herland writes:
[...]
> Assuming that it is a good idea to "allow" empty notes, I think
> there are two issues involved here:
>
> * Traditionally, feeding an empty note is taken as a request to
>
If the user has gone through the trouble of explicitly adding an empty
note, then "git log" should not silently skip it (as if it didn't exist).
Signed-off-by: Johan Herland
---
notes.c | 3 +--
t/t3301-notes.sh | 12
2 files changed, 13 insertions(
Add test cases documenting the current behavior when trying to
add/append/edit empty notes. This is in preparation for adding
--allow-empty; to allow empty notes to be stored.
Improved-by: Eric Sunshine
Improved-by: Junio C Hamano
Signed-off-by: Johan Herland
---
t/t3301-notes.sh | 27
mproved-by: Junio C Hamano
Signed-off-by: Johan Herland
---
t/t3301-notes.sh | 1148 +-
1 file changed, 522 insertions(+), 626 deletions(-)
diff --git a/t/t3301-notes.sh b/t/t3301-notes.sh
index 416ed9e..cd756ec 100755
--- a/t/t3301-notes.sh
+++
Move the 'path' variable from create_note() and into the
note_data struct. Unify cleanup of note_data objects with
a free_note_data() function.
This might not make too much sense on its own, but it makes the
future refactoring of create_note() considerably cleaner.
Signed-off-by: Joh
ntents
of a note.
Also rename write_note_data() to copy_obj_to_fd(), which more aptly
describes what it actually does: Copying the contents of a git object
(given by its SHA1) into a given file descriptor.
Signed-off-by: Johan Herland
---
builtin/notes.c | 109 --
Signed-off-by: Johan Herland
---
builtin/notes.c | 12 +---
1 file changed, 5 insertions(+), 7 deletions(-)
diff --git a/builtin/notes.c b/builtin/notes.c
index 1017472..f1480cf 100644
--- a/builtin/notes.c
+++ b/builtin/notes.c
@@ -399,7 +399,7 @@ static int append_edit(int argc, const
o C Hamano
Signed-off-by: Johan Herland
---
Documentation/git-notes.txt | 12
builtin/notes.c | 17 +++--
t/t3301-notes.sh| 10 +-
3 files changed, 28 insertions(+), 11 deletions(-)
diff --git a/Documentation/git-notes.txt b/Documentation/git
On Mon, Nov 10, 2014 at 9:36 PM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> Signed-off-by: Johan Herland
>> ---
>> builtin/notes.c | 12 +---
>> 1 file changed, 5 insertions(+), 7 deletions(-)
>>
>> diff --git a/builtin/notes.c b/builti
On Mon, Nov 10, 2014 at 9:42 PM, Junio C Hamano wrote:
> Johan Herland writes:
>
>> Make this test script appear somewhat less old-fashioned:
>> - Use test helper functions:
>> - write_script
>> - test_commit
>> - test_write_lines
>>
how HEAD^
@@ -102,7 +102,7 @@ test_expect_success 'can overwrite existing note
with "git notes add -f -m"' '
test_expect_success 'add w/no options on existing note morphs into edit' '
MSG=b2 git notes add &&
test_path_is_missing .git/NOTES_
1 - 100 of 344 matches
Mail list logo
