* Linus Torvalds torva...@linux-foundation.org wrote:
On Wed, Oct 24, 2012 at 12:25 AM, Thomas Gleixner t...@linutronix.de wrote:
It is spelled:
git notes add -m comment SHA1
Cool!
Don't use them for anything global.
Use them for local codeflow, but don't expect them to be
Am 10/24/2012 0:23, schrieb Jeff King:
For the fold-on-rebase idea, I'd think you would want something similar,
like setting rebase.foldNotes to foo to say refs/notes/foo contains
pseudo-headers that should be folded in like a signed-off-by.
If you are rebasing anyway, you can already use
Am 10/24/2012 0:35, schrieb Jeff King:
-test_expect_success 'non-match value' \
- 'test wow = $(git config --get nextsection.nonewline !for)'
+test_expect_success 'non-match value' '
+ test wow = $(git config --get nextsection.nonewline !for)
+'
Here's a case you forgot to update to
All looked sane. Thanks for a pleasant read!
-- Hannes
--
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 Wed, Oct 24, 2012 at 12:21 PM, Uri Moszkowicz u...@4refs.com wrote:
Continuing to work on improving clone times, using git gc
--aggressive has resulted in a large number of tags combining into a
single file but now I have a large number of files in the objects
directory - 131k for a ~2.7GB
On Wed, Oct 24, 2012 at 02:37:12AM -0400, Jeff King wrote:
Here's a case you forgot to update to test_cmp.
[...]
And while you are here, you might want to remove this extra space. ;)
Otherwise, looks fine.
Thanks, I'll fix up both.
Here's an updated version of patch 1 that I'm
On Wed, Oct 24, 2012 at 01:59:16PM +0700, Nguyen Thai Ngoc Duy wrote:
On Wed, Oct 24, 2012 at 12:21 PM, Uri Moszkowicz u...@4refs.com wrote:
Continuing to work on improving clone times, using git gc
--aggressive has resulted in a large number of tags combining into a
single file but now I
On Tue, Oct 23, 2012 at 05:00:21PM -0400, W. Trevor King wrote:
From: W. Trevor King wk...@tremily.us
Use -b branch instead of -b branch. This brings the usage
strings in line with other options, e.g. --reference repository.
Signed-off-by: W. Trevor King wk...@tremily.us
Thanks. Looks
I'll see if I can come up with a patch that cater for both use-cases.
I see that I forgot to Cc you; please see the patch series starting
with the Subject [RFC PATCH 0/2] Localize log output, which I posted
here yesterday.
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from
The git-send-email always use RFC2047 subject quoting for files
with broken encoding - non-ASCII files without Content-Transfer-Encoding,
even for ASCII subjects. Now for ASCII subjects the RFC2047 quoting will be
skipped.
Signed-off-by: Krzysztof Mazur krzys...@podlesie.net
---
Phil Hord ho...@cisco.com writes:
+ if (state-substate==WT_SUBSTATE_NOMINAL)
status_printf_ln(s, color,
_(The current patch is empty.));
This looks weird. First, spaces around == (here and below). Then, the
logic is unintuitive. The if suggests everything is
On Sun, Sep 23, 2012 at 04:10:31PM +0700, Nguyen Thai Ngoc Duy wrote:
+ else {
+ int sb_len = sb-len, offset;
+ switch (c-flush_type) {
+ case flush_left:
+ offset = padding - len;
+ break;
+ case
On Wed, Oct 24, 2012 at 10:03:35AM +0200, Krzysztof Mazur wrote:
The git-send-email always use RFC2047 subject quoting for files
with broken encoding - non-ASCII files without Content-Transfer-Encoding,
even for ASCII subjects. Now for ASCII subjects the RFC2047 quoting will be
skipped.
Since Junio is gone for a few weeks, I'll be doing my best to fill in.
My plan is to pick up topics from the list and keep development moving
on master and next. I'm not planning on cutting any releases, which
should be fine unless some emergency comes up which would require a
quick v1.8.0.1.
Mat Arge venit, vidit, dixit 22.10.2012 15:38:
Hy!
I would like to sign each commit with a X.509 certificate and a private key
stored on a PKCS#11 token. I assume that that should be possible somehow
using
a hook which calls openssl. Does somebody know a working implementation of
this?
With merge conflicts in the work-tree, diff's exit-code seems inconsistent. I
thought --quiet implied --exit-code
/others/foo$ git diff --quiet
/others/foo$ echo $?
1
/others/foo$ git diff --exit-code
diff --cc foo.txt
index f3dc283,bea67fd..000
--- a/foo.txt
+++ b/foo.txt
/others/foo$
On Tue, Oct 23, 2012 at 10:22:45PM +0100, Jeff King wrote:
On Tue, Oct 23, 2012 at 10:09:46PM +0100, Catalin Marinas wrote:
It is spelled:
git notes add -m comment SHA1
The resulting notes are stored in a separate revision-controlled branch
and can be pushed and pulled like
Angelo Borsotti angelo.borso...@gmail.com writes:
Hello,
the man page of git commit-tree SYNOPSIS is:
git commit-tree tree [(-p parent)...] changelog
git commit-tree [(-p parent)...] [(-m message)...] [(-F
file)...] tree
The second form is incorrect: the tree must be specified
On Sat, 20 Oct 2012 21:40:03 +0200
Herman van Rink r...@initfour.nl wrote:
On 10/19/2012 03:21 PM, Yann Dirson wrote:
As the examples in git-subtree.txt show, the synopsis in the same file
should
surely get a patch along the lines of:
-'git subtree' add -P prefix commit
+'git
Jeff King wrote:
On Tue, Oct 23, 2012 at 11:25:06PM +0200, Thomas Gleixner wrote:
The resulting notes are stored in a separate
revision-controlled branch
Which branch(es) is/are that ? What are the semantics of that?
[...]
Nice feature.
Can a later commit be eventually be made to
On Sun, Oct 21, 2012 at 11:02 PM, Sverre Rabbelier srabbel...@gmail.com wrote:
On Sun, Oct 21, 2012 at 10:49 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
From the original remote-hg.
You need git-remote-hg already in your path to run them.
I'm not proposing to include this patch
On Wed, Oct 24, 2012 at 04:46:36AM -0400, Jeff King wrote:
On Wed, Oct 24, 2012 at 10:03:35AM +0200, Krzysztof Mazur wrote:
The git-send-email always use RFC2047 subject quoting for files
with broken encoding - non-ASCII files without Content-Transfer-Encoding,
even for ASCII subjects.
It all goes to pack_refs() in write_remote_refs called from
update_remote_refs().
On Tue, Oct 23, 2012 at 11:29 PM, Nguyen Thai Ngoc Duy
pclo...@gmail.com wrote:
On Wed, Oct 24, 2012 at 1:30 AM, Uri Moszkowicz u...@4refs.com wrote:
I have a large repository which I ran git gc --aggressive on
Hi,
Joined late to the party :)
On Sun, Nov 6, 2011 at 12:23 AM, Sverre Rabbelier srabbel...@gmail.com wrote:
This happens only when the corresponding commits are not exported in
the current fast-export run. This can happen either when the relevant
commit is already marked, or when the commit
On Sun, Nov 6, 2011 at 12:23 AM, Sverre Rabbelier srabbel...@gmail.com wrote:
When a revision is specified on the commandline we explicitly output
a 'reset' command for it if it was not handled already. This allows
for example the remote-helper protocol to use fast-export to create
branches
Hi Felipe,
Felipe Contreras wrote:
This test is completely wrong.
1) Where are the marks file?
2) master..master shouldn't export anything
Why shouldn't master..master export anything? It means update the
master ref; we already have all commits up to and including master^0.
The underlying
On Mon, Oct 22, 2012 at 6:55 PM, W. Trevor King wk...@tremily.us wrote:
On a tangentially related note, it would be nice to set environment
variables for each of the settings in submodule.$name during a foreach
call. Then you could use
git submodule foreach 'git checkout $branch git pull'
Hi,
i am using a textconv filter to display .doc files as plain text.
It seems git gui does not use this textconv filter for displaying new
unstaged files
(other files? = _O)
It seems diff.tcl start_show_diff calls show_other_diff because of this.
This manually loads the file and does not care
On Wed, Oct 24, 2012 at 8:08 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi Felipe,
Felipe Contreras wrote:
This test is completely wrong.
1) Where are the marks file?
2) master..master shouldn't export anything
Why shouldn't master..master export anything? It means update the
master
Am 24.10.2012 00:02, schrieb Nahor:
On 2012-10-23 13:36, Jens Lehmann wrote:
Am 23.10.2012 21:16, schrieb Nahor:
Last issue, the branch that exists in your local repository may not
exist in someone else's repository, either because the branch is
purely local, or because it has a different
Felipe Contreras wrote:
Does it mean that? I don't think so, but let's assume that's the case.
We don't have all those commits; without the marks we have nothing. Or
what exactly do you mean by 'we'?
Not everyone uses marks.
Ciao,
Jonathan
--
To unsubscribe from this list: send the line
Yeah same here. Thanks for tackling this bug. Looking forward to using
the include mechanism for overriding user.email in future versions.
--
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
I still fail to see what adding that functionality to the submodule
command buys us (unless we also add code which really uses the branch
setting). What's wrong with doing a simple:
git config -f .gitmodules submodule.path.branch record_branch
on the command line when you want to use the
On Wed, Oct 24, 2012 at 07:10:36PM +0200, Krzysztof Mazur wrote:
- if ($broken_encoding{$t} !is_rfc2047_quoted($subject)) {
+ if ($broken_encoding{$t} !is_rfc2047_quoted($subject)
+ ($subject =~ /[^[:ascii:]]/)) {
Is that test sufficient? We would also need to
Hello.
I am trying to apply a patch made via {git diff somehash^ somehash
} before (same version of Git, same machine). I have no-prefix
enabled by default.
If I try to apply the patch with -p0, it fails.
If I go to a directory where all the changed files are (src/ below)
to simulate the
On Wed, Oct 24, 2012 at 03:25:30PM -0400, Jeff King wrote:
Right, but I was specifically worried about raw =?, which is only an
issue due to rfc2047 itself.
However, reading the patch again, we are already checking for that with
is_rfc2047_quoted. It might miss the case where we have =? but
For raw subjects rfc2047 quoting is needed not only for non-ASCII characters,
but also for any possible rfc2047 in it.
Signed-off-by: Krzysztof Mazur krzys...@podlesie.net
---
Oops, this ugly Subject was generated by git format-patch (both 1.8.0
and km/send-email-compose-encoding).
Hi,
I am doing some experimenting with git-mktag, and was looking into the
format it expects on input.
Should this sequence of commands work?
kalki:[~]% mkdir /tmp/gittest; cd /tmp/gittest
kalki:[/tmp/gittest]% git init
Initialized empty Git repository in /tmp/gittest/.git/
On Wed, Oct 24, 2012 at 4:39 PM, Anand Kumria akum...@acm.org wrote:
Hi,
I am doing some experimenting with git-mktag, and was looking into the
format it expects on input.
Should this sequence of commands work?
Yes, with a slight tweak...
kalki:[/tmp/gittest]% git tag -m tag-test tag-test
On Wed, Oct 24, 2012 at 09:15:32PM +0200, Jens Lehmann wrote:
I still fail to see what adding that functionality to the submodule
command buys us (unless we also add code which really uses the branch
setting). What's wrong with doing a simple:
git config -f .gitmodules
Ahh, unix time. Of course.
Thanks Brandon.
On 25 October 2012 01:18, Brandon Casey draf...@gmail.com wrote:
On Wed, Oct 24, 2012 at 4:39 PM, Anand Kumria akum...@acm.org wrote:
Hi,
I am doing some experimenting with git-mktag, and was looking into the
format it expects on input.
Should
On Mon, Oct 22, 2012 at 06:03:53PM -0400, Phil Hord wrote:
Some projects now use the 'branch' config value to record the tracking
branch for the submodule. Some ascribe different meaning to the
configuration if the value is given vs. undefined. For example, see
the Gerrit
On Wed, Oct 24, 2012 at 02:12:18PM -0400, Phil Hord wrote:
+ VAR_NAME=$(printf '%s'
$VAR_NAME | tr A-Z a-z | sed -e 's/^[^a-z]/_/' -e 's/[^a-z0-9]/_/g')
Is there a reason why you use printf instead of echo?
Also, this sort of name cleaning should probably
On Wed, Oct 24, 2012 at 8:51 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Now the sysadmin should copy
contrib/completion/git-completion.sh to
/usr/share/bash-completion/completions/git
and contrib/completion/git-prompt.sh to
/usr/share/git-core/contrib/?? (somewhere?)
On Oct 21, 2012, at 12:06 , Junio C Hamano gits...@pobox.com wrote:
This solves errors in some cases when syncing renamed files.
Can you be a bit more descriptive? What are errors in some case?
It might just be when files are renamed. I ran into this after months of using
it, and I'm
I seem to write these kinds of e-mails fairly regularly...
When running t9401-git-cvsserver-crlf:
expecting success:
check_status_options cvswork2 textfile.c
check_status_options cvswork2 binfile.bin -kb
check_status_options cvswork2 .gitattributes
check_status_options
On Wed, Oct 24, 2012 at 9:11 PM, Jonathan Nieder jrnie...@gmail.com wrote:
Felipe Contreras wrote:
Does it mean that? I don't think so, but let's assume that's the case.
We don't have all those commits; without the marks we have nothing. Or
what exactly do you mean by 'we'?
Not everyone
Felipe Contreras wrote:
Again, if you don't have marks, I don't see what you expect to be
exported with 'master..master', even with marks, I don't see what you
expect.
And that's fine. Unless you were trying to do some work and this lack
of understanding got in the way.
In that case, with a
Yes, I believe it's gerrit problem and will discuss there.
During first minutes of restarting gerrit, the pushing becomes quite
faster 13s instead.
2012/10/24 Shawn Pearce spea...@spearce.org:
On Mon, Oct 22, 2012 at 11:27 PM, Joey Jiao joey.jia...@gmail.com wrote:
It looks like the client is
On Oct 24, 2012, at 23:54, Brian Gernhardt br...@gernhardtsoftware.com wrote:
It works if I change \s to [[:space:]], but I don't know how portable that is.
As \s is shorthand for the POSIX character class [:space:], I'd say the latter
should be more portable: anything accepting the shorthand
On Wed, Oct 24, 2012 at 11:41 PM, Johannes Schindelin
johannes.schinde...@gmx.de wrote:
Hi,
On Wed, 24 Oct 2012, Felipe Contreras wrote:
2) master..master shouldn't export anything
The underlying issue -- as explained in the thread -- is when you want to
update master to a commit that
On Thu, Oct 25, 2012 at 6:27 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Felipe Contreras wrote:
Again, if you don't have marks, I don't see what you expect to be
exported with 'master..master', even with marks, I don't see what you
expect.
And that's fine. Unless you were trying to do
Felipe Contreras wrote:
I don't need help, I am helping you, I was asked to take a look at
this patch series. If you don't want my help, then by all means, keep
this series rotting, it has being doing so for the past year without
anybody complaining.
Ah, so _that_ (namely getting Sverre's
On Wed, Oct 24, 2012 at 10:28 PM, Jonathan Nieder jrnie...@gmail.com wrote:
The testcase is imho correct and does not need changing. So yes, I
don't want your help changing it. I don't suspect you will be using
git fast-export $(git rev-parse master)..master. It is safe and
good to add
On Thu, Oct 25, 2012 at 7:28 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Felipe Contreras wrote:
I don't need help, I am helping you, I was asked to take a look at
this patch series. If you don't want my help, then by all means, keep
this series rotting, it has being doing so for the past
On Thu, Oct 25, 2012 at 7:39 AM, Sverre Rabbelier srabbel...@gmail.com wrote:
On Wed, Oct 24, 2012 at 10:28 PM, Jonathan Nieder jrnie...@gmail.com wrote:
The testcase is imho correct and does not need changing. So yes, I
don't want your help changing it. I don't suspect you will be using
git
Felipe Contreras wrote:
All right, so I run this and get this:
% git fast-export master..master
reset refs/heads/master
from 8c7a786b6c8eae8eac91083cdc9a6e337bc133b0
As an user of fast-export, what do I do with that now?
You passed master.. on the command line, indicating that your
57 matches
Mail list logo
