...and check all other merge strategies with testcases while we're at it.
When the index has a staged change before running git merge, most the time
git merge will error out telling the user that the merge operation would
toss their merged changes unless they commit them first. There are two
exce
This patch series adds an --index-only flag to git merge, the idea
being to allow a merge to be performed entirely in the index without
touching (or even needing) a working tree.
The core fix, to merge-recursive, was actually quite easy. The
recursive merge logic already had the ability to ignore
There were a few cases in merge-recursive that could result in a check for
the presence of files in the working copy while trying to create a virtual
merge base. These were rare and innocuous, but somewhat illogical. The
two cases were:
* When there was naming conflicts (e.g. a D/F conflict) a
Signed-off-by: Elijah Newren
---
git-merge-resolve.sh| 12 ++--
t/t6043-merge-index-only.sh | 4 ++--
2 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/git-merge-resolve.sh b/git-merge-resolve.sh
index c9da747..ed4a25b 100755
--- a/git-merge-resolve.sh
+++ b/git-mer
Signed-off-by: Elijah Newren
---
t/t6043-merge-index-only.sh | 170
1 file changed, 170 insertions(+)
create mode 100755 t/t6043-merge-index-only.sh
diff --git a/t/t6043-merge-index-only.sh b/t/t6043-merge-index-only.sh
new file mode 100755
index 000
This is almost trivial to make work, because we already know that the
working tree will need no modifications, but lets test it for completeness
anyway.
Signed-off-by: Elijah Newren
---
t/t6043-merge-index-only.sh | 32
1 file changed, 32 insertions(+)
diff --gi
Signed-off-by: Elijah Newren
---
git-merge-one-file.sh | 44 +++-
1 file changed, 35 insertions(+), 9 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index 424b034..78efa00 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file
From: Elijah Newren
This almost works. It creates the correct merge commit, updates the
branch, but then if the repo is bare it leaves the index as it was before
the merge (and if the repo is non-bare it updates the index). I'm
totally lost as to why the testcase behaves differently in the bare
On Fri, Apr 8, 2016 at 2:37 AM, Kazuki Yamaguchi wrote:
> On Thu, Apr 07, 2016 at 05:20:10PM -0400, Eric Sunshine wrote:
>> On Sun, Mar 27, 2016 at 10:37 AM, Kazuki Yamaguchi wrote:
>> > +int set_worktree_head_symref(const char *gitdir, const char *target)
>> > +{
>> > + static struct lock_
On Thu, Apr 07, 2016 at 05:20:10PM -0400, Eric Sunshine wrote:
> On Sun, Mar 27, 2016 at 10:37 AM, Kazuki Yamaguchi wrote:
> > Add a new function set_worktree_head_symref, to update HEAD symref for
> > the specified worktree.
> >
> > To update HEAD of a linked working tree,
> > create_symref("work
David Turner writes:
> On Thu, 2016-04-07 at 15:52 -0700, Junio C Hamano wrote:
>> Junio C Hamano writes:
>>
>> > > +untracked = data + len + 8 + bitmap_size;
>> >
>> > This breaks compilation as data here is of type (void *).
>> >
>> > There may be similar breakages in this p
Greetings to you.
My names are Mrs Estelle Amadieu, I live in Cote d'Ivoire, I want to entrust a
huge amount of money in your care (USD 2. 5) million dollars for charity work
in your country. I have been suffering from cancer I want to know if I can
trust you to use these funds for charity/orp
On Thu, 2016-04-07 at 15:52 -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > > + untracked = data + len + 8 + bitmap_size;
> >
> > This breaks compilation as data here is of type (void *).
> >
> > There may be similar breakages in this patch.
>
> It turns out that this is th
Junio C Hamano writes:
>> +untracked = data + len + 8 + bitmap_size;
>
> This breaks compilation as data here is of type (void *).
>
> There may be similar breakages in this patch.
It turns out that this is the only one, and
untracked = (char *)data + len + 8 + bitmap_size;
David Turner writes:
> diff --git a/read-cache.c b/read-cache.c
> index 59d892e..b6e9244 100644
> --- a/read-cache.c
> +++ b/read-cache.c
> @@ -1407,10 +1472,24 @@ static int read_watchman_ext(struct index_state
> *istate, const void *data,
> ewah_each_bit(bitmap, mark_no_watchman, istate)
David Turner writes:
> We now have quite a large number of patches before we even get into
> the meat of the pluggable refs backend series. So it's worth breaking
> those out and getting them in before we get into the main series
> (which Michael Haggerty swants to redesign a bit anyway).
>
> Th
Pranit Bauva writes:
> On Fri, Apr 8, 2016 at 12:31 AM, Junio C Hamano wrote:
>> Here are the topics that have been cooking. Commits prefixed with
>> '-' are only in 'pu' (proposed updates) while commits prefixed with
>> '+' are in 'next'. The ones marked with '.' do not appear in any of
>> th
On Thu, Apr 7, 2016 at 12:46 PM, Jacob Keller wrote:
> The documentation for format-patch indicates that --no-patch wilL
> suppress patch output. It also incorrectly mentions that -s will also
> suppress the patch output, but this is incorrect because -s is used to
> add the sign-off line first. F
On Sun, Mar 27, 2016 at 10:37 AM, Kazuki Yamaguchi wrote:
> Add a new function set_worktree_head_symref, to update HEAD symref for
> the specified worktree.
>
> To update HEAD of a linked working tree,
> create_symref("worktrees/$work_tree/HEAD", "refs/heads/$branch", msg)
> could be used. However
On Fri, Apr 8, 2016 at 12:31 AM, Junio C Hamano wrote:
> Here are the topics that have been cooking. Commits prefixed with
> '-' are only in 'pu' (proposed updates) while commits prefixed with
> '+' are in 'next'. The ones marked with '.' do not appear in any of
> the integration branches, but I
Hi,
say I got a file called "asdf" somewhere in a subdirectory. I can do:
git diff other_branch -- \*asdf
and it will show me the diff *only* of that file (which is the only one
that matches), so it works as expected. But if I do on the other hand:
git checkout other_branch -- \*asdf
I get: er
Hello,
A "git stash -u" cleans all untracked files (after storing them), and
normally does not clean ignored files.
But: It cleans ignored files within a directory, when the directory
itself is not ignored (e.g. a "dir/*" ignore filter) and untracked.
See the following reproduction sample. The l
I help manage a Linux kernel repo for a large company. I have encountered
an odd problem that I think should not exist, but does.
At one point a merge was done from the development repo to the local
branch. Two of the existing commits have the same change to the same
location. At first glance they
On Thu, Apr 07, 2016 at 12:56:26PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > Yes, FWIW, those were the sites and reasons I identified last night.
> > Your patch looks like the right thing to me.
>
> Thanks, let's do this then. I'd already anticipated your sign-off ;-).
>
> -- >8
On Thu, Apr 07, 2016 at 12:37:53PM -0700, Junio C Hamano wrote:
> -- >8 --
> Subject: setup.c: do not feed NULL to "%.*s" even with the precision 0
>
> A recent update 75faa45a (replace trivial malloc + sprintf / strcpy
> calls with xstrfmt, 2015-09-24) rewrote
>
> prepare an empty buffer
On 07/04/16 20:50, Junio C Hamano wrote:
Junio C Hamano writes:
So perhaps this is all we need to fix your box.
setup.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
Yes that seems to work very well.
I applied this patch to 2.8.0 and have completed a testsuite run on
Solaris 2.6
Hi Christian,
On Thu, Apr 07, 2016 at 04:06:59PM -0400, Christian Couder wrote:
> On Wed, Apr 6, 2016 at 12:37 PM, Willy Tarreau wrote:
> > On Wed, Apr 06, 2016 at 07:57:01AM -0700, Junio C Hamano wrote:
> >> This seems to have been lost, perhaps because the top part that was
> >> quite long didn
On Wed, Apr 6, 2016 at 12:37 PM, Willy Tarreau wrote:
> On Wed, Apr 06, 2016 at 07:57:01AM -0700, Junio C Hamano wrote:
>> This seems to have been lost, perhaps because the top part that was
>> quite long didn't look like a patch submission message or something.
>
> Don't worry, we all know it's t
Jeff King writes:
> Yes, FWIW, those were the sites and reasons I identified last night.
> Your patch looks like the right thing to me.
Thanks, let's do this then. I'd already anticipated your sign-off ;-).
-- >8 --
From: Jeff King
Subject: commit: do not ignore an empty message given by -m '
Jeff King writes:
>> So perhaps this is all we need to fix your box.
>>
>> setup.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/setup.c b/setup.c
>> index 3439ec6..b6c8aab 100644
>> --- a/setup.c
>> +++ b/setup.c
>> @@ -103,7 +103,7 @@ char *prefix_path_gently(co
From: Michael Haggerty
In place of `buf`, use `refname`, which is anyway a better description
of what is being pointed at.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/refs/files-backend.c b/refs/file
From: Michael Haggerty
Check "branch -d broken...ref"
Check various combinations of
* Deleting using "update-ref -d"
* Deleting using "update-ref --no-deref -d"
* Deleting using "branch -d"
in the following combinations of symref -> ref:
* badname -> broken...ref
* badname -> broken...ref (da
On Thu, Apr 07, 2016 at 11:50:46AM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > "Tom G. Christensen" writes:
> >
> >> The reason for the crash is simple, a null value was passed to the 's'
> >> format for the *printf family of functions.
> >> ...
> >> Passing a null value to the
When locking a symbolic ref to expire a reflog, lock the symbolic
ref (using REF_NODEREF) instead of its referent.
Add a test for this.
Signed-off-by: David Turner
Signed-off-by: Junio C Hamano
---
refs/files-backend.c | 3 ++-
t/t1410-reflog.sh| 10 ++
2 files changed, 12 inserti
On Thu, Apr 07, 2016 at 11:12:19AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > I guessed that this might have come from the conversion of "message"
> > form a pointer (which could be NULL) into a strbuf. And indeed, it looks
> > like f956853 (builtin-commit: resurrect behavior for mul
From: Michael Haggerty
If there is an error in resolve_ref_unsafe(), it returns NULL. We check
for this case, but not until after calling strip_namespace(). Instead,
call strip_namespace() *after* the NULL check.
Signed-off-by: Michael Haggerty
---
builtin/receive-pack.c | 2 +-
1 file changed
From: Michael Haggerty
Make resolve_missing_loose_ref() only responsible for looking up a
packed reference, without worrying about whether we want to read or
write the reference and without setting errno on failure. Move the other
logic to the caller.
Signed-off-by: Michael Haggerty
---
refs/f
From: Michael Haggerty
Signed-off-by: Michael Haggerty
---
t/t1430-bad-ref-name.sh | 16
1 file changed, 16 insertions(+)
diff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh
index a963951..612cc32 100755
--- a/t/t1430-bad-ref-name.sh
+++ b/t/t1430-bad-ref-name.sh
@@
From: Michael Haggerty
Signed-off-by: Michael Haggerty
---
t/t1430-bad-ref-name.sh | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
diff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh
index c465abe..005e2b1 100755
--- a/t/t1430-bad-ref-name.sh
+++ b/t/t1430-
From: Michael Haggerty
If the caller passes flags==NULL, then set it to point at a local
scratch variable. This removes the need for a lot of "if (flags)" guards
in resolve_ref_1() and resolve_missing_loose_ref().
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 31 +-
From: Michael Haggerty
It is never read, so we can pass NULL to resolve_ref_unsafe().
Signed-off-by: Michael Haggerty
---
builtin/fsck.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/fsck.c b/builtin/fsck.c
index 55eac75..3f27456 100644
--- a/builtin/fsck.c
+++
From: Michael Haggerty
The loop's there anyway; we might as well use it.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 13 ++---
1 file changed, 6 insertions(+), 7 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index c0cf6fd..101abba 100644
--- a/re
From: Michael Haggerty
It's questionable whether it should even work.
Signed-off-by: Michael Haggerty
---
t/t1430-bad-ref-name.sh | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh
index cb815ab..a963951 100755
--- a/t/t143
From: Michael Haggerty
Signed-off-by: Michael Haggerty
---
t/t1430-bad-ref-name.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t1430-bad-ref-name.sh b/t/t1430-bad-ref-name.sh
index 005e2b1..cb815ab 100755
--- a/t/t1430-bad-ref-name.sh
+++ b/t/t1430-bad-ref-name.sh
@@ -
From: Michael Haggerty
It is never read, so we can pass NULL to resolve_ref_unsafe().
Signed-off-by: Michael Haggerty
---
builtin/checkout.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/builtin/checkout.c b/builtin/checkout.c
index efcbd8f..ea2fe1c 100644
--- a/builtin
Now that resolve_ref_unsafe's only interaction with the backend is
through read_raw_ref, we can move it into the common code. Later,
we'll replace read_raw_ref with a backend function.
Signed-off-by: David Turner
Signed-off-by: Junio C Hamano
---
refs.c | 74 ++
From: Michael Haggerty
It is never read, so we can pass NULL to resolve_ref_unsafe().
Signed-off-by: Michael Haggerty
---
builtin/merge.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin/merge.c b/builtin/merge.c
index 101ffef..c90ee51 100644
--- a/builtin/merge.
From: Michael Haggerty
resolve_ref_unsafe() wasn't doing anything useful anymore.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 31 +--
1 file changed, 9 insertions(+), 22 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index f752
From: Michael Haggerty
read_raw_ref() is going to be part of the vtable for reference backends,
so clean up its interface to use "unsigned int flags" rather than "int
flags". Its caller still uses signed int for its flags arguments. But
changing that would touch a lot of code, so leave it for now
We now have quite a large number of patches before we even get into
the meat of the pluggable refs backend series. So it's worth breaking
those out and getting them in before we get into the main series
(which Michael Haggerty swants to redesign a bit anyway).
This set of patches should be applie
From: Michael Haggerty
Only use the result of resolve_ref_namespace() if it is non-NULL.
Signed-off-by: Michael Haggerty
---
http-backend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/http-backend.c b/http-backend.c
index 8870a26..2148814 100644
--- a/http-backend.c
On Thu, Apr 07, 2016 at 10:50:06AM +0100, Adam Dinwoodie wrote:
> > PS Is there a previous thread? I see a couple people cc'd, including me,
> >but I don't remember a previous discussion. Did I just forget it?
>
> No previous thread: I noticed the odd behaviour, and figured I'd report
> it.
From: Michael Haggerty
Instead of creating scratch space in resolve_ref_unsafe() and passing it
down through resolve_ref_1 to read_raw_ref(), teach read_raw_ref() to
manage its own scratch space. This reduces coupling across the functions
at the cost of some extra allocations. Also, when read_raw
Make do_for_each_ref take a submodule as an argument instead of a
ref_cache. Since all for_each_*ref* functions are defined in terms of
do_for_each_ref, we can then move them into the common code.
Later, we can simply make do_for_each_ref into a backend function.
Signed-off-by: David Turner
Sig
Refactor resolve_ref_1 in terms of a new function read_raw_ref, which
is responsible for reading ref data from the ref storage.
Later, we will make read_raw_ref a pluggable backend function, and make
resolve_ref_unsafe common.
Signed-off-by: David Turner
Helped-by: Duy Nguyen
Signed-off-by: Jun
From: Michael Haggerty
There is no need to adjust *flags if we're just about to fail.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 69ec903..60f1493 100644
--- a
From: Michael Haggerty
We can use (*flags & REF_BAD_NAME) for that purpose.
Signed-off-by: Michael Haggerty
---
refs/files-backend.c | 13 +
1 file changed, 5 insertions(+), 8 deletions(-)
diff --git a/refs/files-backend.c b/refs/files-backend.c
index 60f1493..b865ba5 100644
--- a
These don't use any backend-specific functions. These were previously
defined in terms of the do_head_ref helper function, but since they
are otherwise identical, we don't need that function.
Signed-off-by: David Turner
Signed-off-by: Junio C Hamano
---
refs.c | 23 ++
On 07/04/16 20:32, Junio C Hamano wrote:
"Tom G. Christensen" writes:
The reason for the crash is simple, a null value was passed to the 's'
format for the *printf family of functions.
...
Passing a null value to the 's' format is explicitly documented as
giving undefined results on Solaris, e
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
The 'master' branch now has the se
On Thu, 2016-04-07 at 11:50 -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > "Tom G. Christensen" writes:
> >
> > > The reason for the crash is simple, a null value was passed to
> > > the 's'
> > > format for the *printf family of functions.
> > > ...
> > > Passing a null value to t
Junio C Hamano writes:
> "Tom G. Christensen" writes:
>
>> The reason for the crash is simple, a null value was passed to the 's'
>> format for the *printf family of functions.
>> ...
>> Passing a null value to the 's' format is explicitly documented as
>> giving undefined results on Solaris, ev
On Thu, 2016-04-07 at 16:14 +0200, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 7 Apr 2016, Johannes Sixt wrote:
>
> > Am 07.04.2016 um 00:11 schrieb David Turner:
> > > +static void share_index(struct index_state *istate, struct shm
> > > *is)
> > > +{
> > > + void *new_mmap;
> > > + if (istate-
"Tom G. Christensen" writes:
> The reason for the crash is simple, a null value was passed to the 's'
> format for the *printf family of functions.
> ...
> Passing a null value to the 's' format is explicitly documented as
> giving undefined results on Solaris, even on Solaris 11(2).
Do you mean
Hello,
While working on an update to the git packages in tgcware(1) I ran into
segfaults when running the testsuite.
Here's what it looks like on Solaris 7/SPARC:
Core was generated by
`/export/home/tgc/buildpkg/git/src/git-upstream/git update-index
should-be-empty'.
Program terminated wit
Jeff King writes:
> I guessed that this might have come from the conversion of "message"
> form a pointer (which could be NULL) into a strbuf. And indeed, it looks
> like f956853 (builtin-commit: resurrect behavior for multiple -m
> options, 2007-11-11) did that.
Yikes. That is a quite ancient
"Michael S. Tsirkin" writes:
> Aren't there other cases where a short option needs to be
> converted to a long one?
As I already said, making internal call to libified part (perhaps in
trailer.c) would make this part of conversation a moot point, but in
general you can find
argv_push(&c
On Thu, Apr 07, 2016 at 10:30:02AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > On Thu, Apr 07, 2016 at 09:55:29AM -0700, Junio C Hamano wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > Allow -t as a short-cut for --trailer.
> >> >
> >> > Signed-off-by: Michael S. Tsirk
"Michael S. Tsirkin" writes:
> - strbuf_addbuf(&msg, &mi.log_message);
> +
> + if (strbuf_read_file(&log_msg, am_path(state, "msg"), 0) < 0) {
> + die_errno(_("could not read '%s'"), am_path(state, "msg"));
> + }
Style: we omit the braces where not needed.
--
Matthieu
"Michael S. Tsirkin" writes:
> it's sometimes useful to be able to pass output message of
> git-mailinfo through git-interpret-trailers,
> but that creates problems since that does not
> include the subject and an empty line after that,
> making interpret-trailers add an empty line.
Nit: we usua
"Michael S. Tsirkin" writes:
> No - but then I will need to re-run mailinfo to parse the result,
> will I not?
By the way, I suspect (if Christian did his implementation right
when he did interpret-trailers) all these points may become moot.
I haven't re-reviewed what is in interpret-trailers,
On Thu, Apr 07, 2016 at 10:26:33AM -0700, Junio C Hamano wrote:
> Matthieu Moy writes:
>
> >> I am in principle OK with the later step that teaches a single
> >> letter option to end-user facing "git am" that would be turned into
> >> "--trailer" when it calls out to "interpret-trailers" (I haven
"Michael S. Tsirkin" writes:
> On Thu, Apr 07, 2016 at 09:55:29AM -0700, Junio C Hamano wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > Allow -t as a short-cut for --trailer.
>> >
>> > Signed-off-by: Michael S. Tsirkin
>> > ---
>>
>> As I do not think interpret-trailers is meant to be end-user
On Thu, Apr 07, 2016 at 09:55:29AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > Allow -t as a short-cut for --trailer.
> >
> > Signed-off-by: Michael S. Tsirkin
> > ---
>
> As I do not think interpret-trailers is meant to be end-user facing,
> I am not sure I should be inte
Matthieu Moy writes:
>> I am in principle OK with the later step that teaches a single
>> letter option to end-user facing "git am" that would be turned into
>> "--trailer" when it calls out to "interpret-trailers" (I haven't
>> checked if 't' is a sensible choice for that single letter option,
>
On Thu, Apr 07, 2016 at 10:00:37AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > it's sometimes useful to be able to pass output message of
> > git-mailinfo through git-interpret-trailers,
> > but that creates problems since that does not
> > include the subject and an empty l
Junio C Hamano writes:
> "Michael S. Tsirkin" writes:
>
>> it's sometimes useful to be able to pass output message of
>> git-mailinfo through git-interpret-trailers,
>> but that creates problems since that does not
>> include the subject and an empty line after that,
>> making interpret-trailers
Junio C Hamano writes:
> "Michael S. Tsirkin" writes:
>
>> Allow -t as a short-cut for --trailer.
>>
>> Signed-off-by: Michael S. Tsirkin
>> ---
>
> As I do not think interpret-trailers is meant to be end-user facing,
> I am not sure I should be interested in this step.
>
> I am in principle OK
On Thu, Apr 07, 2016 at 10:08:37AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > Slightly slower, but will allow easy additional processing on it.
> >
> > Signed-off-by: Michael S. Tsirkin
> > ---
>
> I haven't read 4/4 yet, but can guess from what this patch does that
> the
"Michael S. Tsirkin" writes:
> Slightly slower, but will allow easy additional processing on it.
>
> Signed-off-by: Michael S. Tsirkin
> ---
I haven't read 4/4 yet, but can guess from what this patch does that
the next step would let others futz with the contents of the message
that is on disk
"Michael S. Tsirkin" writes:
> it's sometimes useful to be able to pass output message of
> git-mailinfo through git-interpret-trailers,
> but that creates problems since that does not
> include the subject and an empty line after that,
> making interpret-trailers add an empty line.
>
> Add a fla
"Michael S. Tsirkin" writes:
> Allow -t as a short-cut for --trailer.
>
> Signed-off-by: Michael S. Tsirkin
> ---
As I do not think interpret-trailers is meant to be end-user facing,
I am not sure I should be interested in this step.
I am in principle OK with the later step that teaches a sing
The documentation for format-patch indicates that --no-patch wilL
suppress patch output. It also incorrectly mentions that -s will also
suppress the patch output, but this is incorrect because -s is used to
add the sign-off line first. Fix the documentation to remove the
indication about -s. Fix bu
On Thu, Apr 7, 2016 at 11:23 AM, Michael S. Tsirkin wrote:
> Pass -t and --trailer flags to git-reinterpret-trailers.
s/git-reinterpret-trailers/git-interpret-trailers/
Thanks,
Christian.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger
On Wed, Apr 6, 2016 at 11:40 PM, Santiago Torres wrote:
>> > v5 (this):
>> > Added helpful feedback by Eric
>> >
>> > * Reordering of the patches, to avoid temporal inclusion of a regression
>> > * Fix typos here and there.
>> > * Review commit messages, as some weren't representative of what t
On Thu, Apr 07, 2016 at 05:23:09PM +0200, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 7 Apr 2016, Michael S. Tsirkin wrote:
>
> > Reverts can typically be treated like squash. Eliminating both the
> > original commit and the revert would be even nicer, but this seems a bit
> > harder to impleme
Pass -t and --trailer flags to git-reinterpret-trailers.
Signed-off-by: Michael S. Tsirkin
---
builtin/am.c | 48
1 file changed, 48 insertions(+)
diff --git a/builtin/am.c b/builtin/am.c
index 4180b04..480c4c2 100644
--- a/builtin/am.c
+++ b/bui
Slightly slower, but will allow easy additional processing on it.
Signed-off-by: Michael S. Tsirkin
---
builtin/am.c | 9 -
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/builtin/am.c b/builtin/am.c
index d003939..4180b04 100644
--- a/builtin/am.c
+++ b/builtin/am.c
@@ -124
Allow -t as a short-cut for --trailer.
Signed-off-by: Michael S. Tsirkin
---
builtin/interpret-trailers.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/interpret-trailers.c b/builtin/interpret-trailers.c
index b99ae4b..18cf640 100644
--- a/builtin/interpret-trailers
Hi,
On Thu, 7 Apr 2016, Michael S. Tsirkin wrote:
> Reverts can typically be treated like squash. Eliminating both the
> original commit and the revert would be even nicer, but this seems a bit
> harder to implement.
Whoa. This rings a lot of alarm bells, very loudly. It seems you intend to
int
I'm using git am to apply patches, and I like the ability
to add arbitrary trailers instead of the standard Signed-off-by
one.
To this end, I have extended git am to call git interpret-trailers
internally. This way I can add arbitrary signatures.
For example, I have:
[trailer "t"]
key = T
it's sometimes useful to be able to pass output message of
git-mailinfo through git-interpret-trailers,
but that creates problems since that does not
include the subject and an empty line after that,
making interpret-trailers add an empty line.
Add a flag to bypass adding the blank line.
Signed-o
Reverts can typically be treated like squash. Eliminating both the
original commit and the revert would be even nicer, but this seems a bit
harder to implement.
Signed-off-by: Michael S. Tsirkin
---
git-rebase--interactive.sh | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --
Dearest One,
Good day!
I am interested in establishing and operating a very viable business as a
means of investment abroad with the Sum of US $ 9,500,000.00 I inherited
from my Father which he deposited in Bahamas.
My preference is any good profit yielding businesses you will suggest. My
n
Hi,
On Thu, 7 Apr 2016, Johannes Sixt wrote:
> Am 07.04.2016 um 00:11 schrieb David Turner:
> > +static void share_index(struct index_state *istate, struct shm *is)
> > +{
> > + void *new_mmap;
> > + if (istate->mmap_size <= 20 ||
> > + hashcmp(istate->sha1,
> > + (unsigne
Добрый день!
Имеются ли у Вас должники в Москве? К примеру это могут быть контрагенты,
которые долго тянут с оплатой счета.
Я профессионально занимаюсь взысканием любых долгов для организаций в Москве.
Если Вы столкнулись с ситуацией - долгой неуплаты счетов Вашими заказчиками - я
хотела бы пр
On Thu, Apr 07, 2016 at 12:42:19AM -0400, Jeff King wrote:
> On Wed, Apr 06, 2016 at 06:15:03PM +0100, Adam Dinwoodie wrote:
> > `git commit --amend -m ''` seems to be an unambiguous request to blank a
> > commit message, but it actually leaves the commit message as-is. That's
> > the case regardl
Hi,
you dropped the Cc: list. So most likely Cameron won't get your mail nor
any response to your mail.
On Thu, 7 Apr 2016, daurnimator wrote:
> Cameron Currie cameroncurrie.net> writes:
> > This is helpful for folks with commit.gpgsign = true in their .gitconfig.
>
> > https://github.com/git/
98 matches
Mail list logo
