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
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer 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 *conflict;
> + st
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer 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 the end of the l
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer wrote:
> + if (!with_tree) {
> + memset(opts, 0, sizeof(*opts));
> + opts->pathspec = &pathspec_struct;
> + opts->read_staged = 1;
> + if (show_resolve_undo)
> + op
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:
http:
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer 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++) {
> -
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer 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
> index when it's tr
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer 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 = create_from_disk(disk_ce, &consumed, pr
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer 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 CE_MATCH_IGNORE_SK
On Sat, Jul 13, 2013 at 12:26 AM, Thomas Gummerer 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 perf tests and "ma
On Sat, Jul 13, 2013 at 3:20 AM, Stefan Beller
wrote:
> This is a regression test for a66e77eab70a08938fdc2227b7ada0f0465c6991
>
> Signed-off-by: Stefan Beller
> ---
> t/t4203-mailmap.sh | 41 +
> 1 file changed, 41 insertions(+)
>
> diff --git a/t/t4203-m
On Sun, Jul 14, 2013 at 4:25 AM, Jonathan Nieder 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. Update
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 tweake
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
> do
On Fri, Jul 12, 2013 at 3:52 PM, Junio C Hamano wrote:
>
> Jonathan Nieder 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 was written that way?
>
> N
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
Am 13.07.2013 22:08, schrieb Junio C Hamano:
> Junio C Hamano 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 t
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 IDEN
Stefan Beller 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 (which is good).
gi
Am 13.07.2013 20:14, schrieb Junio C Hamano:
> Johannes Sixt writes:
>>> Your table above makes this fail:
>>>
>>> git push --lockref topic
>>>
>>> and the user has to force it,
>>
>> Of course.
>>
>>> like this?
>>>
>>> git push --lockref --force topic ;# or alternatively
>>>
Junio C Hamano 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 of what
On Jul 12, 2013, at 13:58, Aaron Schrab wrote:
At 06:07 -0700 12 Jul 2013, "Kyle J. McKay" 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 config)
complet
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 07/13/2013 07:38 PM, Junio C Hamano wrote:
> Stefan Beller 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 i
Johannes Sixt 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:
>f
Stefan Beller 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 said commit, the new test
sti
From: "Kirill A. Korinskiy"
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
---
builtin/fetch.c | 4 +++-
builtin/remote.c | 13 +
remote.c | 2 ++
remote.h
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 whe
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 th
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 va
This is a regression test for a66e77eab70a08938fdc2227b7ada0f0465c6991
Signed-off-by: Stefan Beller
---
t/t4203-mailmap.sh | 41 +
1 file changed, 41 insertions(+)
diff --git a/t/t4203-mailmap.sh b/t/t4203-mailmap.sh
index 842b754..9ec87a2 100755
--- a/t/
31 matches
Mail list logo
