When I try to a plain old "git add ." when files have been
deleted/moved, I get the warning
> You ran 'git add' with neither '-A (--all)' or '--ignore-removal'
There should be some way to put something in ~/.gitconfig to tell git to
always choose one or another.
--
To unsubscribe from this list:
On Wed, Sep 25, 2013 at 10:13 AM, Keshav Kini wrote:
> [2] fs@erdos /tmp/extraction-framework $ git checkout wiktionary --
> fatal: invalid reference: wiktionary
It may work if we demote this from fatal to error warning so the dwim
logic in checkout has a chance to try differently, I thin
David Aguilar writes:
> On Tue, Sep 24, 2013 at 2:07 PM, Jona Christopher Sahnwaldt
> wrote:
>> Hi,
>>
>> maybe this has already been reported, but I didn't find it in the mail
>> archive.
>>
>> If I understand correctly, after I clone a repo, I should be able to
>> switch to branch foo just by
On Tue, Sep 24, 2013 at 2:07 PM, Jona Christopher Sahnwaldt
wrote:
> Hi,
>
> maybe this has already been reported, but I didn't find it in the mail
> archive.
>
> If I understand correctly, after I clone a repo, I should be able to
> switch to branch foo just by running
>
> git checkout foo
>
> T
On Tue, Sep 24, 2013 at 03:53:56PM -0700, Jonathan Nieder wrote:
> Michael S. Tsirkin wrote:
>
> > See v2 that I sent, maybe that's clear enough.
>
> Yep, looks sensible. Thanks.
OK, ack that please :)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to
Michael S. Tsirkin wrote:
> See v2 that I sent, maybe that's clear enough.
Yep, looks sensible. Thanks.
--
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 Tue, Sep 24, 2013 at 03:44:31PM -0700, Jonathan Nieder wrote:
> Michael S. Tsirkin wrote:
> > On Tue, Sep 24, 2013 at 03:14:09PM -0700, Jonathan Nieder wrote:
> >> Michael S. Tsirkin wrote:
>
> >>> -The commits are compared with their 'patch id', obtained from
> >>> -the 'git patch-id' program.
Michael S. Tsirkin wrote:
> On Tue, Sep 24, 2013 at 03:14:09PM -0700, Jonathan Nieder wrote:
>> Michael S. Tsirkin wrote:
>>> -The commits are compared with their 'patch id', obtained from
>>> -the 'git patch-id' program.
>>> +The diffs are compared with their diff id (sha1) calculated after remov
The id is already different for binary files.
The hash used is an implementation detail, so
let's just document how diffs are compared.
Cc: Jonathan Nieder
Signed-off-by: Michael S. Tsirkin
---
Changes from v1:
address comments by Jonathan
Documentation/git-cherry.txt | 3 +--
1 file
On Tue, Sep 24, 2013 at 03:14:09PM -0700, Jonathan Nieder wrote:
> Michael S. Tsirkin wrote:
>
> > Subject: [PATCH] doc: don't claim that cherry-pick calls patch-id
>
> s/cherry-pick/cherry/
>
> > The id is already different for binary files.
> > Let's document that they are similar, not identic
Michael S. Tsirkin wrote:
> Subject: [PATCH] doc: don't claim that cherry-pick calls patch-id
s/cherry-pick/cherry/
> The id is already different for binary files.
> Let's document that they are similar, not identical.
Thanks.
[...]
> --- a/Documentation/git-cherry.txt
> +++ b/Documentation/gi
Michael S. Tsirkin wrote:
> On Tue, Sep 24, 2013 at 02:31:16PM -0700, Jonathan Nieder wrote:
>> Michael S. Tsirkin wrote:
>>> Just making sure: is it correct that there's no requirement to use same
>>> algorithm between patch-ids.c and builtin/patch-id.c ?
>>
>> I think so,
[...]
>> (They already
The id is already different for binary files.
Let's document that they are similar, not identical.
Cc: Jonathan Nieder
Signed-off-by: Michael S. Tsirkin
---
Documentation/git-cherry.txt | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-cherry.txt b/D
On Tue, Sep 24, 2013 at 02:31:16PM -0700, Jonathan Nieder wrote:
> Michael S. Tsirkin wrote:
> >>> On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:
>
> Then start over with sorted hunks (for example
> building a table of offsets within the patch
Michael S. Tsirkin wrote:
>>> On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:
Then start over with sorted hunks (for example
building a table of offsets within the patch for each hunk to
support this).
[...]
> Well, then the result is n
Hi,
maybe this has already been reported, but I didn't find it in the mail archive.
If I understand correctly, after I clone a repo, I should be able to
switch to branch foo just by running
git checkout foo
This doesn't seem to work if a folder called "foo" exists in the root
of the repo.
I go
On Tue, Sep 24, 2013 at 03:36:13AM -0400, Jeff King wrote:
> On Fri, Sep 20, 2013 at 11:27:15AM +0200, Josef Wolf wrote:
> > Even without asking, we can assume with great probability that
> > origin/somebranch is available at origin.
> Bear in mind that the transfer process does not know about
> c
On Tue, Sep 24, 2013 at 12:36:10PM -0700, Jonathan Nieder wrote:
> Michael S. Tsirkin wrote:
> > On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:
>
> >> a) When asked to compute the patch-id of a seekable file, use the
> >> current streaming implementation until you notice a f
Hello,
git rebase is confused about commits like
https://github.com/pfalcon/civetweb/commit/ce8493837bf7676c6d824cdcb1d5e3a7ed476fe1
- it stops, telling user to just run rebase --continue. I remember like
few years ago rebase was confused like that oftentimes, which is in turn
confused novices try
Michael S. Tsirkin wrote:
> On Mon, Sep 23, 2013 at 02:37:29PM -0700, Jonathan Nieder wrote:
>> a) When asked to compute the patch-id of a seekable file, use the
>> current streaming implementation until you notice a filename that
>> is out of order. Then start over with sorted hunks (fo
Mediawiki introduces a new API for queries w/ more than 500 results in
version 1.21. That change triggered an infinite loop while cloning a
mediawiki with such a page.
The latest API renamed and moved the "continuing" information in the
response, necessary to build the next query. The code failed
On Tue, Sep 24, 2013 at 2:39 PM, Jonathan Nieder wrote:
> Jeff King wrote:
>> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:
>
>>> For now simply add a few common aliases.
>>>
>>> co = checkout
>>> ci = commit
>>> rb = rebase
>>> st = status
>>
>> Are these the best defi
Johan Herland wrote:
> Signed-off-by: Johan Herland
Thanks.
What symptoms does this alleviate? Is this to allow configurations like
[hooks]
allowNonAscii = 1
and
[hooks]
allowNonAscii
to do the expected thing, or is it somethi
(cc-ing Jeff King, "git clone -c" inventor)
Hi,
Amit Bakshi wrote:
> I'm trying to use this to create a shared repo (group r/w), but it's
> not working as expected. The help for git clone says "Set a
> configuration variable in the newly-created repository; this takes
> effect immediately after
Jeff King wrote:
> On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:
>> For now simply add a few common aliases.
>>
>> co = checkout
>> ci = commit
>> rb = rebase
>> st = status
>
> Are these the best definitions of those shortcuts? It seems[1] that some
> people define "ci
Hi,
I'm trying to use this to create a shared repo (group r/w), but it's
not working as expected. The help for git clone says "Set a
configuration variable in the newly-created repository; this takes
effect immediately after the repository is initialized, but before the
remote history is fetched
For now simply add a few common aliases.
co = checkout
ci = commit
rb = rebase
st = status
Signed-off-by: Felipe Contreras
---
Documentation/git-checkout.txt | 5 +
Documentation/git-commit.txt | 5 +
Documentation/git-rebase.txt | 5 +
Documentation/git-status.txt | 5
The subject line needs to be updated.
On Sat, Sep 21, 2013 at 02:20:21PM -0500, Felipe Contreras wrote:
> For now simply add a few common aliases.
>
> co = checkout
> ci = commit
> rb = rebase
> st = status
>
> Signed-off-by: Felipe Contreras
> ---
[...]
> diff --git a/alias.c b/alias
On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister wrote:
> On Tue, Sep 24, 2013 at 6:25 AM, Felipe Contreras
> wrote:
>> On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister
>> wrote:
>>> On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras
>>> wrote:
For now simply add a few common aliases.
>>
On 13-09-24 03:51 AM, Jeff King wrote:
On Sat, Sep 21, 2013 at 08:42:26AM +0200, Michael Haggerty wrote:
I think it would be preferable if "--prune" would *not* affect tags, and
if there were an extra option like "--prune-tags" that would have to be
used explicitly to cause tags to be pruned.
Hi Karsten,
On Tue, Sep 24, 2013 at 5:50 PM, Karsten Blees wrote:
>
> | add| get 100% hits |get 10% hits
> | hash | hashmap | hash | hashmap | hash | hashmap
> ++-+---+-+-+
> FNV | 14.815 | 2.345 |
On Tue, Sep 24, 2013 at 6:25 AM, Felipe Contreras
wrote:
> On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister
> wrote:
>> On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras
>> wrote:
>>> For now simply add a few common aliases.
>>>
>>> co = checkout
>>> ci = commit
>>> rb = rebase
>>> st
On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister wrote:
> On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras
> wrote:
>> For now simply add a few common aliases.
>>
>> co = checkout
>> ci = commit
>> rb = rebase
>> st = status
>>
>> Signed-off-by: Felipe Contreras
>> ---
>>
>> I still th
We have a period in other places after "done" (see e.g. clone_local), so
we should have one here, too.
Signed-off-by: Sebastian Schuberth
---
builtin/clone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index ca3eb68..0aff974 100644
--- a/
On Tue, Sep 24, 2013 at 11:50:16AM +0200, Karsten Blees wrote:
> Regarding performance, I have to admit that the difference between the two
> implementations is far greater than I had anticipated. The following times
> (in seconds) are from Linux x64 (Debian Sarge) on a Core i7 860 @2.8GHz. All
On Tue, Sep 24, 2013 at 10:00:30AM +0100, Luke Noel-Storr wrote:
> I'm trying to use the diff-algorithm option for recursive merge, but
> get the above error. I've tried various different ways of specifying
> the option, but none work.
>
> To try and find what the correct syntax is I tried peepin
Signed-off-by: Karsten Blees
---
diffcore-rename.c | 48 +---
1 file changed, 13 insertions(+), 35 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 82b7975..2e70d31 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -4,7 +4,
No actual code changes, just move hash_filespec up and outdent part of
find_identical_files.
Signed-off-by: Karsten Blees
---
diffcore-rename.c | 98 +++
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git a/diffcore-rename.c b/diffco
The find_exact_renames function currently only uses the hash table for
grouping, i.e.:
1. add sources
2. add destinations
3. iterate all buckets, per bucket:
4. split sources from destinations
5. iterate destinations, per destination:
6. iterate sources to find best match
This can be simplified b
Signed-off-by: Karsten Blees
---
builtin/describe.c | 53 -
1 file changed, 24 insertions(+), 29 deletions(-)
diff --git a/builtin/describe.c b/builtin/describe.c
index 7d73722..5db5d89 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@
Also here: https://github.com/kblees/git/tree/kb/hashmap-v2
Changes since initial version:
- removed struct typedefs
- clarified documentation of hashmap_entry
- renamed find_entry -> find_entry_ptr
- added performance tests for lookup
I've also tried to resize the table based on the number of u
The existing hashtable implementation (in hash.[ch]) uses open addressing
(i.e. resolve hash collisions by distributing entries across the table).
Thus, removal is difficult to implement with less than O(n) complexity.
Resolving collisions of entries with identical hashes (e.g. via chaining)
is lef
Dear Juno
Thanks for your answer.
My fair criticism in my previous emails (and below) is just to try to convince
you that with a few short sentences you risk to transmit only vague ideas,
while a serious user is interested to understand the behavior of git in any
occurrence, with no ambiguity.
On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras
wrote:
> For now simply add a few common aliases.
>
> co = checkout
> ci = commit
> rb = rebase
> st = status
>
> Signed-off-by: Felipe Contreras
> ---
>
> I still think we should ship a default /etc/gitconfig, but the project needs
> to
Hi,
I'm trying to use the diff-algorithm option for recursive merge, but get the
above error. I've tried various different ways of specifying the option, but
none work.
To try and find what the correct syntax is I tried peeping into the source
code, and it looks like it may actually be an err
Benoit Person writes:
>> d17cf5f3a32f07bf (tests: Introduce test_seq; 2012-08-03)
>>
>>> + do
>>> + echo "creating revision $i"
>>
>> Do you want to end this line with '&&'?
> The way it's intended is that it's more a debug information to see how
> it's going on (creating >50
On 23 September 2013 19:58, Matthieu Moy wrote:
> I'd rather have the comments say "# API version < X" and "# API version
>>= X". Next time the API change, "new" Vs "old" will become meaningless.
done, thanks
On 23 September 2013 20:26, Jonathan Nieder wrote:
> Some distros (e.g., Debian) occas
Signed-off-by: Johan Herland
---
Resend/reminder...
...Johan
templates/hooks--pre-commit.sample | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/templates/hooks--pre-commit.sample
b/templates/hooks--pre-commit.sample
index 586e3bf..68d62d5 100755
--- a/templates/hooks--pre-
On Sat, Sep 21, 2013 at 08:42:26AM +0200, Michael Haggerty wrote:
> I think it would be preferable if "--prune" would *not* affect tags, and
> if there were an extra option like "--prune-tags" that would have to be
> used explicitly to cause tags to be pruned. Would somebody object to
> such a ch
On Tue, Sep 24, 2013 at 1:54 AM, Jeff King wrote:
> On Tue, Sep 24, 2013 at 01:31:48AM -0500, Felipe Contreras wrote:
>
>> > I don't think it is the end of the world if we say "upstream branch". I
>> > was hoping to find a term that could be both friendly and accurate.
>> >
>> > And failing that,
On Fri, Sep 20, 2013 at 11:27:15AM +0200, Josef Wolf wrote:
> > Yes. If you know that the receiver has commit X, and you want to know if
> > it has some blob Y, the only way to know for sure is to look at every
> > tree of every commit reachable from X, and see whether any of them
> > references Y
On Tue, Sep 24, 2013 at 1:46 AM, Jeff King wrote:
> On Tue, Sep 24, 2013 at 01:41:19AM -0500, Felipe Contreras wrote:
>
>> > People who have different aliases for
>> > the same terms are unaffected on existing boxes, but slightly hindered
>> > on new boxes as the aliases do something else.
>>
>> L
52 matches
Mail list logo
