On Tue, Sep 24, 2013 at 12:57:36AM -0500, Felipe Contreras wrote:
No, I'm not. The users that know branch.*.remote exists know why it
exists. The part where it is explained, 'git config --help', is
perfectly clear: When on branch name, it tells 'git fetch' and 'git
push' which remote to fetch
On Tue, Sep 24, 2013 at 12:49:21AM -0500, Felipe Contreras wrote:
Anyway, if you are so worried about this hypothetical user not
noticing that 'git ci' didn't commit all the files, we could ma ci to
'git commit -v' so we are being straightforward to the user as to what
is being committed.
I
On Tue, Sep 24, 2013 at 1:10 AM, Jeff King p...@peff.net wrote:
On Tue, Sep 24, 2013 at 12:57:36AM -0500, Felipe Contreras wrote:
No, I'm not. The users that know branch.*.remote exists know why it
exists. The part where it is explained, 'git config --help', is
perfectly clear: When on branch
On Tue, Sep 24, 2013 at 1:18 AM, Jeff King p...@peff.net wrote:
On Tue, Sep 24, 2013 at 12:49:21AM -0500, Felipe Contreras wrote:
Anyway, if you are so worried about this hypothetical user not
noticing that 'git ci' didn't commit all the files, we could ma ci to
'git commit -v' so we are
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.
Less hindered than in the current situation.
I do not agree, but
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, I hoped you might say I see what you are saying, but
I cannot
On Sun, Sep 22, 2013 at 12:15:21PM -0700, Jonathon Mah wrote:
A few days ago I came across the same surprising output of git-grep,
tried to adjust the code to print git show-able object names, and
ran into similar subtleties. I just found this thread, and Jeff's code
handles more cases than
On Tue, Sep 24, 2013 at 1:46 AM, Jeff King p...@peff.net 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.
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:54 AM, Jeff King p...@peff.net 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, I
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 change?
Signed-off-by: Johan Herland jo...@herland.net
---
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
---
On 23 September 2013 19:58, Matthieu Moy matthieu@grenoble-inp.fr 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 jrnie...@gmail.com wrote:
Benoit Person benoit.per...@gmail.com 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
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
On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
For now simply add a few common aliases.
co = checkout
ci = commit
rb = rebase
st = status
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
I still think we should ship a default
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
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
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
Signed-off-by: Karsten Blees bl...@dcon.de
---
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
+++
No actual code changes, just move hash_filespec up and outdent part of
find_identical_files.
Signed-off-by: Karsten Blees bl...@dcon.de
---
diffcore-rename.c | 98 +++
1 file changed, 49 insertions(+), 49 deletions(-)
diff --git
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
Signed-off-by: Karsten Blees bl...@dcon.de
---
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
+++
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 peeping
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
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 sschube...@gmail.com
---
builtin/clone.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/clone.c b/builtin/clone.c
index
On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister j...@szakmeister.net wrote:
On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
For now simply add a few common aliases.
co = checkout
ci = commit
rb = rebase
st = status
Signed-off-by: Felipe
On Tue, Sep 24, 2013 at 6:25 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister j...@szakmeister.net
wrote:
On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras
felipe.contre...@gmail.com wrote:
For now simply add a few common aliases.
Hi Karsten,
On Tue, Sep 24, 2013 at 5:50 PM, Karsten Blees karsten.bl...@gmail.com wrote:
| add| get 100% hits |get 10% hits
| hash | hashmap | hash | hashmap | hash | hashmap
++-+---+-+-+
FNV |
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.
On Tue, Sep 24, 2013 at 6:06 AM, John Szakmeister j...@szakmeister.net wrote:
On Tue, Sep 24, 2013 at 6:25 AM, Felipe Contreras
felipe.contre...@gmail.com wrote:
On Tue, Sep 24, 2013 at 4:19 AM, John Szakmeister j...@szakmeister.net
wrote:
On Sat, Sep 21, 2013 at 3:20 PM, Felipe Contreras
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 felipe.contre...@gmail.com
---
[...]
diff --git
For now simply add a few common aliases.
co = checkout
ci = commit
rb = rebase
st = status
Signed-off-by: Felipe Contreras felipe.contre...@gmail.com
---
Documentation/git-checkout.txt | 5 +
Documentation/git-commit.txt | 5 +
Documentation/git-rebase.txt | 5 +
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
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 as commit -a,
(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 the
Johan Herland wrote:
Signed-off-by: Johan Herland jo...@herland.net
Thanks.
What symptoms does this alleviate? Is this to allow configurations like
[hooks]
allowNonAscii = 1
and
[hooks]
allowNonAscii
to do the expected thing,
On Tue, Sep 24, 2013 at 2:39 PM, Jonathan Nieder jrnie...@gmail.com 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 definitions
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
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 (for
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
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 filename
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
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 got
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 not compatible
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 for each hunk
The id is already different for binary files.
Let's document that they are similar, not identical.
Cc: Jonathan Nieder jrnie...@gmail.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Documentation/git-cherry.txt | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git
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 differ in
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
+++
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 identical.
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 jrnie...@gmail.com
Signed-off-by: Michael S. Tsirkin m...@redhat.com
---
Changes from v1:
address comments by Jonathan
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 removing
+any
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.
+The diffs
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: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
On Tue, Sep 24, 2013 at 2:07 PM, Jona Christopher Sahnwaldt
j...@sahnwaldt.de 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
David Aguilar dav...@gmail.com writes:
On Tue, Sep 24, 2013 at 2:07 PM, Jona Christopher Sahnwaldt
j...@sahnwaldt.de 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
On Wed, Sep 25, 2013 at 10:13 AM, Keshav Kini keshav.k...@gmail.com 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
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:
59 matches
Mail list logo
