Thank-you all for replying,
It's just as Jason suggests - Genbank, FASTA & EMBL are more or less
the defacto standards, I suspect FASTA will be phased out because (to
my knowledge) it does not support gene annotation, nevertheless, they
are all text based.
These formats usually insert linebreaks
Karsten Blees writes:
> I still don't like that the invalidation is done in git_config_set, though, as
> this is also used to write completely unrelated files.
I don't get it. It is used to write the config files. Yes, we trigger a
complete reload instead of just changing this particular value i
On 06/27/2014 07:59 PM, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Michael Haggerty writes:
>>
>>> When reading a symbolic ref via resolve_gitlink_ref_recursive(), check
>>> that the reference name that is pointed at is formatted correctly,
>>> using the same check as resolve_ref_unsafe
This commit adds a mention to the '--subject-prefix' option in
git-send-email's documentation. This option is already described in
git-format-patch's docs (because it belongs to this command, actually),
but it is very useful when you are submitting patches using
git-send-email too, for obvious rea
Am 27.06.2014 21:19, schrieb Matthieu Moy:
>
> The reason for which setting any config value invalidates the cache is
> that it is _much_ simpler to implement. Less complexity, less
> corner-cases, less bugs.
>
I think I see what you mean. E.g. in cmd_clone we have:
write_config(&option_confi
On Fri, Jun 27, 2014 at 04:13:22PM +0200, Michael J Gruber wrote:
> This is v3 rebased on current next (the %G works by Jeff & Junio).
Aside from the minor test issues Junio pointed out, I think this version
looks OK.
> For a general command which allows different verification policies,
> I'm st
On Fri, Jun 27, 2014 at 12:07:35PM -0700, Junio C Hamano wrote:
> > - Should we do this now or go for generic "git verify" right away?
>
> I do not think we are ready to do "git verify" yet.
If there is one thing that this discussion have convinced me of, it is
this. :)
-Peff
--
To unsubscribe
On Fri, Jun 27, 2014 at 03:18:36PM +0200, Michael J Gruber wrote:
> A wrong '}' made our code record the results of mergetag signature
> verification incorrectly.
>
> Fix it.
I think this is the right thing to do, but we went from:
if (...)
if (...) {
if (...)
> -Original Message-
> From: Jason Pyeron
> Sent: Friday, June 27, 2014 18:39
>
> > -Original Message-
> > From: Phil Hord [mailto:phil.h...@gmail.com]
> > Sent: Friday, June 27, 2014 17:46
> > To: Jason Pyeron
> > Cc: git
> > Subject: Re: Trouble merging renamed but identical fi
On Fri, Jun 27, 2014 at 2:30 PM, Ronnie Sahlberg wrote:
> List,
>
> One of my ref transaction aims is to make define a stable public API
> for accessing refs.
> Once this is done I want to make it possible to replace the current
> .git/refs/* model with a
> different type of backend.
> In my case
On Fri, Jun 27, 2014 at 11:36:47AM -0700, Junio C Hamano wrote:
> Michael J Gruber writes:
>
> > A merge commit with embedded signed tag it is, then.
> >
> > The commit could carry it's own commit signature, couldn't it?
>
> Yes, an integrator can choose to sign a merge he creates, merging
> th
When git checkout checks out a branch, create or update the
cache-tree so that subsequent operations are faster.
Signed-off-by: David Turner
---
builtin/checkout.c| 4
cache-tree.c | 22 --
cache-tree.h | 1 +
t/t0090-cache-tree.sh | 15 ++
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 T
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
---
t/t0090-cache-tree.sh | 28 +---
test-dump-cac
> -Original Message-
> From: Phil Hord [mailto:phil.h...@gmail.com]
> Sent: Friday, June 27, 2014 17:46
> To: Jason Pyeron
> Cc: git
> Subject: Re: Trouble merging renamed but identical files -
> CONFLICT (rename/rename)
>
> On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron
> wrote:
> > Th
Junio C Hamano writes:
> Felix Eckhofer writes:
>
>> This seems to have been caused by 3361a548db. After reverting this
>> commit, using --date-order appears to work again.
>
> Hmph, unfortunate.
>
> 3361a548 (Allow git-filter-branch to process large repositories with
> lots of branches., 2013-0
On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron wrote:
> There are two identical files from the same original parent, but both were
> renamed in their own branches. One branch moved the file to a new folder, the
> other renamed the file in the same folder.
You have not stated what you think the iss
List,
One of my ref transaction aims is to make define a stable public API
for accessing refs.
Once this is done I want to make it possible to replace the current
.git/refs/* model with a
different type of backend.
In my case I want to add support to store all refs and reflogs in a TDB database
bu
Tanay Abhra writes:
> API functions:
>
> 1. int git_config_get_value(char *k, char **v): The most generic function,
> traverses
> the usual config functions for values. (internally uses the the_config_set
> struct)
This may also want to be accompanied by a set of more type-specific
API functio
There are two identical files from the same original parent, but both were
renamed in their own branches. One branch moved the file to a new folder, the
other renamed the file in the same folder.
Steps to reproduce the issue:
git init
git fetch https://github.com/pdinc-oss/CipherShed.git
git fetch
On 27. Juni 2014 21:32:30 MESZ, Junio C Hamano wrote:
>Michael J Gruber writes:
>
>> sed -e "s/seventh/7th forged/" raw >forged1 &&
>> git hash-object -w -t commit forged1 >forged1.commit &&
>> +! git verify-commit $(cat forged1.commit) &&
>
>test_must_fail git verify-commit ... &
On Fri, Jun 27, 2014 at 12:55 PM, Jason Pyeron wrote:
>
> The issue will be, if we talk about changes other than same length
> substitutions
> (e.g. Down's Syndrome where it has an insertion of code) would require one
> code
> per line for the diffs to work nicely.
Not my area of expertise, but
> -Original Message-
> From: Linus Torvalds
> Sent: Friday, June 27, 2014 15:39
>
> On Fri, Jun 27, 2014 at 10:48 AM, Junio C Hamano
> wrote:
> >
> > Even though the original question mentioned "delta discovery", I
> > think what was being asked is not "delta" in the Git sense (which
> >
On Fri, Jun 27, 2014 at 12:38 PM, Linus Torvalds
wrote:
>
> I think it might be possible to just specify a special diff algorithm
> (git already supports that, obviously), and just introduce a new "use
> binary diffs with a textual representation" model.
Another model would be to just insert newl
On Fri, Jun 27, 2014 at 10:48 AM, Junio C Hamano 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
> (that happens to consist of only
Michael J Gruber writes:
> sed -e "s/seventh/7th forged/" raw >forged1 &&
> git hash-object -w -t commit forged1 >forged1.commit &&
> + ! git verify-commit $(cat forged1.commit) &&
test_must_fail git verify-commit ... &&
> git show --pretty=short --show-signature $(cat for
Karsten Blees writes:
> Am 27.06.2014 13:55, schrieb Matthieu Moy:
>> Karsten Blees writes:
>>
>>> If for some reason a config string is accessed after config_cache_free()
>>> (which would be a bug), you won't notice if strings are xstrdup()ed (i.e.
>>> git
>>> will continue to run with some i
Michael J Gruber writes:
> This is v3 rebased on current next (the %G works by Jeff & Junio).
>
> Open questions:
>
> - Should one of git verify-{commit,tag} learn how to verify mergetags?
> (Probably no, it differs from both other cases.)
If we were to teach one of them, "verify-commit" as part
Am 26.06.2014 19:55, schrieb Junio C Hamano:
> Nguyễn Thái Ngọc Duy writes:
>
>> Too large files may lead to failure to allocate memory. If it happens
>> here, it could impact quite a few commands that involve
>> diff. Moreover, too large files are inefficient to compare anyway (and
>> most like
Michael J Gruber writes:
> ... or an extension ^{mergetag} to our machinery, defaulting to the
> tag object containing the mergetag for the 2nd parent, with an optional
> version ^{mergetag}?
One thing you should not forget is that with mergetag, the original
tag object is not even necessary to
Michael J Gruber writes:
> A merge commit with embedded signed tag it is, then.
>
> The commit could carry it's own commit signature, couldn't it?
Yes, an integrator can choose to sign a merge he creates, merging
the work by a contributor who gave him a pull-request for a tag
signed by the contr
Felix Eckhofer writes:
> When trying to rewrite svn revisions in commit messages to
> corresponding git commit hashes, I came across the following problem
> (using git 1.9.1):
>
> $ git filter-branch --msg-filter svnrev2git.py -- --date-order --all
> fatal: options not supported in --stdin mo
Add a hash table to cache all key-value pairs read from config files
(repo specific .git/config, user wide ~/.gitconfig and the global
/etc/gitconfig). Add two external functions `git_config_get_string` and
`git_config_get_string_multi` for querying in a non-callback manner from the
hash table.
Ad
Junio C Hamano writes:
> Michael Haggerty writes:
>
>> When reading a symbolic ref via resolve_gitlink_ref_recursive(), check
>> that the reference name that is pointed at is formatted correctly,
>> using the same check as resolve_ref_unsafe() uses for non-gitlink
>> references. This prevents b
Michael Haggerty writes:
> When reading a symbolic ref via resolve_gitlink_ref_recursive(), check
> that the reference name that is pointed at is formatted correctly,
> using the same check as resolve_ref_unsafe() uses for non-gitlink
> references. This prevents bogosity like
>
> ref: ../../
Shawn Pearce writes:
> Git does source code well. I don't know enough to judge if DNA/RNA
> sequence storage is similar enough to source code to benefit from
> things like `git log -p` showing deltas over time, or if some other
> algorithm would be more effective.
>
>> From my understanding the l
shig...@kanamei.co.jp writes:
> From: Kazumasa Shigeta
>
> The --include-untracked option acts like the normal "git stash save
> --include-untracked --all" but it does not change anything in working
> directory.
> It is inconvenient stash create does not have --include-untracked option
> howev
Paul Mackerras writes:
> On Thu, Jun 26, 2014 at 01:47:36PM -0700, Junio C Hamano wrote:
>>
>> In the meantime, I've fetched from you and merged up to your
>> master~2 aka 17f9836c (gitk: Show staged submodules regardless of
>> ignore config, 2014-04-08).
>
> I have applied and pushed out this p
Matthieu Moy writes:
>>> Isn't that a bit overkill? Why not just let the caller manage a hashmap
>>> directly instead of a config_set?
>>
>> Because I had an experience under my belt of a painful refactoring
>> of "the_index" which turned out to be not just a single array, I
>> simply suspect tha
Am 27.06.2014 13:55, schrieb Matthieu Moy:
> Karsten Blees writes:
>
>> If for some reason a config string is accessed after config_cache_free()
>> (which would be a bug), you won't notice if strings are xstrdup()ed (i.e. git
>> will continue to run with some invalid configuration). This is IMO m
Hey.
When trying to rewrite svn revisions in commit messages to corresponding
git commit hashes, I came across the following problem (using git
1.9.1):
$ git filter-branch --msg-filter svnrev2git.py -- --date-order --all
fatal: options not supported in --stdin mode
Could not get the com
On Fri, Jun 27, 2014 at 1:45 AM, Jarrad Hope wrote:
> As a software developer I've used git for years and have found it the
> perfect solution for source control.
>
> Lately I have found myself using git in a unique use-case - modifying
> DNA/RNA sequences and storing them in git, which are essent
On Thu, Jun 26, 2014 at 10:50 PM, Christian Halstrick
wrote:
> Imagine git does a recursive merge between A and B and finds multiple
> common ancestors X1,X2 for these commits.
> - Does git try to create an implicit/temporary common ancestor X3 by
> merging X1 and X2?
Yes this is the point of the
In contrast to tag signatures, commit signatures are put into the
header, that is between the other header parts and commit messages.
Provide access to the commit content sans the signature, which is the
payload that is actually signed. Commit signature verification does the
parsing anyways, and c
Commit signatures can be verified using "git show -s --show-signature"
or the "%G?" pretty format and parsing the output, which is well suited
for user inspection, but not for scripting.
Provide a command "verify-commit" which is analogous to "verify-tag": It
returns 0 for good signatures and non-
The struct has been growing members whose malloced memory needs to be
freed. Do this with one helper function so that no malloced memory shall
be left unfreed.
Signed-off-by: Michael J Gruber
---
builtin/merge.c | 5 +
gpg-interface.c | 12
gpg-interface.h | 1 +
pretty.c
This is v3 rebased on current next (the %G works by Jeff & Junio).
Open questions:
- Should one of git verify-{commit,tag} learn how to verify mergetags?
(Probably no, it differs from both other cases.)
- Should we do this now or go for generic "git verify" right away?
That depends on whether si
This mixes the "git verify-commit" tests in with the "git show
--show-signature" tests, to keep the tests more readable.
The tests already mix in the "call show" tests with the "verify" tests.
So in case of a test beakage, a '-v' run would be needed to reveal the
exact point of breakage anyway.
A
Michael J Gruber venit, vidit, dixit 27.06.2014 14:49:
> Michael J Gruber venit, vidit, dixit 27.06.2014 14:31:
>> Jeff King venit, vidit, dixit 16.06.2014 22:39:
>>> On Mon, Jun 16, 2014 at 01:34:20PM -0700, Junio C Hamano wrote:
>>>
> Your middle example above did make me think of one other t
A wrong '}' made our code record the results of mergetag signature
verification incorrectly.
Fix it.
Signed-off-by: Michael J Gruber
---
This is the "color fix"...
log-tree.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/log-tree.c b/log-tree.c
index 10e6844..fdea358
Michael J Gruber venit, vidit, dixit 27.06.2014 14:49:
> Michael J Gruber venit, vidit, dixit 27.06.2014 14:31:
>> Jeff King venit, vidit, dixit 16.06.2014 22:39:
>>> On Mon, Jun 16, 2014 at 01:34:20PM -0700, Junio C Hamano wrote:
>>>
> Your middle example above did make me think of one other t
Michael J Gruber venit, vidit, dixit 27.06.2014 14:31:
> Jeff King venit, vidit, dixit 16.06.2014 22:39:
>> On Mon, Jun 16, 2014 at 01:34:20PM -0700, Junio C Hamano wrote:
>>
Your middle example above did make me think of one other thing, though.
As you noted, we actually have _three_ sig
Jeff King venit, vidit, dixit 16.06.2014 22:39:
> On Mon, Jun 16, 2014 at 01:34:20PM -0700, Junio C Hamano wrote:
>
>>> Your middle example above did make me think of one other thing, though.
>>> As you noted, we actually have _three_ signature types:
>>>
>>> 1. signed tags
>>>
>>> 2. signed c
Use the ARRAY_SIZE macro to get the number
of elements in an array.
Signed-off-by: Elia Pinto
---
submodule.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/submodule.c b/submodule.c
index b80ecac..48e3b44 100644
--- a/submodule.c
+++ b/submodule.c
@@ -965,7 +965,7 @@ sta
Karsten Blees writes:
> If for some reason a config string is accessed after config_cache_free()
> (which would be a bug), you won't notice if strings are xstrdup()ed (i.e. git
> will continue to run with some invalid configuration). This is IMO much worse
> than failing with segfault.
I disagre
When reading a symbolic ref via resolve_gitlink_ref_recursive(), check
that the reference name that is pointed at is formatted correctly,
using the same check as resolve_ref_unsafe() uses for non-gitlink
references. This prevents bogosity like
ref: ../../other/file
from causing problems.
Si
- Ursprungligt meddelande -
> Från: "Alan Franzoni"
> Till: "Robin Rosenberg"
> Kopia: git@vger.kernel.org, "Alan Franzoni" ,
> sch...@linux-m68k.org
> Skickat: fredag, 27 jun 2014 10:24:23
> Ämne: Re: [PATCH] Fix: wrong offset for CET timezone
>
> On Fri, Jun 27, 2014 at 12:08 AM, Ro
Hello,
As a software developer I've used git for years and have found it the
perfect solution for source control.
Lately I have found myself using git in a unique use-case - modifying
DNA/RNA sequences and storing them in git, which are essentially
software/source code for cells/life. For Bacteri
On Fri, Jun 27, 2014 at 12:08 AM, Robin Rosenberg
wrote:
> 1 hour in winter and 2 in summer, although some standards seem to say
> that summer time is really called CEST, computers apply DST to CET in summer.
>
> $ TZ=UTC date
> Tor 26 Jun 2014 22:08:01 UTC
>
> $ TZ=CET date
> Fre 27 Jun 2014 00:0
Am 26.06.2014 23:21, schrieb Junio C Hamano:
> Karsten Blees writes:
>
>>> Because I had an experience under my belt of a painful refactoring
>>> of "the_index" which turned out to be not just a single array, I
>>> simply suspect that the final data structure to represent a "set of
>>> config-lik
Junio C Hamano writes:
> Matthieu Moy writes:
>
>> Junio C Hamano writes:
>>
>>> When the submodule script that uses "git config -f .gitmodules" is
>>> converted into C, if the updated config API is ready, it may be able
>>> to do something like these in a single program:
>>>
>>> const char
From: Kazumasa Shigeta
The --include-untracked option acts like the normal "git stash save
--include-untracked --all" but it does not change anything in working directory.
It is inconvenient stash create does not have --include-untracked option
however stash save has --include-untracked option.
Robin Rosenberg writes:
> $ TZ=CET date
> Fre 27 Jun 2014 00:08:05 CEST
That only works because CET is a special zone name (POSIX time zones
require at least a number to denote the standard offset), similar to
Europe/Berlin but without the history.
Andreas.
--
Andreas Schwab, sch...@linux-m68
Junio C Hamano writes:
> But then in order to learn what tags the remote has, you need to
> talk to the remote and it won't be "complately a local" operation
> anymore, no?
Just like for every other remote ref. If you need to know the
ultimative truth the only way is to ask the remote. Your lo
On Wed, Jun 18, 2014 at 07:53:14PM -0700, David Aguilar wrote:
> 105b5d3fbb1c00bb0aeaf9d3e0fbe26a7b1993fc introduced a dependency
> on mkdtemp, which is not available on Windows.
>
> Use the original temporary directory behavior when mkdtemp fails.
> This makes the code use mkdtemp when available
On Thu, Jun 26, 2014 at 01:47:36PM -0700, Junio C Hamano wrote:
> David Aguilar writes:
>
> > 105b5d3fbb1c00bb0aeaf9d3e0fbe26a7b1993fc introduced a dependency
> > on mkdtemp, which is not available on Windows.
> >
> > Use the original temporary directory behavior when mkdtemp fails.
> > This make
66 matches
Mail list logo
