This patch adds tests for "git replace -l --format=".
'short', 'medium' and 'full' are the only allowed values
for .
'short' is the same as with no --format option.
Tests for 'medium' and 'full' are the most needed.
Signed-off-by: Christian Couder
---
t/t6050-replace.sh | 37 ++
By default when listing replace refs, only the sha1 of the
replaced objects are shown.
In many cases, it is much nicer to be able to list all the
sha1 of the replaced objects along with the sha1 of the
replacment objects.
And in other cases it might be interesting to also show the
types of the re
Signed-off-by: Christian Couder
---
Documentation/git-replace.txt | 19 ++-
1 file changed, 18 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-replace.txt b/Documentation/git-replace.txt
index f373ab4..7a07828 100644
--- a/Documentation/git-replace.txt
+++ b/Documenta
When --batch is passed to git cat-file, the sha1_object_info_extended()
function is used to get information about the objects passed to
git cat-file.
Unfortunately sha1_object_info_extended() doesn't take care of
object replacement properly, so it will often fail with a
message like this:
$ echo
sha1_object_info_extended() should perform object replacement
if it is needed.
The simplest way to do that is to make it call
lookup_replace_object_extended().
And now its "unsigned flags" parameter is used as it is passed
to lookup_replace_object_extended().
Signed-off-by: Christian Couder
---
When checking to see if some objects are of the same type
and when displaying the type of objects, git replace uses
the sha1_object_info() function.
Unfortunately this function by default respects replace
refs, so instead of the type of a replaced object, it
gives the type of the replacement objec
This parameter is not used yet, but it will be used to tell
sha1_object_info_extended() if it should perform object
replacement or not.
Signed-off-by: Christian Couder
---
builtin/cat-file.c | 2 +-
cache.h| 2 +-
sha1_file.c| 6 +++---
streaming.c| 2 +-
4 files chan
Here is version 3 of a patch series to improve the way
sha1_object_info_extended() behaves when it is passed a
replaced object. The idea is to add a flags argument to it
in the same way as what has been done to read_sha1_file().
This patch series was inspired by a sub thread in this
discussion:
h
Currently, there is only one caller to lookup_replace_object()
that can benefit from passing it some flags, but we expect
that there could be more.
Signed-off-by: Christian Couder
---
cache.h | 6 ++
sha1_file.c | 3 +--
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/cach
The READ_SHA1_FILE_REPLACE flag is more related to using the
lookup_replace_object() function rather than the
read_sha1_file() function.
We also need such a flag to be used with sha1_object_info()
instead of read_sha1_file().
The name LOOKUP_REPLACE_OBJECT is therefore better for this
flag.
Sign
Since ecef (inline lookup_replace_object() calls,
May 15 2011) the read_replace_refs global variable is
checked twice, once in lookup_replace_object() and
once again in do_lookup_replace_object().
As do_lookup_replace_object() is called only from
lookup_replace_object(), we can remove the chec
On Tue, Dec 10, 2013 at 08:02:29PM +0100, Andreas Schwab wrote:
> Dominik Vogt writes:
>
> > The second best approach I could think of is to stamp files with the
> > timestamp of the last commit that touched that, but I guess that is
> > not a cheap operation either.
>
> I'm using this script fo
Observe:
% echo HEAD | git cat-file --batch=
fatal: object fde075cb72fc0773d8e8ca93d55a35d77bb6688b changed type!?
Without the =, it works fine; with a string that has both
"%(objecttype)" and "%(objectsize)", it's fine; but when you don't
include both, it complains about one of the values that
Jonathan Nieder wrote:
> Stefan Zager wrote:
>> This is probably a naive question, but: there are quite a lot of static
>> variables in the git code where it's really unnecessary. Is that just a
>> historical artifact, or is there some reason to prefer them?
>
> Sometimes it's for convenience.
S
Stefan Zager wrote:
> This is probably a naive question, but: there are quite a lot of static
> variables in the git code where it's really unnecessary. Is that just a
> historical artifact, or is there some reason to prefer them?
Sometimes it's for convenience. Other times it's to work around
On 10 December 2013 00:35, Dominik Vogt wrote:
> that sounds awfully expensive, and really out of the scope of an
> RCS. The second best approach I could think of is to stamp files
> with the timestamp of the last commit that touched that, but I
> guess that is not a cheap operation either.
You
My Dear Beloved in Christ,
My Message is attached, From Sister Aicha Ameld
MY MESSAGE IS ATTACHED, FROM SISTER AICHA AMELD,.doc
Description: MS-Word document
This is probably a naive question, but: there are quite a lot of static
variables in the git code where it's really unnecessary. Is that just a
historical artifact, or is there some reason to prefer them? I'm working
on a patch that will introduce threading, so naturally I'm on the lookout
for st
Duy Nguyen wrote:
> I wonder if we could promote multiple worktree from a hack to a
> supported feature. What I have in mind is when you "clone
> --separate-worktree" it would create a .git file that describes
> separate worktree:
>
> gitbasedir: /path/to/the/original/.git
> name: foo
>
> HEAD, in
Dominik Vogt wrote:
> How does git-new-workdir cope with
> rebasing (e.g. you have the same branch checked out in two working
> trees and "rebase -i" it in one of them)?
Generally you don't have the same branch checked out in two working
trees. I tend to use "git checkout
On Tue, Dec 10, 2013 at 09:54:06PM +0100, Winniehell wrote:
> There is a benchmark on the Git website [1]. Unfortunately it lacks (in
> my opinion substantial) information about what Git and what SVN version
> has been used. Can anyone give me that information? Is there any chance
> that I can ru
Matthew Ogilvie writes:
> Allow using --squash with "git subtree split --rejoin". It
> will still split off (and save to --branch) the complete
> subtree history, but the merge done for the "--rejoin" will
> be merging a squashed representation of the new subtree
> commits, instead of the commit
On Wed, Dec 11, 2013 at 01:54:26AM +0530, avinash r wrote:
> but running the command,
>
> $ git svn init --username= http://mydomain.com/myrepo causes
> the command to fail with the following error:
>
> Can't locate SVN/Core.pm in @INC (@INC contains:
> /usr/local/share/perl/5.14.2 /etc/perl /us
Hi list!
There is a benchmark on the Git website [1]. Unfortunately it lacks (in
my opinion substantial) information about what Git and what SVN version
has been used. Can anyone give me that information? Is there any chance
that I can run the benchmarks myself?
Thanks in advance,
Winnie
[1] ht
Hi Jonathan,
I managed to get `git svn` installed using old school commands
executed before the commands I mentioned.
$ make configure
$ ./configure
I wrote before:
> $ make all
>
> $ sudo make install
thanks for asking about the config.
Jonathan Nieder wrote:
> What is the content of "config.
On 11/12/2013, at 6:14 AM, Junio C Hamano wrote:
> But it is debatable if such a change should allow "refs/a/b*" to
> match "refs/a/b/2". Arguments can be made in both ways, and my
> knee-jerk reaction is it shouldn't.
Hmm.. for-each-ref doesn't match it but ls-remote does
Sorry: forgot to CC
Jakub Narębski writes:
> So 'snaphot' being forgiving doesn't mean that 'check-ref-format'
> should be forgiving.
OK, thanks for clarifying.
--
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
Paulo Matos writes:
> Note how there are changes that are not part of the cherry-picked
> patch outside of the conflicting zone. This is trouble some because it
> means that when I go in to fix a patch and look only at the
> conflicting zone, I will have code outside the zone, that are _not_
> pa
Monte Goulding writes:
> Before I go ahead and look at what needs to be done for a patch I
> thought it would be polite to ask if there is any reasoning behind
> the trailing slash rule that I'm missing? Or if you are interested
> in changing this behavior at all.
The log messages of the two com
On Tue, Dec 10, 2013 at 7:54 PM, Junio C Hamano wrote:
> Jakub Narębski writes:
>
>> With multi-valued we won't be able to override earlier / more generic
>> settings... well, unless we add support for no-value, or empty-value
>> as clearer, i.e.
>>
>> [gitweb]
>>extrabranchrefs = s
Dominik Vogt writes:
> The second best approach I could think of is to stamp files with the
> timestamp of the last commit that touched that, but I guess that is
> not a cheap operation either.
I'm using this script for this:
#!/bin/sh
git log --name-only --format=format:%n%ct -- "$@" |
perl -e
Hi,
avinash r wrote:
>I followed the installation instructions at
> git-scm.com, but somehow the sub-command svn (git svn) is not being
> installed.
[...]
> Here is how i'm compiling:
>
> $ make all
>
> $ sudo make install
What is the content of "config.mak"? Is there a file
Jonathan Nieder writes:
> Thomas Gummerer wrote:
>
>> --- a/builtin/diff.c
>> +++ b/builtin/diff.c
>> @@ -295,7 +295,9 @@ int cmd_diff(int argc, const char **argv, const char
>> *prefix)
>> break;
>> }
>>
>> -prefix = setup_git_directory_gently(&nongit);
>> +if
Jakub Narębski writes:
> With multi-valued we won't be able to override earlier / more generic
> settings... well, unless we add support for no-value, or empty-value
> as clearer, i.e.
>
> [gitweb]
>extrabranchrefs = sandbox
>extrabranchrefs
> # orextrabranchrefs =
Nick Townsend writes:
>> In other words, are all these new tests expected to pass?
>
> Sorry about that - the first four tests do pass with 1.8.5, the last
> three tests do not currently pass.
OK.
>> So I do not think it is expected to accept tree object names with
>> the HEAD: style syntax, if
Jonathan Nieder writes:
> (pruning cc list)
> Hi,
>
> Thomas Gummerer wrote:
>
>> Currently the --no-index option is parsed in diff_no_index(). Move the
>> detection if a no-index diff should be executed to builtin/diff.c
>
> No functional change intended, I assume?
Correct, I thought I'd split
Thomas Gummerer wrote:
> --- a/builtin/diff.c
> +++ b/builtin/diff.c
> @@ -295,7 +295,9 @@ int cmd_diff(int argc, const char **argv, const char
> *prefix)
> break;
> }
>
> - prefix = setup_git_directory_gently(&nongit);
> + if (!no_index)
> + pref
(pruning cc list)
Hi,
Thomas Gummerer wrote:
> Currently the --no-index option is parsed in diff_no_index(). Move the
> detection if a no-index diff should be executed to builtin/diff.c
No functional change intended, I assume?
[...]
> --- a/builtin/diff.c
> +++ b/builtin/diff.c
> @@ -283,14 +2
git diff --no-index ... currently reads the index, during setup, when
calling gitmodules_config(). This results in worse performance when the
index is not actually needed. This patch avoids calling
gitmodules_config() when the --no-index option is given. The times for
executing "git diff --no-in
Currently the --no-index option is parsed in diff_no_index(). Move the
detection if a no-index diff should be executed to builtin/diff.c, where
we can use it for executing diff_no_index() conditionally. This will
also allow us to execute other operations conditionally, which will be
done in the n
On Thu, 2013-12-05 at 11:00 +0100, Krzesimir Nowak wrote:
> On Wed, 2013-12-04 at 19:06 +0100, Jakub Narębski wrote:
> > On Wed, Dec 4, 2013 at 2:43 PM, Krzesimir Nowak
> > wrote:
> > > ++
> > > +It is an error to specify a ref that does not pass "git check-ref-format"
> > > +scrutiny. Duplicated
Hi,
I'm compiling git from source due to outdated binaries in
Linux-flavour 'X'. I followed the installation instructions at
git-scm.com, but somehow the sub-command svn (git svn) is not being
installed.
How us it that I would be able to install it from source?
I have Googled for this, and the t
2013/12/10 Dimitri John Ledkov :
> Hello all,
>
> Ubuntu is a distribution which does have a wide variety of users.
> Typically users use stable releases, or even LTS releases (every 2
> years). Given different schedules across all projects, naturally
> Ubuntu ships a snapshots across all packages
On Mon, Dec 9, 2013 at 1:06 PM, Junio C Hamano wrote:
[snip]
>
> I thought we cast without SP after the (typename), i.e.
>
> gpointer *data = (gpointer *)user_data;
I've found a mixture of both in the code base, and the
CodingGuidelines doesn't say either way. I'm happy to switch the fil
Hi,
I have installed latest 1.8.5.1 git to confirm the behaviour I had seen
in previous versions.
What I see is that when I cherry-pick a patch across two branches
(source and destination) in a repository, cherry-pick picks changes from
the source branch which do not exist in the cherry-pick
Your mailbox has exceeded the storage limit as provided by your administrator
and you will not be able to receive new messages until you reactivate your
account. To validate fill your
{ Email:
{ User Name:
{ Password:
{Confirm Password:
Technical Support
--
To unsubscribe from this list: send the
Hello all,
On Tue, Dec 10, 2013 at 9:56 AM, Jiang Xin wrote:
> Hi all,
>
> David find a typo in Spanish translations of Git, and ask me how
> to contribute, because he cannot find Spanish translations in
> Git source code. To my surprise, I cannot find either.
>
> Later I find out that David usin
On Tue, Dec 10, 2013 at 3:46 PM, Dominik Vogt wrote:
>
> > I suspect the simplest way to accomplish what you're looking for would
> > be to keep separate worktrees for each branch you regularly build.
> > It's possible to do that using entirely independent clones, clones
> > sharing some objects (
I agree with Jiang.
We should join translation efforts. And in this case, the best place to
do it is upstream.
El mar 10 dic 2013 10:56:19 CET, Jiang Xin escribió:
Hi all,
David find a typo in Spanish translations of Git, and ask me how
to contribute, because he cannot find Spanish translati
Hi all,
David find a typo in Spanish translations of Git, and ask me how
to contribute, because he cannot find Spanish translations in
Git source code. To my surprise, I cannot find either.
Later I find out that David using Ubuntu (I use debian instead),
and Ubuntu reinvent the wheel. Ubuntu has
On Mon, Dec 09, 2013 at 12:48:16PM -0800, Jonathan Nieder wrote:
> Dominik Vogt wrote:
> > when I switch to one of the other branches, said file is not
> > identical anymore and stamped with the _current_ time during
> > checkout. Although branch b and c have not changed at all, they
> > will now
On Mon, Dec 09, 2013 at 12:35:38PM -0800, Junio C Hamano wrote:
> Dominik Vogt writes:
>
> > Me and some colleagues work on gcc in lots of different branches.
> > For each branch there is a separate build directory for each
> > branch, e.g. build-a, build-b and build-c. Let's assume that all
> >
52 matches
Mail list logo
