On 07/13/2013 02:35 AM, Eric Sunshine wrote:
Two tests in t4203-mailmap.sh set up the mapping b...@company.xx =
b...@company.xy in an apparent attempt to check that email address
remapping works as expected (in addition to name remapping which is also
tested). To test the remapping,
Am 12.07.2013 23:19, schrieb Junio C Hamano:
Johannes Sixt j...@kdbg.org writes:
We have three independent options that the user can choose in any
combination:
o --force given or not;
o --lockref semantics enabled or not;
o refspec with or without +;
and these two orthogonal
This is a regression test for a66e77eab70a08938fdc2227b7ada0f0465c6991
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
t/t4203-mailmap.sh | 41 +
1 file changed, 41 insertions(+)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index
Without git fetch --prune, remote-tracking branches for a branch
the other side already has removed will stay forever. Some people
want to always run git fetch --prune.
To accommodate users who want to either prune always or when fetching
from a particular remote, add two new configuration
On Tue, Jul 09, 2013 at 04:02:11PM +0530, Ramkumar Ramachandra wrote:
Hi,
I'm sending this out in the hope of attracting some reviews. It's an
unedited resend, and there were zero conflicts from the rebase.
I still don't like my callback idea. How about this? It's refactoring
a bit so that
I have a clone of linux.git with various stuff added to it (remotes for
'stable' and 'next', a bunch of local tags, and historical repositories
imported using `git replace`).
Yesterday, I noticed that `git describe`, built from git.git master
(v1.8.3.2-804-g0da7a53, gcc 4.8) would simply crash
From: Kirill A. Korinskiy ca...@catap.ru
Basic idea is a make behavior `git remote update --prune'
to `git remote update' as default to specify or all remotes repos.
Signed-off-by: Kirill A. Korinskiy ca...@catap.ru
---
builtin/fetch.c | 4 +++-
builtin/remote.c | 13 +
remote.c
Stefan Beller stefanbel...@googlemail.com writes:
This is a regression test for a66e77eab70a08938fdc2227b7ada0f0465c6991
Sorry, I do not quite get this.
If you apply the patch on top of the said commit before that commit, the
new test does not pass.
But if you apply the patch on top of the
Johannes Sixt j...@kdbg.org writes:
I am suggesting that +refspec would *not* override the match/mismatch
safety, but --force would.
OK.
I earlier did not read from your message that you wanted to change
+refspec to mean allow non-ff push, so the two entries in your
table:
On 07/13/2013 07:38 PM, Junio C Hamano wrote:
Stefan Beller stefanbel...@googlemail.com writes:
This is a regression test for a66e77eab70a08938fdc2227b7ada0f0465c6991
Sorry, I do not quite get this.
If you apply the patch on top of the said commit before that commit, the
new test does
On Jul 12, 2013, at 12:05, Jonathan Nieder wrote:
Junio C Hamano wrote:
The existing code triggers only when the configuration variable is
set to true. Once the variable is set to true in a more generic
configuration file (e.g. ~/.gitconfig), it cannot be overriden to
false in the
On Jul 12, 2013, at 13:58, Aaron Schrab wrote:
At 06:07 -0700 12 Jul 2013, Kyle J. McKay mack...@gmail.com wrote:
I don't think it's necessary to split the URL apart though.
Whatever URL the user gave to git on the command line (at some
point even if it's now stored as a remote setting in
Junio C Hamano gits...@pobox.com writes:
If --lockref automatically implies --allow-no-ff (the design in
the reposted patch), you cannot express that combination. But once
you use --lockref in such a situation , for the push to succeed,
you know that the push replaces not just _any_ ancestor
Stefan Beller stefanbel...@googlemail.com writes:
Indeed the patch tests for both bugs unintentionally.
I was puzzled because I do not think that is what is happening with
the posted patch.
If I drop the tip one from jc/mailmap-case-insensitivity and apply
this patch instead, the test passes
Dear Email Account Holder,
The Division of Information Technology (IT) is currently carrying out an
upgrade on our network
Warning!!! E-mail owner that refuses to update his or her E-mail, within
48hrs of receiving this warning will lose his or her E-mail permanently.
CONFIRM YOUR E-MAIL
Am 13.07.2013 22:08, schrieb Junio C Hamano:
Junio C Hamano gits...@pobox.com writes:
If --lockref automatically implies --allow-no-ff (the design in
the reposted patch), you cannot express that combination. But once
you use --lockref in such a situation , for the push to succeed,
you know
Hi,
Nguyễn Thái Ngọc Duy wrote:
Since 52fed6e (receive-pack: check connectivity before concluding git
push - 2011-09-02), receive-pack is prepared to deal with broken
push, a shallow push can't cause any corruption. Update the document
to reflect that.
Hmm, what happens when pushing to
On Fri, Jul 12, 2013 at 3:52 PM, Junio C Hamano gits...@pobox.com wrote:
Jonathan Nieder jrnie...@gmail.com writes:
FWIW the GIT_SSL_CERT_PASSWORD_PROTECTED envvar has a similar can
only enable behavior, but since it's documented, that's not as big
of a problem. Do you remember why it
Mark Levedahl wrote:
However, I don't understand why git would need to consume its own
output - If named pipes are really needed to use git-svn because
git-svn depends upon git feeding the same git process, then that
package should not be available on cygwin or any other platform that
does
Torsten Bögershausen wrote:
Disabling PIPE under cygwin seems to be the right thing to do,
or do I miss something ?
If fifos don't work on Cygwin, disabling that test prerequisite
is defintely the right thing to do. I was taking the opportunity to
find out whether and how git could be tweaked
On Sun, Jul 14, 2013 at 4:25 AM, Jonathan Nieder jrnie...@gmail.com wrote:
Hi,
Nguyễn Thái Ngọc Duy wrote:
Since 52fed6e (receive-pack: check connectivity before concluding git
push - 2011-09-02), receive-pack is prepared to deal with broken
push, a shallow push can't cause any corruption.
On Sat, Jul 13, 2013 at 3:20 AM, Stefan Beller
stefanbel...@googlemail.com wrote:
This is a regression test for a66e77eab70a08938fdc2227b7ada0f0465c6991
Signed-off-by: Stefan Beller stefanbel...@googlemail.com
---
t/t4203-mailmap.sh | 41 +
1 file
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
t/perf/p0003-index.sh| 59 +
t/t2104-update-index-skip-worktree.sh|1 +
For such a big code addition, the test part seems modest. Speaking
from my experience, I rarely run
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
@@ -489,8 +479,8 @@ extern void *read_blob_data_from_index(struct index_state
*, const char *, unsig
#define CE_MATCH_RACY_IS_DIRTY 02
/* do stat comparison even if CE_SKIP_WORKTREE is true */
#define
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
@@ -238,7 +245,6 @@ static int read_index_v2(struct index_state *istate, void
*mmap,
disk_ce = (struct ondisk_cache_entry *)((char *)mmap +
src_offset);
ce =
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
A partially read index file currently cannot be written to disk. Make
sure that never happens, by erroring out when a caller tries to change a
partially read index. The caller is responsible for reading the whole
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
+static int grep_cache(struct cache_entry *ce, void *cb_data)
{
- int hit = 0;
- int nr;
- read_cache();
+ struct grep_opts *opts = cb_data;
- for (nr = 0; nr active_nr; nr++) {
-
EEEAD 2013
The 2013 International Conference on Environment, Energy, Ecosystems and
Development
September 28-30, 2013, Venice, Italy
http://www.europment.org/venice2013/eeead.htm
Other Parallel Conferences in Venice, Italy in September 28-30 of 2013:
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
+ if (!with_tree) {
+ memset(opts, 0, sizeof(*opts));
+ opts-pathspec = pathspec_struct;
+ opts-read_staged = 1;
+ if (show_resolve_undo)
+
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
+== Directory offsets (diroffsets)
+
+ diroffset (32-bits): offset to the directory relative to the beginning
+of the index file. There are ndir + 1 offsets in the diroffset table,
+the last is pointing to
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer t.gumme...@gmail.com wrote:
+struct directory_entry {
+ struct directory_entry *next;
+ struct directory_entry *next_hash;
+ struct cache_entry *ce;
+ struct cache_entry *ce_last;
+ struct conflict_entry
I've alluded to this little project of mine on the mailing list before,
but I've never really announced it properly. So here we go...
git-imerge [1] is an open-source tool that helps you perform difficult
Git merges and rebases by allowing conflicts to be resolved
incrementally. The tool breaks
32 matches
Mail list logo
