Jeff King p...@peff.net writes:
First off, I agree that verify-tag is probably not the right place.
There _is_ no tag object to verify anymore (the only reason it is a tag
at all is that the signature came out of what once was a tag).
Yes, if we imagine that the header were called mergesig,
David Turner dtur...@twopensource.com writes:
When git checkout checks out a branch, create or update the
cache-tree so that subsequent operations are faster.
Signed-off-by: David Turner dtur...@twitter.com
---
builtin/checkout.c| 4
cache-tree.c | 22
Christian Couder christian.cou...@gmail.com writes:
Now, after having read the recent thread about git verify-commit, I
understand
that you also want me to drop the signature of a tag that was merged, because
such signatures are added to the commit message.
Huh? I am not sure if I follow.
if you move two identical {e.g.: empty} files to two new locations in a
single commit, the move detection picks them {seemingly?} arbitrarily.
it should use a statistical algorithm to compare the filenames and pick
a likely match.
my apologies in advance if this isnt the right venue or is
I sometimes pull things in from unrelated repositories to rebase or
cherry-pick items from a different line of development. I've done this
to bring isolated features into a project in their own feature
branches with their full development histories, and also to extract
lines of development out to
Christian Couder chrisc...@tuxfamily.org writes:
While I agree with Michael on the other thread that we should limit
the syntax and start with ':' only, if you really want to allow
random syntax like Bug #12345 and Acked-by= Peff, for which you
have demonstrations in the tests in the other
Usually will do
$ git push repo local_branch:destination_branch
repo - could be internal and public remote repo.
Any command or modified git push will do a push for internal and public repo's
Let me know If I'm unclear.
thanks!
--
Jagan.
--
To unsubscribe from this list: send the line
On Sun, Jun 29, 2014 at 11:40:40PM -0700, Gary Fixler wrote:
I sometimes pull things in from unrelated repositories to rebase or
cherry-pick items from a different line of development. I've done this
to bring isolated features into a project in their own feature
branches with their full
I've been having trouble sending my Git-generated patches to the tz
mailing list. Patches containing UTF-8 text are garbled, e.g., if you
visit http://mm.icann.org/pipermail/tz/2014-June/021086.html you'll
see Ãœrümqi where the patch actually had Ürümqi.
I've tracked this down to the fact
I just made a new test repo, added and fetched two unrelated repos,
and then did the log view (all/graph/decorate/oneline), and tacked on
--boundary, but saw no change. The root commits looked the same.
-g
On Mon, Jun 30, 2014 at 1:08 AM, John Keeping j...@keeping.me.uk wrote:
On Sun, Jun 29,
On Mon, Jun 30, 2014 at 8:37 AM, Junio C Hamano gits...@pobox.com wrote:
Christian Couder christian.cou...@gmail.com writes:
Now, after having read the recent thread about git verify-commit, I
understand
that you also want me to drop the signature of a tag that was merged, because
such
Christian Couder wrote:
+
+
+* Configure a 'sign' trailer with a command to automatically add a
+ 'Signed-off-by: ' with the author information only if there is no
+ 'Signed-off-by: ' already, and show how it works:
++
+
+$ git config trailer.sign.key Signed-off-by:
They don't. The conflicts are preserved into the virtual ancestor. The
user only sees the final conflicts during merging of A and B with
virtual X3 as the common ancestor.
Ah, now I understand. When I merge X1 and X2 into the virtual X3
I should not stop if this is not doable without conflict
Linus Torvalds wrote:
On Fri, Jun 27, 2014 at 10:48 AM, Junio C Hamano gits...@pobox.com wrote:
Even though the original question mentioned delta discovery, I
think what was being asked is not delta in the Git sense (which
your answer is about) but is can we diff two long sequences of text
On Sun, Jun 29, 2014 at 07:43:17AM +0200, René Scharfe wrote:
Instead of using strbuf to create a message string in case a path is
too long for our fixed-size buffer, replace that buffer with a strbuf
and thus get rid of the limitation.
Yay. Safer, and the end result is much more readable.
Am 29.06.2014 13:01, schrieb Eric Sunshine:
On Thu, Jun 26, 2014 at 4:19 AM, Tanay Abhra tanay...@gmail.com wrote:
On 6/25/2014 1:24 PM, Eric Sunshine wrote:
On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra tanay...@gmail.com wrote:
Use git_config_get_string instead of git_config to take advantage
On Sun, Jun 29, 2014 at 07:56:25AM +0200, René Scharfe wrote:
Avoid overrunning the existing pack name (p-pack_name, a C string) in
the case that the new path is longer by using strncmp instead of memcmp
for comparing. While at it, replace the magic constant 4 with a
strlen call to document
On Mon, Jun 30, 2014 at 8:43 PM, Jeff King p...@peff.net wrote:
diff --git a/sha1_file.c b/sha1_file.c
index 394fa45..8adab14 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1207,7 +1207,8 @@ static void prepare_packed_git_one(char *objdir, int
local)
if
On Mon, Jun 30, 2014 at 08:59:53PM +0700, Duy Nguyen wrote:
On Mon, Jun 30, 2014 at 8:43 PM, Jeff King p...@peff.net wrote:
diff --git a/sha1_file.c b/sha1_file.c
index 394fa45..8adab14 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1207,7 +1207,8 @@ static void
On Mon, Jun 30, 2014 at 9:34 AM, Karsten Blees karsten.bl...@gmail.com wrote:
Am 29.06.2014 13:01, schrieb Eric Sunshine:
On Thu, Jun 26, 2014 at 4:19 AM, Tanay Abhra tanay...@gmail.com wrote:
On 6/25/2014 1:24 PM, Eric Sunshine wrote:
On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra
On 6/30/2014 7:04 PM, Karsten Blees wrote:
Am 29.06.2014 13:01, schrieb Eric Sunshine:
On Thu, Jun 26, 2014 at 4:19 AM, Tanay Abhra tanay...@gmail.com wrote:
On 6/25/2014 1:24 PM, Eric Sunshine wrote:
On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra tanay...@gmail.com wrote:
Use
Am 30.06.2014 16:32, schrieb Eric Sunshine:
On Mon, Jun 30, 2014 at 9:34 AM, Karsten Blees karsten.bl...@gmail.com
wrote:
Am 29.06.2014 13:01, schrieb Eric Sunshine:
On Thu, Jun 26, 2014 at 4:19 AM, Tanay Abhra tanay...@gmail.com wrote:
On 6/25/2014 1:24 PM, Eric Sunshine wrote:
On Mon, Jun
Hi Max,
On Sun, 29 Jun 2014, Max Kirillov wrote:
diff --git a/xdiff/xmerge.c b/xdiff/xmerge.c
index 9e13b25..625198e 100644
--- a/xdiff/xmerge.c
+++ b/xdiff/xmerge.c
@@ -245,11 +245,11 @@ static int xdl_fill_merge_buffer(xdfenv_t *xe1, const
char *name1,
My name is Kong Hui from Hong Kong, I want you to be my partner in a
business project.
If Interested Contact me back via my email address.
Thank you,
Mr. Kong Hui.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
Am 30.06.2014 16:39, schrieb Tanay Abhra:
On 6/30/2014 7:04 PM, Karsten Blees wrote:
Am 29.06.2014 13:01, schrieb Eric Sunshine:
On Thu, Jun 26, 2014 at 4:19 AM, Tanay Abhra tanay...@gmail.com wrote:
On 6/25/2014 1:24 PM, Eric Sunshine wrote:
On Mon, Jun 23, 2014 at 6:41 AM, Tanay Abhra
On 6/30/2014 9:26 PM, Karsten Blees wrote:
Am 30.06.2014 16:39, schrieb Tanay Abhra:
On 6/30/2014 7:04 PM, Karsten Blees wrote:
Am 29.06.2014 13:01, schrieb Eric Sunshine:
On Thu, Jun 26, 2014 at 4:19 AM, Tanay Abhra tanay...@gmail.com wrote:
On 6/25/2014 1:24 PM, Eric Sunshine wrote:
On
Am 30.06.2014 15:43, schrieb Jeff King:
On Sun, Jun 29, 2014 at 07:56:25AM +0200, René Scharfe wrote:
Avoid overrunning the existing pack name (p-pack_name, a C string) in
the case that the new path is longer by using strncmp instead of memcmp
for comparing. While at it, replace the magic
Am 30.06.2014 16:22, schrieb Jeff King:
On Mon, Jun 30, 2014 at 08:59:53PM +0700, Duy Nguyen wrote:
On Mon, Jun 30, 2014 at 8:43 PM, Jeff King p...@peff.net wrote:
diff --git a/sha1_file.c b/sha1_file.c
index 394fa45..8adab14 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1207,7 +1207,8 @@
On Mon, Jun 30, 2014 at 06:43:35PM +0200, René Scharfe wrote:
Am 30.06.2014 16:22, schrieb Jeff King:
On Mon, Jun 30, 2014 at 08:59:53PM +0700, Duy Nguyen wrote:
On Mon, Jun 30, 2014 at 8:43 PM, Jeff King p...@peff.net wrote:
diff --git a/sha1_file.c b/sha1_file.c
index 394fa45..8adab14
On Mon, Jun 30, 2014 at 06:35:50PM +0200, René Scharfe wrote:
It's probably not a big deal, as we don't expect random
junk in the pack directory, but I wonder if it would be better to be
explicit, like:
snip
Here's a simpler approach:
I agree that solves the problem. However, I'm
From: René Scharfe l@web.de
Instead of using strbuf to create a message string in case a path is
too long for our fixed-size buffer, replace that buffer with a strbuf
and thus get rid of the limitation.
Helped-by: Duy Nguyen pclo...@gmail.com
Signed-off-by: Rene Scharfe l@web.de
Here's a series to do for ends_with what the recent skip_prefix series
did for starts_with. Namely: drop some magic numbers and repeated string
literals, and hopefully make things more readable.
The first patch is René's patch 1/2, with the leak fix from Duy and typo
fixes in the commit message
The ends_with function is essentially a simplified version
of strip_suffix, in which we throw away the stripped length.
Implementing it as an inline on top of strip_suffix has two
advantages:
1. We save a bit of duplicated code.
2. The suffix is typically a string literal, and we call
These two are almost the same function, with the exception
that has_extension only matches if there is content before
the suffix. So ends_with(.exe, .exe) is true, but
has_extension would not be.
This distinction does not matter to any of the callers,
though, and we can just replace uses of
Many callers of ends_with want to not only find out whether
a string has a suffix, but want to also strip it off. Doing
that separately has two minor problems:
1. We often run over the string twice (once to find
the suffix, and then once more to find its length to
subtract the suffix
When stripping a suffix like:
if (ends_with(str, foo))
buf = xmemdupz(str, strlen(str) - 3);
we can instead use strip_suffix to avoid the constant 3,
which must match the literal foo (we sometimes use
strlen(foo) instead, but that means we are repeating
ourselves). The example above
We also switch to using strbufs, which lets us avoid the
potentially dangerous combination of a manual malloc
followed by a strcpy.
Signed-off-by: Jeff King p...@peff.net
---
builtin/index-pack.c | 29 ++---
1 file changed, 14 insertions(+), 15 deletions(-)
diff --git
You can almost get away with just calling strip_suffix_mem
on a strbuf's buf and len fields. But we also need to move
the NUL-terminator to satisfy strbuf's invariants. Let's
provide a convenience wrapper that handles this.
Signed-off-by: Jeff King p...@peff.net
---
I called strbuf_setlen here
In this code, we try to convert both foo.idx and foo
into foo.pack. By stripping the suffix, we can avoid a
confusing use of strbuf_splice, and make it clear that both
cases are adding .pack to the end.
Signed-off-by: Jeff King p...@peff.net
---
builtin/verify-pack.c | 7 +++
1 file changed,
When we are reloading the list of packs, we check whether a
particular pack has been loaded. This is slightly tricky,
because we load packs based on the presence of their .idx
files, but record the name of the matching .pack file.
Therefore we want to compare their bases.
The existing code
On Sun, Jun 29, 2014 at 03:41:37AM -0400, Eric Sunshine wrote:
+static inline void bitset_set(unsigned char *bits, int n)
+{
+ bits[n / CHAR_BIT] |= 1 (n % CHAR_BIT);
+}
Is it intentional or an oversight that there is no way to clear a bit
in the set?
Intentional in the sense
On Mon, Jun 30, 2014 at 02:03:25AM -0700, Paul Eggert wrote:
I've been having trouble sending my Git-generated patches to the tz mailing
list. Patches containing UTF-8 text are garbled, e.g., if you visit
http://mm.icann.org/pipermail/tz/2014-June/021086.html you'll see
Ürümqi where the
My name is Kong Hui from Hong Kong, I want you to be my partner in a
business project.
If Interested Contact me back via my email address.
Thank you,
Mr. Kong Hui.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More
Karsten Blees karsten.bl...@gmail.com writes:
Which may not be too harmful in some cases, but if a user changes:
gc.pruneexpire=4.weeks.ago
to
gc.pruneexpire=4.monhts.ago
(note the typo), the next git-gc will warn the user and then happily throw
away data that the user intended to
It looks like the gpg output is not parsed to prefix the correct number of
spaces. What interests me the most is the folowing line is also wrong.
$ git log --graph
* commit 258e0a237cb69aaa587b0a4fb528bb0316b1b776
|\ Merge: 727c355 1ca13ed
| | Author: Jason Pyeron jpye...@pdinc.us
| | Date:
David Turner dtur...@twopensource.com writes:
During the commit process, the cache-tree is updated. We need to write
this updated cache-tree so that it's ready for subsequent commands.
Add test code which demonstrates that git commit now writes the cache
tree. Also demonstrate that
Duy Nguyen pclo...@gmail.com writes:
I wonder if we should do this in !opts-force code path only. In the
opts-force code path we could use prime_cache_tree() (like
read-tree), which is supposedly faster...
Nobody sane should be constantly running checkout -f, so even if
priming from existing
Torsten Bögershausen tbo...@web.de writes:
Historically there are 3 different parameters controlling how line endings
are handled by Git:
- core.autocrlf
- core.eol
- the text attribute in .gitattributes
There are different types of content:
- (1) Files with only LF
- (2) Files with only
Jeff King wrote:
How do you send the mails after they come out of format-patch?
I run a shell command like this (on Solaris 10):
/usr/lib/sendmail -ONoRecipientAction=add-to t...@iana.org
0001-whatever.patch
(The NoRecipientAction option pacifies the IANA MTA.)
This is an old machine not
From: Charles Bailey cbaile...@bloomberg.net
When multiple parents of a merge commit get mapped to the same commit,
filter-branch used to pass all instances of the parent commit to the
parent and commit filters and to git commit-tree or
git_commit_non_empty_tree.
This can often happen when
On Mon, Jun 30, 2014 at 5:48 AM, Christian Halstrick
christian.halstr...@gmail.com wrote:
They don't. The conflicts are preserved into the virtual ancestor. The
user only sees the final conflicts during merging of A and B with
virtual X3 as the common ancestor.
Ah, now I understand. When I
When git checkout checks out a branch, create or update the
cache-tree so that subsequent operations are faster.
Signed-off-by: David Turner dtur...@twitter.com
---
builtin/checkout.c| 8
cache-tree.c | 5 +++--
t/t0090-cache-tree.sh | 15 ++-
3 files changed,
Make test-dump-cache-tree more useful for testing. Do not treat known
invalid trees as errors (and do not produce non-zero exit code),
because we can fall back to the non-cache-tree codepath.
Signed-off-by: David Turner dtur...@twitter.com
---
t/t0090-cache-tree.sh | 28
During the commit process, the cache-tree is updated. We need to write
this updated cache-tree so that it's ready for subsequent commands.
Add test code which demonstrates that git commit now writes the cache
tree. Also demonstrate that cache-tree invalidation is correct.
Signed-off-by: David
On Mon, Jun 30, 2014 at 9:55 AM, Jeff King p...@peff.net wrote:
Here's a series to do for ends_with what the recent skip_prefix series
did for starts_with. Namely: drop some magic numbers and repeated string
literals, and hopefully make things more readable.
The first patch is René's patch
diff --git a/t/t0090-cache-tree.sh b/t/t0090-cache-tree.sh
index 6c33e28..7c60675 100755
--- a/t/t0090-cache-tree.sh
+++ b/t/t0090-cache-tree.sh
@@ -85,9 +85,22 @@ test_expect_success 'reset --hard without index gives
cache-tree' '
test_shallow_cache_tree
'
-test_expect_failure
[]
diff --git a/t/t0090-cache-tree.sh b/t/t0090-cache-tree.sh
index 5383258..d50acb8 100755
--- a/t/t0090-cache-tree.sh
+++ b/t/t0090-cache-tree.sh
@@ -16,8 +16,31 @@ cmp_cache_tree () {
# We don't bother with actually checking the SHA1:
# test-dump-cache-tree already verifies that all
I wonder if it would be enough to do:
1. Always add a content-type header, even if the commit is utf-8 and
contains only ascii characters. This _shouldn't_ hurt anything,
though I suppose it would if you have latin1 (for example) commit
messages and did not correctly set the
On Mon, Jun 30, 2014 at 8:13 PM, David Turner dtur...@twopensource.com wrote:
Make test-dump-cache-tree more useful for testing. Do not treat known
invalid trees as errors (and do not produce non-zero exit code),
because we can fall back to the non-cache-tree codepath.
Signed-off-by: David
Am 7/1/2014 6:26, schrieb Torsten Bögershausen:
And as test -n tests for a non-zero string,
could we write like this (and drop the local ?)?
if test -n $1
then
dir=$1/
else
dir=
fi
These six lines can be written as
dir=$1${1:+/}
and 'local'
60 matches
Mail list logo
