Christian Couder christian.cou...@gmail.com writes:
sort_refs() - ref_array_sort()
struct ref_sort - struct ref_sort_criteria
default_sort() - ref_default_sort_criteria()
opt_parse_sort() - opt_parse_ref_sort_criteria()
BTW, having such summary in the log message would help review: we could
Karthik Nayak karthik@gmail.com writes:
On 06/01/2015 02:16 AM, Matthieu Moy wrote:
Karthik Nayak karthik@gmail.com writes:
That is kind of a problem, If I need to swap those commits also, I'd
have to add the part where ref-filter is added to the Makefile with
the code movement
On Mon, Jun 01, 2015 at 11:22:12AM +, brian m. carlson wrote:
As an aside, now that we are dereferencing, these flags are from the
wrong object. They _should_ be the same (we mark the tag as
UNINTERESTING, too), but it's a little weird that at the end of the
function we restore the
Check if commits were removed (i.e. a line was deleted) and print
warnings or abort git rebase according to the value of the
configuration variable rebase.checkLevel.
Add the configuration variable rebase.checkLevel.
- When unset or set to ignore, no checking is done.
- When set to warn,
Instead of removing a line to remove the commit, you can use the
command drop (just like pick or edit). It has the same effect as
deleting the line (removing the commit) except that you keep a visual
trace of your actions, allowing a better control and reducing the
possibility of removing a commit
Hi Greg,
On Mon, Jun 1, 2015 at 3:54 AM, Greg KH gre...@linuxfoundation.org wrote:
On Mon, Jun 01, 2015 at 09:17:59AM +0900, Greg KH wrote:
Hi all,
I received the patch attached below as part of a submission against the
Linux kernel tree. The patch seems to have been hand-edited, and is not
Previously this example would fail if the history contained any empty
commit, because the index would not change, and the mv would fail with:
mv: cannot stat redacted/index.new': No such file or directory
The updated example checks whether the index file has been created
before attempting the
On Mon, Jun 01, 2015 at 06:20:46AM -0400, Jeff King wrote:
So I think what you really want is lookup_commit_reference. And the
error message is really not invalid tag, but not a commit. I think
you can just use lookup_commit_or_die.
Thanks. That does seem to be what I want.
As an aside, now
According to the documentation, the parser should print a warning for
any explicitly unsupported constructs. These are now explicitly
unsupported, so the parser should warn on |, /, and :include: .
Perhaps the lines that match should be ignored like the others, too.
On Sun, May 31, 2015 at 6:29
This series looks very good to me. Thanks for the extra work you've
done to make the sendmail alias support much better :)
I'm not too concerned about this, but if you think it would be
appropriate you may use it:
Acked-by: Allen Hubbe alle...@gmail.com
On Sun, May 31, 2015 at 6:29 PM, Eric
On Mon, Jun 01, 2015 at 09:37:17AM +0200, Stefan Näwe wrote:
One of my repos started giving an error on 'git gc' recently:
$ git gc
error: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85
Counting objects: 3052, done.
Delta compression using up to 4 threads.
Compressing
Stefan noticed that running git gc with a recent version of git causes
some useless complaints about missing objects.
The reason is that since git d3038d2 (prune: keep objects reachable from
recent objects, 2014-10-15), we will traverse objects that are not
reachable but have recent mtimes
On Mon, Jun 01, 2015 at 11:14:27AM +0200, Stefan Näwe wrote:
Maybe this one:
d3038d (prune: keep objects reachable from recent objects)
Yes, exactly.
It would be really helpful if you sent the patch as an attachment.
I know that's not the normal wokflow but our mail server garbles
We set revs-ignore_missing_links to instruct the
revision-walking machinery that we know the history graph
may be incomplete. For example, we use it when walking
unreachable but recent objects; we want to add what we can,
but it's OK if the history is incomplete.
However, we still print error
- [PATCH 1/2] git-rebase -i: add command drop to remove a commit
The 'drop' command is added as a way to explicitely remove commits in
git rebase -i.
This patch does not prevent users from commenting the line, removing
the line or using the 'noop' command if they want to.
While the 'noop' command
When we call parse_commit, it will complain to stderr if the
object does not exist or cannot be read. This means that we
may produce useless error messages if this situation is
expected (e.g., because the object is marked UNINTERESTING,
or because revs-ignore_missing_links is set).
We can fix
When we are traversing commit parents along the
UNINTERESTING side of a revision walk, we do not care if
the parent turns out to be missing. That lets us limit
traversals using unreachable and possibly incomplete
sections of history. However, we do still print error
messages about the missing
Check if commits were removed (i.e. a line was deleted) and print
warnings or abort git rebase according to the value of the
configuration variable rebase.checkLevel.
Add the configuration variable rebase.checkLevel.
- When unset or set to ignore, no checking is done.
- When set to warn,
Hi there.
One of my repos started giving an error on 'git gc' recently:
$ git gc
error: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85
Counting objects: 3052, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (531/531), done.
Writing objects: 100%
On Mon, Jun 01, 2015 at 01:03:13AM +, brian m. carlson wrote:
format-patch would segfault if provided a tag as one of the range
endpoints in conjunction with --ignore-if-in-upstream, as it assumed the
object was a commit and attempted to cast it to struct commit.
Dereference the tag as
On Sun, May 31, 2015 at 11:15:22AM -0700, Jim Hill wrote:
Check for an existing match before appending a path to the alternates
file. Beyond making git look smart to anyone checking the alternates
file, this removes the last use of hold_lock_file_for_append.
Makes sense. We don't catch _all_
Instead of removing a line to remove the commit, you can use the
command drop (just like pick or edit). It has the same effect as
deleting the line (removing the commit) except that you keep a visual
trace of your actions, allowing a better control and reducing the
possibility of removing a commit
On Sun, May 31, 2015 at 11:16:45AM -0700, Jim Hill wrote:
Make strbuf_read not try to do read_in_full's job too. If xread returns
less than was requested it can be either eof or an interrupted read. If
read_in_full returns less than was requested, it's eof. Use read_in_full
to detect eof
Am 01.06.2015 um 10:52 schrieb Jeff King:
On Mon, Jun 01, 2015 at 10:40:53AM +0200, Stefan Näwe wrote:
Turns out to be a tree:
tree 7713c3b1e9ea2dd9126244697389e4000bb39d85
parent d7acfc22fbc0fba467d82f41c90aab7d61f8d751
author Stefan Naewe stefan.na...@atlas-elektronik.com 1429536806
Am 01.06.2015 um 11:58 schrieb Jeff King:
On Mon, Jun 01, 2015 at 11:14:27AM +0200, Stefan Näwe wrote:
Maybe this one:
d3038d (prune: keep objects reachable from recent objects)
Yes, exactly.
It would be really helpful if you sent the patch as an attachment.
I know that's not the
On Mon, Jun 01, 2015 at 10:40:53AM +0200, Stefan Näwe wrote:
Turns out to be a tree:
tree 7713c3b1e9ea2dd9126244697389e4000bb39d85
parent d7acfc22fbc0fba467d82f41c90aab7d61f8d751
author Stefan Naewe stefan.na...@atlas-elektronik.com 1429536806 +0200
committer Stefan Naewe
On Mon, Jun 01, 2015 at 12:08:27PM +0200, Stefan Näwe wrote:
It ended up as a patch series. However, you can fetch it from:
git://github.com/peff/git.git jk/silence-unreachable-broken-links
which is perhaps even easier.
Not really in my situation...(but that's another story)
Oh,
On Sun, May 31, 2015 at 07:16:29PM -0400, Spencer Baugh wrote:
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -1237,6 +1237,7 @@ static int parse_branchname_arg(int argc, const char
**argv,
char *head_ref = resolve_refdup(HEAD, 0, sha1, flag);
if (head_ref
Am 01.06.2015 um 10:14 schrieb Jeff King:
On Mon, Jun 01, 2015 at 09:37:17AM +0200, Stefan Näwe wrote:
One of my repos started giving an error on 'git gc' recently:
$ git gc
error: Could not read 7713c3b1e9ea2dd9126244697389e4000bb39d85
Counting objects: 3052, done.
Delta compression
On Sun, May 31, 2015 at 11:15:21AM -0700, Jim Hill wrote:
These patches address
http://thread.gmane.org/gmane.comp.version-control.git/269050/focus=269415
linked from the git blame page, avoiding adding duplicates to info/alternates
and removing hold_lock_file_for_append which is too
Ralf Thielow venit, vidit, dixit 29.05.2015 20:54:
The term index is translated as Staging-Area to
not confuse beginners who don't know about Git's index.
Since the term staging area doesn't appear in original
Git messages (not even in the glossary) and index is a
well known term for
Hello,
the imap.folder config option specifies the folder name to use on the
imap server.
At the protocol level, according to RFC 3501 Section Mailbox
International Naming Convention, folder names use a modified UTF-7
encoding. The git-imap-send command doesn't encode the folder name
though;
Hi,
#: sequencer.c:661
#, c-format
msgid git %s: failed to read the index
-msgstr git %s: Fehler beim Lesen der Staging-Area
+msgstr git %s: Fehler beim Lesen des Indexes
Now we have to decide whether we flex Index like a foreign word in
German or like a German word:
der Index, des
Jeff King p...@peff.net writes:
On Sun, May 31, 2015 at 11:16:45AM -0700, Jim Hill wrote:
Make strbuf_read not try to do read_in_full's job too. If xread returns
less than was requested it can be either eof or an interrupted read. If
read_in_full returns less than was requested, it's eof.
Jeff King p...@peff.net writes:
Stefan noticed that running git gc with a recent version of git causes
some useless complaints about missing objects.
The reason is that since git d3038d2 (prune: keep objects reachable from
recent objects, 2014-10-15), we will traverse objects that are not
Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr writes:
Remove the limitation imposed by 79ee555b (Check and document the
options to prevent mistakes, 2006-06-21) which rejected every argument
with comma in --cc, --to and --bcc
Missing . at the end of sentence.
-The --bcc option must be
Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr writes:
Instead of removing a line to remove the commit, you can use the
command drop (just like pick or edit). It has the same effect as
deleting the line (removing the commit) except that you keep a visual
trace of your actions,
Hello,
I'm wondering if there is no option to find out the full path of a conflicting
file from within a custom merge driver? If I understand this correctly, Git
only provides the name of the 3 temporary local files and the size of the
limiter. But is there any possibility to get the path of
Currently, git for-each-ref fails to handle REF_ISBROKEN references
correctly, treating them instead as valid references that point at
NULL_SHA1. Sometimes this makes for-each-ref emit the wrong error
message; sometimes it even appears to complete successfully.
Instead, emit warnings for broken
Add tests that for-each-ref correctly reports broken loose reference
files and references that point at missing objects. In fact, two of
these tests fail, because (1) NULL_SHA1 is not recognized as an
invalid reference value, and (2) for-each-ref doesn't respect
REF_ISBROKEN. Fixes to come.
If there is a loose reference file with invalid contents, git
for-each-ref incorrectly reports the problem as being a missing
object with name NULL_SHA1:
$ echo '12345678' .git/refs/heads/nonsense
$ git for-each-ref
fatal: missing object for
NULL_SHA1 is never a valid value for a reference. If a loose reference
has that value, mark it as broken.
Why check NULL_SHA1 and not the nearly 2^160 other SHA-1s that are
also invalid in a given repository? Because (a) it is cheap to test
for NULL_SHA1, and (b) NULL_SHA1 is often used as a
On Mon, Jun 01, 2015 at 05:53:49PM +0200, Michael Haggerty wrote:
Add tests that for-each-ref correctly reports broken loose reference
files and references that point at missing objects. In fact, two of
these tests fail, because (1) NULL_SHA1 is not recognized as an
invalid reference value,
Jeff King p...@peff.net writes:
The fixes make sense to me (I haven't carefully read the
implementation, but design/approach explained in the proposed log
messages are very sound), and I think 3/3 is a good thing to do,
too, in the new world order after d3038d2.
I think it's rather the
Quoting Junio C Hamano gits...@pobox.com:
SZEDER Gábor sze...@ira.uka.de writes:
I don't see the benefits of this change. This patch adds more than
twice as many lines as it removes, and patch 2/2 adds 8 new lines
although it could get away with only 5 without this function. To
offer
Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr writes:
Accept a list of emails separated by commas in flags --cc, --to and
--bcc. Multiple addresses can already be given by using these options
multiple times, but it is more convenient to allow cutting-and-pasting
a list of addresses
On Mon, Jun 01, 2015 at 08:03:05AM -0700, Junio C Hamano wrote:
The reason is that since git d3038d2 (prune: keep objects reachable from
recent objects, 2014-10-15), we will traverse objects that are not
reachable but have recent mtimes (within the 2-week prune expiration
window). Because
Gondek, Andreas andreas.gon...@dwpbank.de writes:
I'm wondering if there is no option to find out the full path of a
conflicting file from within a custom merge driver? If I understand
this correctly, Git only provides the name of the 3 temporary local
files and the size of the limiter. But
Junio C Hamano gits...@pobox.com writes:
Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr writes:
Accept a list of emails separated by commas in flags --cc, --to and
--bcc. Multiple addresses can already be given by using these options
multiple times, but it is more convenient to allow
On Mon, Jun 1, 2015 at 3:44 PM, Christian Couder
christian.cou...@gmail.com wrote:
The following seems to fix it, but I am not sure it is the right fix:
Ooops, I had not seen that Brian and Peff are already discussing a fix
in this thread:
Currently, we have different wordings for the same index write error
message, which may be confusing to users and increases the risk of
more severely different translated messages:
builtin/add.c: die(_(Unable to write new index file));
builtin/apply.c:
Currently, we have different wordings for the same index read error
message, which may be confusing to users and increase3s the risk of more
severely different translated messages:
builtin/apply.c:die(_(unable to read index file));
show-index.c:
Accept a list of emails separated by commas in flags --cc, --to and
--bcc. Multiple addresses can already be given by using these options
multiple times, but it is more convenient to allow cutting-and-pasting
a list of addresses from the header of an existing e-mail message,
which already lists
Create a function which replaces Date, Message-Id and
X-Mailer lines generated by git-send-email by a specific string
Date:.*$ - Date: DATE-STRING
Message-Id:.*$ - Message-Id: MESSAGE-ID-STRING
X-Mailer:.*$ - X-Mailer: X-MAILER-STRING
This is a preparatory for the next commit which uses
SZEDER Gábor sze...@ira.uka.de writes:
I don't see the benefits of this change. This patch adds more than
twice as many lines as it removes, and patch 2/2 adds 8 new lines
although it could get away with only 5 without this function. To
offer sequencer options we currently go through
On Mon, Jun 1, 2015 at 2:01 AM, Christian Couder
christian.cou...@gmail.com wrote:
On Mon, Jun 1, 2015 at 1:53 AM, Christian Couder
christian.cou...@gmail.com wrote:
On Mon, Jun 1, 2015 at 1:14 AM, Christian Couder
christian.cou...@gmail.com wrote:
On Sun, May 31, 2015 at 10:45 PM, Bruce Korb
Hi,
git bisect old/new is an alternative to good/bad, which can be confusing to use
in some situations.
A work on it was done a few years ago, it is partially working but there are a
lot of issues.
We based on Christian Couder's github:
https://github.com/chriscool/git/commits/boldnew2
Karthik Nayak karthik@gmail.com writes:
Could be achieved using a simple wrapper around 'filter_refs()'
something like this perhaps.
int filter_refs_with_pattern(struct ref_array *ref, int
(*for_each_ref_fn)(each_ref_fn, void *), char **patterns)
{
int i;
struct
On Sun, May 31, 2015 at 4:53 PM, Christian Couder
christian.cou...@gmail.com wrote:
(Please don't top post if you reply to this email as it is frown upon
on this list.)
WRT top posting, two points:
1. Too many sites/lists now *require* top posting
2. MUA's (like Google Mail) hide the old mail
brian m. carlson sand...@crustytoothpaste.net writes:
diff --git a/builtin/log.c b/builtin/log.c
index dd8f3fc..e0465ba 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -807,6 +807,12 @@ static void get_patch_ids(struct rev_info *rev, struct
patch_ids *ids)
o2 =
Matthieu Moy matthieu@grenoble-inp.fr writes:
Just match_refname may not carry all the semantics of the function,
which matches a prefix up to the end of string, or up to a / (but you
can't just be a prefix stopping in the middle of a word). To me, the
_as_path helped understanding the
Hi,
Just had to deal with a nasty cross-UNIX/Windows problem.
Two files in the repository were in the same direcory and had the same
name differing only by the case of some of the letters. While
checking them out, git wantonly confused them (conflated them into
one) and got confused about them.
I keep having git-repack run out of virtual memory ( 32 bit system )
when trying to repack my linux kernel repo. It keeps making it right up
to 99% then barfing saying mmap failed: Cannot allocate memory.
I thought I could help this by limiting the pack size, and using
--window-memory to
Jeff King p...@peff.net writes:
On Mon, Jun 01, 2015 at 05:53:49PM +0200, Michael Haggerty wrote:
Add tests that for-each-ref correctly reports broken loose reference
files and references that point at missing objects. In fact, two of
these tests fail, because (1) NULL_SHA1 is not recognized
On Mon, 1 Jun 2015 13:30:19 -0400
Vadim Kramer vkokie...@gmail.com wrote:
Just had to deal with a nasty cross-UNIX/Windows problem.
Two files in the repository were in the same direcory and had the same
name differing only by the case of some of the letters. While
checking them out, git
Junio C Hamano gits...@pobox.com writes:
Galan Rémi remi.galan-alfo...@ensimag.grenoble-inp.fr writes:
Instead of removing a line to remove the commit, you can use the
command drop (just like pick or edit). It has the same effect as
deleting the line (removing the commit) except that you
Junio C Hamano gits...@pobox.com writes:
Is this sufficient?
If you are going to do something in 2/2 that relies on the format of
this line being correct (as opposed to noop or # that can have
any garbage on the remainder of the line), wouldn't you want to at
least check $sha1 is sensible?
Junio C Hamano gits...@pobox.com writes:
brian m. carlson sand...@crustytoothpaste.net writes:
diff --git a/builtin/log.c b/builtin/log.c
index dd8f3fc..e0465ba 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -807,6 +807,12 @@ static void get_patch_ids(struct rev_info *rev,
struct
Junio C Hamano gits...@pobox.com writes:
Remi LESPINET remi.lespi...@ensimag.grenoble-inp.fr writes:
first original file:
10
20
30
40
for the following diff file:
@@ -1,2 +1,2 @@
20
-30
+35
40
The patch will not be applied with a git apply command, but it will
with a basic
On Mon, Jun 01, 2015 at 07:43:08AM -0400, Allen Hubbe wrote:
On May 31, 2015 at 6:29 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
Sendmail aliases[1] supports expansion to a file (/path/name) or
pipe (|command), as well as file inclusion (:include: /path/name),
however, our
On Mon, Jun 01, 2015 at 10:44:21AM -0700, Junio C Hamano wrote:
Shouldn't you ensure o1 and o2 are commits here?
Heh, I should have read the remainder of the thread before
responding.
How about doing it this way? We know and trust that existing
revision traversal machinery is doing the
Junio C Hamano gits...@pobox.com writes:
How about doing it this way? We know and trust that existing
revision traversal machinery is doing the right thing, and it is
only that the clear_commit_marks() calls are botched.
Another alternative may be to allow any object to clear_commit_marks()
==
= 1. The bug
==
hunks of the form:
@@ -1,k +n,m @@
have a special behavior because of the variable match_begining. For
these hunks, offset is not allowed
Remi LESPINET remi.lespi...@ensimag.grenoble-inp.fr writes:
first original file:
10
20
30
40
for the following diff file:
@@ -1,2 +1,2 @@
20
-30
+35
40
The patch will not be applied with a git apply command, but it will
with a basic patch command.
Doesn't that merely indicate
Junio C Hamano gits...@pobox.com writes:
Remi LESPINET remi.lespi...@ensimag.grenoble-inp.fr writes:
first original file:
10
20
30
40
for the following diff file:
@@ -1,2 +1,2 @@
20
-30
+35
40
The patch will not be applied with a git apply command, but it will
with a basic
On Wed, May 27, 2015 at 12:08 AM, Jeff King p...@peff.net wrote:
On Wed, May 27, 2015 at 02:18:18AM -0400, Jeff King wrote:
The new protocol works just like the old protocol, except for
the capabilities negotiation being before any exchange of real data.
I like this approach. [...]
So
Remi LESPINET remi.lespi...@ensimag.grenoble-inp.fr writes:
==
= 2. Correction
==
I see mainly two ways to fix the bug:
Greg KH gre...@linuxfoundation.org writes:
But, there's nothing in the patch at all except the commit message:
$ git show HEAD
...
Any ideas what is going on here? Shouldn't 'git am' have failed?
Yes. The patch reads like this:
---
Matthieu Moy matthieu@grenoble-inp.fr writes:
@@ -1,1 +1,2 @@
+5
10
@@ -1,3 +2,3 @@
10
+15
-20
30
With this one, I get:
$ git apply p2.diff
error: patch failed: pre.txt:1
error: pre.txt: patch does not apply
$ patch p2.diff
patching file pre.txt
= no fuzzy matching
Junio C Hamano gits...@pobox.com writes:
Matthieu Moy matthieu@grenoble-inp.fr writes:
@@ -1,1 +1,2 @@
+5
10
@@ -1,3 +2,3 @@
10
+15
-20
30
With this one, I get:
$ git apply p2.diff
error: patch failed: pre.txt:1
error: pre.txt: patch does not apply
$ patch p2.diff
On June 1, 2015 12:08:57 PM GMT+05:30, Matthieu Moy
matthieu@grenoble-inp.fr wrote:
Christian Couder christian.cou...@gmail.com writes:
sort_refs() - ref_array_sort()
struct ref_sort - struct ref_sort_criteria
default_sort() - ref_default_sort_criteria()
opt_parse_sort() -
On Mon, Jun 1, 2015 at 2:58 PM, Junio C Hamano gits...@pobox.com wrote:
Subject: apply: reject a hunk that does not do anything
A hunk like this in a hand-edited patch without correctly adjusting
the line counts:
@@ -660,2 +660,2 @@ inline struct sk_buff *ieee80211_authentic...
Matthieu Moy matthieu@grenoble-inp.fr writes:
I am not sure what you are trying to do with that patch that tries
to touch the same line twice. Is this the same old laziness coming
back to bite us, the one that we attempted to work around with
933e44d3 (add -p: work-around an old laziness
Am Montag, 1. Juni 2015, 09:38:37 schrieb g...@drmicha.warpmail.net:
Ralf Thielow venit, vidit, dixit 29.05.2015 20:54:
The term index is translated as Staging-Area to
not confuse beginners who don't know about Git's index.
Since the term staging area doesn't appear in original
Git
On June 1, 2015 8:23:51 PM GMT+05:30, Junio C Hamano gits...@pobox.com wrote:
Karthik Nayak karthik@gmail.com writes:
Could be achieved using a simple wrapper around 'filter_refs()'
something like this perhaps.
int filter_refs_with_pattern(struct ref_array *ref, int
Junio C Hamano gits...@pobox.com writes:
It claims that it has only 2 lines in the hunk, so git apply
parses the hunk that begins at line 660 as such:
@@ -660,2 +660,2 @@ inline struct sk_buff *ieee80211_authentic...
auth = (struct ieee80211_authentication *)
On 6/1/2015 2:43 PM, Junio C Hamano wrote:
Phil Susi ps...@ubuntu.com writes:
I keep having git-repack run out of virtual memory ( 32 bit system )
when trying to repack my linux kernel repo. It keeps making it right
up to 99% then barfing saying mmap failed: Cannot allocate memory.
I thought
On Sun, 31 May 2015, David Aguilar wrote:
Were you thinking of something like this, or something else?
Can you describe your use case a bit more?
I think now I should just publish my script and then it will be very clear
what I'm talking about. If somebody then wants to add a similar feature
Phil Susi ps...@ubuntu.com writes:
I keep having git-repack run out of virtual memory ( 32 bit system )
when trying to repack my linux kernel repo. It keeps making it right
up to 99% then barfing saying mmap failed: Cannot allocate memory.
I thought I could help this by limiting the pack
Am Montag, 1. Juni 2015, 12:34:31 schrieb Stefan Beller:
On Mon, Jun 1, 2015 at 12:26 PM, Christian Stimming stimm...@tuhh.de
wrote:
index concept, my explanation routinely says This concept is called
'index' but it has nothing to do with any associations you make with that
word. Better
On Mon, Jun 1, 2015 at 12:26 PM, Christian Stimming stimm...@tuhh.de wrote:
index concept, my explanation routinely says This concept is called 'index'
but it has nothing to do with any associations you make with that word. Better
remember this thingy as *** and replace the termin 'index' with
Eric Sunshine sunsh...@sunshineco.com writes:
s/enw/new/
Heh, thanks; I wasn't planning to commit this one yet, but why not.
Here is with an updated log message and a test.
-- 8 --
Subject: [PATCH] apply: reject a hunk that does not do anything
A hunk like this in a hand-edited patch without
On Mon, Jun 01, 2015 at 03:07:16PM -0400, Phil Susi wrote:
It's more the --window-memory argument that is important here: it is
supposed to prevent exactly this problem. I guess I tried adding the
--max-pack-size as well on the off chance that it would help.
How many processors do you have?
Jeff King p...@peff.net writes:
On Mon, Jun 01, 2015 at 10:44:21AM -0700, Junio C Hamano wrote:
Shouldn't you ensure o1 and o2 are commits here?
Heh, I should have read the remainder of the thread before
responding.
How about doing it this way? We know and trust that existing
brian m. carlson sand...@crustytoothpaste.net writes:
In the longer term, it might be a more correct fix to teach
clear_commit_marks() to do the same committish to commit
dereferncing that is done in the revision traversal machinery, but
dereferencing. Otherwise, looks exactly like what I
On Mon, Jun 01, 2015 at 01:35:17PM -0700, Junio C Hamano wrote:
-- 8 --
From: Junio C Hamano gits...@pobox.com
Date: Mon, 1 Jun 2015 10:44:21 -0700
Subject: [PATCH] format-patch: do not feed tags to clear_commit_marks()
git format-patch --ignore-if-in-upstream A..B, when either A or B
is a
This looks good.
On Mon, Jun 1, 2015 at 2:22 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
On Mon, Jun 01, 2015 at 07:43:08AM -0400, Allen Hubbe wrote:
On May 31, 2015 at 6:29 PM, Eric Sunshine sunsh...@sunshineco.com wrote:
Sendmail aliases[1] supports expansion to a file (/path/name) or
Each ref namespace have their own separate branches, tags, and HEAD, so
when pushing to a namespace we need to make sure that there exists a
HEAD ref for the namespace, otherwise you will not be able to check out
the repo after cloning from a namespace
---
So, I have absolutely no clue where this
Ok, Thanks for all the informations
Notice that the pre-context lines in this second example is only one
line. Is it giving the same degree of safety if we rejected an
attempt to apply this patch only when the original does not have 10,
20, 30 and 40 in this order?
No. Because we are
On 22 May 2015 at 16:59, Junio C Hamano gits...@pobox.com wrote:
Roberto, isn't your threading of multi-patch series busted?
Why is 1/2 a follow-up to 2/2? Do you have a time-machine ;-)?
Oh, embarrassing, I better destroy the time-machine:
https://github.com/rtyley/submitgit/pull/5
This
1 - 100 of 125 matches
Mail list logo
