Allow extracting To/Cc addresses from cover letter.
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Is there interest in this kind of feature?
I find it easier than adding --cc to send-email command line.
git-send-email.perl | 16
1 file changed, 16 insertions(+)
diff
Change -f into `-f`, -x into `-x`, etc.
Signed-off-by: Włodzimierz Gajda gaj...@gajdaw.pl
---
Documentation/git-clean.txt | 20 ++--
1 file changed, 10 insertions(+), 10 deletions(-)
diff --git a/Documentation/git-clean.txt b/Documentation/git-clean.txt
index 8997922..b8d3486
Hi folks,
sometimes when I send a patch, I want to reply it to an existing e-mail,
using pretty much the same recipient list. Currently, I have to:
- copy-paste the message id for --in-reply-to header
- copy one address for --to
- copy the other addresses for the --cc's
Since I can't just
On Wed, Oct 02, 2013 at 10:25:25AM +0200, Matthijs Kooijman wrote:
sometimes when I send a patch, I want to reply it to an existing e-mail,
using pretty much the same recipient list. Currently, I have to:
- copy-paste the message id for --in-reply-to header
- copy one address for --to
-
checkpoint command causes fast-import to finish the current pack and
start a new one. If there are no (newly imported) objects in the pack
fast-import does nothing with the pack AND doesn't save out branches,
tags and marks.
Fix it by always saving out branches, tags and marks on a checkpoint.
On 2013-09-29 02.33, Duy Nguyen wrote:
On Sun, Sep 29, 2013 at 2:37 AM, Torsten Bögershausen tbo...@web.de wrote:
git clone /foo/bar:baz or git clone ../foo/bar:baz
are meant to clone from the local file system, and not to clone
from a remote server over git-over-ssh.
I don't think this is
Hi,
recently I did a merge where a complete repo shall be
merged into a specific directory of another repo. I
tried both the subtree merge strategy and the option
-Xsubtree=dir of recursive. I noticed that in both
cases somehow the history of single files were lost
during these merges (with
Ralf Thielow ralf.thie...@gmail.com writes:
Hi,
recently I did a merge where a complete repo shall be
merged into a specific directory of another repo. I
tried both the subtree merge strategy and the option
-Xsubtree=dir of recursive. I noticed that in both
cases somehow the history of
On Wed, Oct 2, 2013 at 9:42 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Ralf Thielow ralf.thie...@gmail.com writes:
Hi,
recently I did a merge where a complete repo shall be
merged into a specific directory of another repo. I
tried both the subtree merge strategy and the option
Ralf Thielow ralf.thie...@gmail.com writes:
Thanks for explanation.
I knew the history of the repo is there, but the history of single files
(and the ability to look at it)
There is no such thing as single file history in Git. Git knows about
the history of the project, and knows which files
On Wed, Oct 2, 2013 at 10:21 PM, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Ralf Thielow ralf.thie...@gmail.com writes:
Thanks for explanation.
I knew the history of the repo is there, but the history of single files
(and the ability to look at it)
There is no such thing as single
When the unset push.default warning message is displayed
this may be the first time many users encounter push.default.
Modified the warning message to explain in a compact
manner what push.default is and why it is being changed in
Git 2.0. Also provided additional information to help users
decide
Hi,
At last, I foundfollowing Makefile optimization suppression works fine in my
case.
CFLAGS = -g -O2 -fno-inline-small-functions -Wall
Following optimization option cause crash,
-finline-small-functions
// entry.c:237
int checkout_entry(struct cache_entry *ce,
const
On Thu, Oct 3, 2013 at 1:40 AM, Torsten Bögershausen tbo...@web.de wrote:
On 2013-09-29 02.33, Duy Nguyen wrote:
On Sun, Sep 29, 2013 at 2:37 AM, Torsten Bögershausen tbo...@web.de wrote:
git clone /foo/bar:baz or git clone ../foo/bar:baz
are meant to clone from the local file system, and not
On Thu, Oct 03, 2013 at 08:01:23AM +0700, Nguyen Thai Ngoc Duy wrote:
Sorry for the noise, I noticed it when I was trying to construct test cases.
What do we think about adding this at the end of t5505:
As usual more tests are usually better. But is t5505-remote.sh the
best place? That
The use case is
tar -xzf bigproject.tar.gz
cd bigproject
git init
git add .
# git grep or something
The first add will generate a bunch of loose objects. With --bulk, all
of them are forced into a single pack instead, less clutter on disk
and maybe faster object access.
This
16 matches
Mail list logo
