* Re: regression in 92392b4
From: Johannes Schindelin @ 2008-07-23 11:37 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Björn Steinbrink, spearce, Git ML, Junio C Hamano
In-Reply-To: <20080723111931.GF15243@artemis.madism.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 3148 bytes --]
Hi,
On Wed, 23 Jul 2008, Pierre Habouzit wrote:
> On Wed, Jul 23, 2008 at 10:49:04AM +0000, Johannes Schindelin wrote:
>
> > On Wed, 23 Jul 2008, Björn Steinbrink wrote:
> >
> > > On 2008.07.23 01:17:45 +0200, Pierre Habouzit wrote:
> > > > Hi, here is a manual painful down-secting (opposed to a bisect ;P) I
> > > > did, since git in next cannot fetch on a regular basis for me. The
> > > > culprit seems to be commit 92392b4:
> > > >
> > > > ┌─(1:11)──<~/dev/scm/git 92392b4....>──
> > > > └[artemis] git fetch
> > > > remote: Counting objects: 461, done.
> > > > remote: Compressing objects: 100% (141/141), done.
> > > > remote: Total 263 (delta 227), reused 155 (delta 121)
> > > > Receiving objects: 100% (263/263), 95.55 KiB, done.
> > > > fatal: Out of memory, malloc failed
> > > > fatal: index-pack failed
> > > > [2] 16674 abort (core dumped) git fetch
> > > >
> > > > ┌─(1:12)──<~/dev/scm/git 92392b4....>──
> > > > └[artemis] git checkout -m HEAD~1; make git-index-pack
> > > > Previous HEAD position was 92392b4... index-pack: Honor core.deltaBaseCacheLimit when resolving deltas
> > > > HEAD is now at 03993e1... index-pack: Track the object_entry that creates each base_data
> > > > GIT_VERSION = 1.5.6.3.3.g03993
> > > > CC index-pack.o
> > > > LINK git-index-pack
> > > >
> > > > ┌─(1:12)──<~/dev/scm/git 03993e1....>──
> > > > └[artemis] git fetch
> > > > remote: Counting objects: 461, done.
> > > > remote: Compressing objects: 100% (141/141), done.
> > > > remote: Total 263 (delta 227), reused 155 (delta 121)
> > > > Receiving objects: 100% (263/263), 95.55 KiB, done.
> > > > Resolving deltas: 100% (227/227), completed with 153 local objects.
> > > > From git://git.kernel.org/pub/scm/git/git
> > > > 5ba2c22..0868a30 html -> origin/html
> > > > 2857e17..abeeabe man -> origin/man
> > > > 93310a4..95f8ebb master -> origin/master
> > > > 559998f..e8bf351 next -> origin/next
> > > >
> > > > You can see the commit sha's in the prompt. 03993e1 is fine, 92392b4 is
> > > > broken, I've absolutely no clue about what happens.
> > > >
> > > > All I can say is that at some point in get_data_from_pack, obj[1].idx
> > > > points to something that is *not* a sha so it's probably corrupted.
> > > > (from index-pack.c).
> > >
> > > Here's how to reproduce:
> >
> > Funny. That does not reproduce the bug here at all.
> >
> > But then, it is unsurprising, since both Pierre and me did something
> > similar yesterday, fetching _just_ the pre-fetch refs into a freshly
> > initted Git repository, and then fetching from kernel.org.
> >
> > Tested on x86_64.
>
> I can reproduce on x86_64 here.
Well, I cannot. However, I get some pread issue on i686. To be nice to
kernel.org, I downloaded the pack in question:
http://pacific.mpi-cbg.de/git/thin-pack.pack
You should be able to reproduce the behavior by piping this into
git-index-pack --stdin -v --fix-thin --keep=fetch-pack --pack_header=2,263
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Dmitry Potapov @ 2008-07-23 11:40 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Schindelin, Junio C Hamano, git
In-Reply-To: <719E03C0-E8C3-4C35-AE9C-9BD5A7BCDF03@zib.de>
On Wed, Jul 23, 2008 at 07:49:20AM +0200, Steffen Prohaska wrote:
>
> On Jul 23, 2008, at 3:31 AM, Johannes Schindelin wrote:
>
> >
> >- if ((action == CRLF_BINARY) || !auto_crlf || !len)
> >+ if ((action == CRLF_BINARY) || (!auto_crlf && action < 0) || !len)
>
> I think we should strictly follow the documentation, so this should read
>
> + if ((action == CRLF_BINARY) || (!auto_crlf && action !=
> CRLF_INPUT) || !len)
Well, your expression is correct if we choose to strictly follow to what
the current documentation says, but it is not well written in this place,
and, more importantly, I don't see any use case where you would want to
set crlf=input in .gitattributes, because it is shared among users on
different platforms. What you want to specify in it is whether a file is
text or binary. If crlf is set, it means a text file; if unset, it is a
binary file. Regardless of what autocrlf value, I don't see why a text
file should be checked in with CRs. So, Dscho's patch makes more sense
to me. This requires correction to the documentation though:
diff --git a/Documentation/gitattributes.txt b/Documentation/gitattributes.txt
index d7b4114..448857b 100644
--- a/Documentation/gitattributes.txt
+++ b/Documentation/gitattributes.txt
@@ -99,9 +99,9 @@ This attribute controls the line-ending convention.
Set::
Setting the `crlf` attribute on a path is meant to mark
- the path as a "text" file. 'core.autocrlf' conversion
- takes place without guessing the content type by
- inspection.
+ the path as a "text" file. Line endings in a text file
+ are converted to LF upon checkin, and if 'core.autocrlf'
+ is true then to CRLF upon checkout.
Unset::
Dmitry
^ permalink raw reply related
* [PATCH] checkout: mention '--' in the docs
From: SZEDER Gábor @ 2008-07-23 11:49 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit, gitster, SZEDER Gábor
In-Reply-To: <1216808133-31919-2-git-send-email-madcoder@debian.org>
'git checkout' uses '--' to separate options from paths, but it was not
mentioned in the documentation
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
And here are two small changes related to 'git checkout --'.
Documentation/git-checkout.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 2abfbda..5aa69c0 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git checkout' [-q] [-f] [[--track | --no-track] -b <new_branch> [-l]] [-m] [<branch>]
-'git checkout' [<tree-ish>] <paths>...
+'git checkout' [<tree-ish>] [--] <paths>...
DESCRIPTION
-----------
--
1.6.0.rc0.35.gb83a7
^ permalink raw reply related
* [PATCH] bash: offer only paths after '--' for 'git checkout'
From: SZEDER Gábor @ 2008-07-23 11:49 UTC (permalink / raw)
To: git; +Cc: Pierre Habouzit, gitster, SZEDER Gábor
In-Reply-To: <1216813762-23511-1-git-send-email-szeder@ira.uka.de>
Commit d773c631 (bash: offer only paths after '--', 2008-07-08) did the
same for several other git commands, but 'git checkout' went unnoticed.
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
---
contrib/completion/git-completion.bash | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 2edb341..9b51fda 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -626,6 +626,8 @@ _git_bundle ()
_git_checkout ()
{
+ __git_has_doubledash && return
+
__gitcomp "$(__git_refs)"
}
--
1.6.0.rc0.35.gb83a7
^ permalink raw reply related
* Re: regression in 92392b4
From: Pierre Habouzit @ 2008-07-23 11:50 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Björn Steinbrink, spearce, Git ML, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807231235150.8986@racer>
[-- Attachment #1: Type: text/plain, Size: 1438 bytes --]
On Wed, Jul 23, 2008 at 11:37:00AM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 23 Jul 2008, Pierre Habouzit wrote:
>
> > On Wed, Jul 23, 2008 at 10:49:04AM +0000, Johannes Schindelin wrote:
> >
> > > On Wed, 23 Jul 2008, Björn Steinbrink wrote:
> > > Funny. That does not reproduce the bug here at all.
> > >
> > > But then, it is unsurprising, since both Pierre and me did something
> > > similar yesterday, fetching _just_ the pre-fetch refs into a freshly
> > > initted Git repository, and then fetching from kernel.org.
> > >
> > > Tested on x86_64.
> >
> > I can reproduce on x86_64 here.
>
> Well, I cannot. However, I get some pread issue on i686. To be nice to
> kernel.org, I downloaded the pack in question:
>
> http://pacific.mpi-cbg.de/git/thin-pack.pack
>
> You should be able to reproduce the behavior by piping this into
>
> git-index-pack --stdin -v --fix-thin --keep=fetch-pack --pack_header=2,263
I can reproduce. Funily enough, I just happened to see that I have
core.deltabasecachelimit = 0 in my git.git repository... which I
probably used meaning -1 but oh well. The bottom line is that the
pruning algorithm likely removes a pointer we still have a pointer to
somewhere...
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-svn does not seems to work with crlf convertion enabled.
From: Alexander Litvinov @ 2008-07-23 11:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807231117290.2830@eeepc-johanness>
> On Wed, 23 Jul 2008, Alexander Litvinov wrote:
> > In short: I can't clone svn repo into git when crlf convertion is
> > activated.
>
> This is a known issue, but since nobody with that itch seems to care
> enough to fix it, I doubt it will ever be fixed.
That is a bad news for me. Anyway I will spend some time at holidays during
digging this bug.
^ permalink raw reply
* Re: regression in 92392b4
From: Björn Steinbrink @ 2008-07-23 12:00 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pierre Habouzit, spearce, Git ML, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807231235150.8986@racer>
On 2008.07.23 12:37:00 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 23 Jul 2008, Pierre Habouzit wrote:
>
> > On Wed, Jul 23, 2008 at 10:49:04AM +0000, Johannes Schindelin wrote:
> >
> > > On Wed, 23 Jul 2008, Björn Steinbrink wrote:
> > >
> > > > On 2008.07.23 01:17:45 +0200, Pierre Habouzit wrote:
> > > > > Hi, here is a manual painful down-secting (opposed to a bisect ;P) I
> > > > > did, since git in next cannot fetch on a regular basis for me. The
> > > > > culprit seems to be commit 92392b4:
> > > > >
> > > > > ┌─(1:11)──<~/dev/scm/git 92392b4....>──
> > > > > └[artemis] git fetch
> > > > > remote: Counting objects: 461, done.
> > > > > remote: Compressing objects: 100% (141/141), done.
> > > > > remote: Total 263 (delta 227), reused 155 (delta 121)
> > > > > Receiving objects: 100% (263/263), 95.55 KiB, done.
> > > > > fatal: Out of memory, malloc failed
> > > > > fatal: index-pack failed
> > > > > [2] 16674 abort (core dumped) git fetch
> > > > >
> > > > > ┌─(1:12)──<~/dev/scm/git 92392b4....>──
> > > > > └[artemis] git checkout -m HEAD~1; make git-index-pack
> > > > > Previous HEAD position was 92392b4... index-pack: Honor core.deltaBaseCacheLimit when resolving deltas
> > > > > HEAD is now at 03993e1... index-pack: Track the object_entry that creates each base_data
> > > > > GIT_VERSION = 1.5.6.3.3.g03993
> > > > > CC index-pack.o
> > > > > LINK git-index-pack
> > > > >
> > > > > ┌─(1:12)──<~/dev/scm/git 03993e1....>──
> > > > > └[artemis] git fetch
> > > > > remote: Counting objects: 461, done.
> > > > > remote: Compressing objects: 100% (141/141), done.
> > > > > remote: Total 263 (delta 227), reused 155 (delta 121)
> > > > > Receiving objects: 100% (263/263), 95.55 KiB, done.
> > > > > Resolving deltas: 100% (227/227), completed with 153 local objects.
> > > > > From git://git.kernel.org/pub/scm/git/git
> > > > > 5ba2c22..0868a30 html -> origin/html
> > > > > 2857e17..abeeabe man -> origin/man
> > > > > 93310a4..95f8ebb master -> origin/master
> > > > > 559998f..e8bf351 next -> origin/next
> > > > >
> > > > > You can see the commit sha's in the prompt. 03993e1 is fine, 92392b4 is
> > > > > broken, I've absolutely no clue about what happens.
> > > > >
> > > > > All I can say is that at some point in get_data_from_pack, obj[1].idx
> > > > > points to something that is *not* a sha so it's probably corrupted.
> > > > > (from index-pack.c).
> > > >
> > > > Here's how to reproduce:
> > >
> > > Funny. That does not reproduce the bug here at all.
> > >
> > > But then, it is unsurprising, since both Pierre and me did something
> > > similar yesterday, fetching _just_ the pre-fetch refs into a freshly
> > > initted Git repository, and then fetching from kernel.org.
> > >
> > > Tested on x86_64.
> >
> > I can reproduce on x86_64 here.
>
> Well, I cannot. However, I get some pread issue on i686. To be nice to
> kernel.org, I downloaded the pack in question:
>
> http://pacific.mpi-cbg.de/git/thin-pack.pack
>
> You should be able to reproduce the behavior by piping this into
>
> git-index-pack --stdin -v --fix-thin --keep=fetch-pack --pack_header=2,263
OK, that gave me a seemingly sane backtrace. What seems to happen (AFA
my limited knowledge tells me):
In fix_unresolved_deltas, we read base_obj from an existing pack, other
than the one we're reading. We then link that object to the base cache.
Then in resolve_delta, we create the "result" base_data object and link
that one, too. Now this triggers the pruning, and because the cache is
so small, we prune the object that we read from the existing pack! Fast
forward a few function calls, we end up in get_base_data trying to
re-read the data for that object, but this time from the pack that we
got on stdin. And boom it goes.
Does that make any sense to you?
Björn
^ permalink raw reply
* Re: [PATCH] rebase -i: only automatically amend commit if HEAD did not change
From: Dmitry Potapov @ 2008-07-23 12:01 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Johannes Schindelin, git, gitster
In-Reply-To: <32541b130807221522r2a43c49cl6400f00dbe7451a0@mail.gmail.com>
On Tue, Jul 22, 2008 at 06:22:34PM -0400, Avery Pennarun wrote:
>
> This patch is perhaps a symptom of something I've been meaning to ask
> about for a while.
>
> Why doesn't "edit" just stage the commit and not auto-commit it at
> all? That way an amend would *never* be necessary, and rebase
> --continue would always do a commit -a (if there was anything left to
> commit).
Actually, it would be better to refuse to continue if there are unstaged
changes in the work tree, and if all changes are staged then just do git
commit.
> The special case fixed by this patch would thus not be
> needed.
>
> It would also make it more obvious how to remove files from a commit,
> for example, without having to learn about "git reset". For that
> matter, you wouldn't have to learn about "git commit --amend" either,
> and it would save typing.
It would not only save typing, but also help to avoid costly mistakes
where users, being taught to use "git commit --amend" after editing
during git-rebase, fire this command automatically after a conflict
resolution and get two commits accidently squashed.
So, I completely agree that the current auto-commit behavior is not very
user friendly...
Dmitry
^ permalink raw reply
* [PATCH] index-pack: never prune base_cache.
From: Pierre Habouzit @ 2008-07-23 12:11 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Johannes Schindelin, spearce, Git ML, Junio C Hamano
In-Reply-To: <20080723120045.GA21274@atjola.homenet>
It may belong to something (stdin) that is consumed.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
On Wed, Jul 23, 2008 at 12:00:45PM +0000, Björn Steinbrink wrote:
> On 2008.07.23 12:37:00 +0100, Johannes Schindelin wrote:
> > Hi,
> >
> > Well, I cannot. However, I get some pread issue on i686. To be nice to
> > kernel.org, I downloaded the pack in question:
> >
> > http://pacific.mpi-cbg.de/git/thin-pack.pack
> >
> > You should be able to reproduce the behavior by piping this into
> >
> > git-index-pack --stdin -v --fix-thin --keep=fetch-pack --pack_header=2,263
>
> OK, that gave me a seemingly sane backtrace. What seems to happen (AFA
> my limited knowledge tells me):
>
> In fix_unresolved_deltas, we read base_obj from an existing pack, other
> than the one we're reading. We then link that object to the base cache.
>
> Then in resolve_delta, we create the "result" base_data object and link
> that one, too. Now this triggers the pruning, and because the cache is
> so small, we prune the object that we read from the existing pack! Fast
> forward a few function calls, we end up in get_base_data trying to
> re-read the data for that object, but this time from the pack that we
> got on stdin. And boom it goes.
>
> Does that make any sense to you?
Yes, that's obvious, the pack that we read from stdin is consumed, we
should *NEVER* prune base_cache. And indeed that little patch works for
me.
index-pack.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/index-pack.c b/index-pack.c
index ac20a46..eb81ed4 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -227,7 +227,7 @@ static void prune_base_data(struct base_data *retain)
for (b = base_cache;
base_cache_used > delta_base_cache_limit && b;
b = b->child) {
- if (b->data && b != retain) {
+ if (b != base_cache && b->data && b != retain) {
free(b->data);
b->data = NULL;
base_cache_used -= b->size;
--
1.6.0.rc0.155.ga0442.dirty
^ permalink raw reply related
* Re: [PATCH] Rename ".dotest/" to ".git/rebase" and ".dotest-merge" to "rebase-merge"
From: Olivier Marin @ 2008-07-23 12:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: Theodore Tso, Nanako Shiraishi, Johannes Schindelin,
René Scharfe, Stephan Beyer, Joe Fiorini, git, Jari Aalto
In-Reply-To: <7vk5fdiheh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano a écrit :
>
>> diff --git a/git-am.sh b/git-am.sh
>> index 60aaa4a..864c77e 100755
>> --- a/git-am.sh
>> +++ b/git-am.sh
>> @@ -202,8 +202,15 @@ then
>> die "previous rebase directory $dotest still exists but mbox given."
>> resume=yes
>>
>> - case "$abort" in
>> - t)
>> + case "$skip,$abort" in
>> + t,)
>> + git rerere clear
>> + git read-tree --reset -u HEAD HEAD
>> + orig_head=$(cat "$GIT_DIR/ORIG_HEAD")
>> + git reset HEAD
>> + git update-ref ORIG_HEAD $orig_head
>> + ;;
>
> Sorry, I do not quite understand what this reset after the read-tree dance
> is trying to do; you have already reset the index to the tree in HEAD when
> you cleared the change involved in the patch application with that
> two-tree form of read-tree.
I add reset to unstage paths with no conflict that are left behind. Perhaps
read-tree can clear those paths as well but I do not know how, the man page
is hard to follow.
--
Olivier.
^ permalink raw reply
* Re: [PATCH] index-pack: never prune base_cache.
From: Björn Steinbrink @ 2008-07-23 12:52 UTC (permalink / raw)
To: Pierre Habouzit, Johannes Schindelin, spearce, Git ML,
Junio C Hamano
In-Reply-To: <20080723121118.GA20614@artemis.madism.org>
On 2008.07.23 14:11:18 +0200, Pierre Habouzit wrote:
> It may belong to something (stdin) that is consumed.
Probably thanks to me, babbling about stdin without having a clue what
I'm talking about, that rationale is wrong.
We may not prune base_cache since that object might come from a
different pack than the one that we are processing. In such a case, we
would try to restore the data for that object from the pack we're
processing and fail miserably.
The patch itself should be fine.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
>
> On Wed, Jul 23, 2008 at 12:00:45PM +0000, Björn Steinbrink wrote:
> > On 2008.07.23 12:37:00 +0100, Johannes Schindelin wrote:
> > > Hi,
> > >
> > > Well, I cannot. However, I get some pread issue on i686. To be nice to
> > > kernel.org, I downloaded the pack in question:
> > >
> > > http://pacific.mpi-cbg.de/git/thin-pack.pack
> > >
> > > You should be able to reproduce the behavior by piping this into
> > >
> > > git-index-pack --stdin -v --fix-thin --keep=fetch-pack --pack_header=2,263
> >
> > OK, that gave me a seemingly sane backtrace. What seems to happen (AFA
> > my limited knowledge tells me):
> >
> > In fix_unresolved_deltas, we read base_obj from an existing pack, other
> > than the one we're reading. We then link that object to the base cache.
> >
> > Then in resolve_delta, we create the "result" base_data object and link
> > that one, too. Now this triggers the pruning, and because the cache is
> > so small, we prune the object that we read from the existing pack! Fast
> > forward a few function calls, we end up in get_base_data trying to
> > re-read the data for that object, but this time from the pack that we
> > got on stdin. And boom it goes.
> >
> > Does that make any sense to you?
>
> Yes, that's obvious, the pack that we read from stdin is consumed, we
> should *NEVER* prune base_cache. And indeed that little patch works for
> me.
>
> index-pack.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/index-pack.c b/index-pack.c
> index ac20a46..eb81ed4 100644
> --- a/index-pack.c
> +++ b/index-pack.c
> @@ -227,7 +227,7 @@ static void prune_base_data(struct base_data *retain)
> for (b = base_cache;
> base_cache_used > delta_base_cache_limit && b;
> b = b->child) {
> - if (b->data && b != retain) {
> + if (b != base_cache && b->data && b != retain) {
> free(b->data);
> b->data = NULL;
> base_cache_used -= b->size;
^ permalink raw reply
* Re: git-svn does not seems to work with crlf convertion enabled.
From: Johannes Schindelin @ 2008-07-23 12:57 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <200807231852.10206.litvinov2004@gmail.com>
Hi,
On Wed, 23 Jul 2008, Alexander Litvinov wrote:
> > On Wed, 23 Jul 2008, Alexander Litvinov wrote:
> > > In short: I can't clone svn repo into git when crlf convertion is
> > > activated.
> >
> > This is a known issue, but since nobody with that itch seems to care
> > enough to fix it, I doubt it will ever be fixed.
>
> That is a bad news for me. Anyway I will spend some time at holidays
> during digging this bug.
Note that you will have to do your digging using msysGit (i.e. the
developer's pack, not the installer for plain Git), since git-svn will be
removed from the next official "Windows Git" release, due to lack of
fixers.
Ciao,
Dscho
^ permalink raw reply
* q: faster way to integrate/merge lots of topic branches?
From: Ingo Molnar @ 2008-07-23 13:05 UTC (permalink / raw)
To: git
I've got the following, possibly stupid question: is there a way to
merge a healthy number of topic branches into the master branch in a
quicker way, when most of the branches are already merged up?
Right now i've got something like this scripted up:
for B in $(git-branch | cut -c3- ); do git-merge $B; done
It takes a lot of time to run on even a 3.45GHz box:
real 0m53.228s
user 0m41.134s
sys 0m11.405s
I just had a workflow incident where i forgot that this script was
running in one window (53 seconds are a _long_ time to start doing some
other stuff :-), i switched branches and the script merrily chugged away
merging branches into a topic branch i did not intend.
It iterates over 140 branches - but all of them are already merged up.
Anyone can simulate it by switching to the linus/master branch of the
current Linux kernel tree, and doing:
time for ((i=0; i<140; i++)); do git-merge v2.6.26; done
real 1m26.397s
user 1m10.048s
sys 0m13.944s
One could argue that determining whether it's all merged up already is a
complex task, but but even this seemingly trivial merge of HEAD into
HEAD is quite slow:
time for ((i=0; i<140; i++)); do git-merge HEAD; done
real 0m17.871s
user 0m8.977s
sys 0m8.396s
I'm wondering whether there are tricks to speed this up. The real script
i'm using is much longer and obscured with boring details like errors,
conflicts, etc. - but the above is the gist of it. (and that is what
makes it slow primarily)
Using a speculative Octopus might be one approach, but that runs into
the octopus merge limitation at 24 branches, and it also is quite slow
as well. (and is not equivalent to the serial merge of 140 branches)
I have thought of using the last CommitDate of the topic branch and
compare it with the last CommitDate of the master branch [and i can
trust those values] - that would be a lot faster - but maybe i'm missing
something trivial that makes that approach unworkable. It would also be
nice to have a builtin shortcut for that instead of having to go via
"git-log --pretty=fuller" to dump the CommitDate field.
builtin-integrate.c perhaps? ;-)
Ingo
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Jakub Narebski @ 2008-07-23 13:08 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807231128090.2830@eeepc-johanness>
On Wed, 23 Jul 2008, Johannes Schindelin wrote:
> On Wed, 23 Jul 2008, Jakub Narebski wrote:
>
> Some people prefer to stay anonymous, so I think email is out.
>
> > 04. Which programming languages you are proficient with?
> > (The choices include programming languages used by git)
> > (zero or more: multiple choice)
> > - C, shell, Perl, Python, Tcl/Tk
> > + (should we include other languages, like C++, Java, PHP,
> > Ruby,...?)
>
> Yes, I think this should be a long list.
I'd rather not have a "laundry list" of languages. I have put C++
because QGit uses it, Java because of egit/jgit, PHP for web
interfaces, Ruby because of GitHub and because of Ruby comminity
choosing Git. I should perhaps add Emacs Lisp, HTML+CSS and
JavaScript here. What other languages should be considered?
> > 07. What helped you most in learning to use it?
> > (free form question)
>
> Is it possible to have multiple choice, with "other" (free-form)? Then
> I'd suggest:
>
> Colleague/Instructor, User Manual, Manpages, Tutorials, Tutorials
> (elsewhere; not in git.git), Mailing list, IRC, Git Wiki, Other.
By "Tutorials (elsewhere; not in git.git)" you mean here many various
"git guide" pages, like "Git for Computer Scientists", "Git Magic",
etc.?
I'm not sure about having multiple choice vs. free-form question here.
Multiple choice is easier to analyze, especially if one would want
histogram of replies... but free form is more rich. But perhaps
multiple choice with free-form "other" choice would be the best?
Besides proposed choices limit person filling the survey to single
understanding of "what helped you in learning to use Git", which
can be also understood as asking for list of features helping with
learning Git, not only list of documentation and such.
> > 08. What did you find hardest in learning Git?
> > What did you find harderst in using Git?
>
> s/harderst/hardest.
>
> > (free form question)
>
> Again, I'd suggest a multiple choice + Other:
>
> The amount of commands, the amount of options, the index (AKA
> staging), branching, user interface, bugs, Other.
Here it can be hard to come up with good list of choices. For example
among responses in 2007 survey there were 'inconsistent commands',
'obtuse command messages', 'insufficient/hard to use documentation',
and many more.
I'm not sure if troubles with coming with extensive but not too large
list of options for this question is worth it; I think that we need
only list of responses, and not number of responses (perhaps mentioning
which one occur [much] more frequently).
> > Other SCMs (shortened compared with 2007 survey)
> >
> > 10. What other SCM did or do you use?
> > (zero or more: multiple choice)
> > - CVS, Subversion, GNU Arch or arch clone (ArX, tla, ...),
> > Bazaar-NG, Darcs, Mercurial, Monotone, SVK, AccuRev, Perforce,
> > BitKeeper, ClearCase, MS Visual Source Safe, MS Visual Studio
> > Team System, custom, other(*)
>
> PVCS seems to be pretty popular, too.
O.K., I'll add it. I think I'd better add RCS too.
> > 11. Why did you choose Git? (if you use Git)
> > What do you like about using Git?
> > (free form, not to be tabulated)
>
> Again, to avoid hassles with free-form:
>
> Mandatory: work, mandatory: open source project I am participating
> in, speed, scalability, It's What Linus Uses, Other.
Free form has some hassles. Because here histogram of responses might
be interesting, perhaps it would be good to use multiple choice here.
I would add "features" and/or "unique features" to the list, and also
perhaps "being popular/hype".
> > 12. Why did you choose other SCMs? (if you use other SCMs)
> > What do you like about using other SCMs?
> > Note: please write name of SCMs you are talking about.
> > (free form, not to be tabulated).
>
> Again:
>
> ease-of use, simplicity, existing project uses it, I Do Not Like
> Linus, Other
Again: free form has some hassles, but so does coming up with good
choice of fixed answers in multiple choice question. I'll add
"ease to install on MS Windows" (or something like that) if we decide
to have this question multiple choice.
> > 15. What operating system do you use Git on?
> > (one or more: multiple choice, as one can use more than one OS)
> > - Linux, *BSD (FreeBSD, OpenBSD, etc.), MS Windows/Cygwin,
> > MS Windows/msysGit, MacOS X, other UNIX, other
>
> You should include "Dunno", which gets automatically mapped to "MS
> Windows/msysGit" ;-)
>
> > 19. How do you publish/propagate your changes?
> > (zero or more: multiple choice)
> > - push, pull request, format-patch + email, bundle, other
>
> git svn
>
> You might laugh, but it is a sad fact that some guy promotes "Using Git
> with Google Code" by using git-svn to drive their crappy Subversion.
O.K. I'll add "git-svn (or other to foreign SCM)".
> > 22. How does Git compare to other SCM tools you have used?
> > - worse/equal (or comparable)/better
> > 23. What would you most like to see improved about Git?
> > (features, bugs, plug-ins, documentation, ...)
>
> Maybe here should be another question "What are the most useful features
> of Git?" but maybe that is covered by earlier questions.
I think it is. I'd rather try to reduce number of questions...
> > 24. If you want to see Git more widely used, what do you
> > think we could do to make this happen?
> > + Is this question necessary/useful? Do we need wider adoption?
>
> I agree with Junio: this is not so interesting for us; we are no company,
> and we have no sales department who could wank of on these answers.
I'll remove it, then.
> > 27. Which of the following features do you use?
> > (zero or more: multiple choice)
> > - git-gui or other commit tool, gitk or other history viewer, patch
> > management interface (e.g. StGIT), bundle, eol conversion,
>
> For our Windows friends, we should add " (crlf)" to the last item.
Right. Thanks.
> > 42. Do you find traffic levels on Git mailing list OK.
> > - yes/no? (optional)
>
> /too low? *ducksandrunsforcover*
???
> > 44. If yes, do you find IRC channel useful?
> > - yes/no (optional)
>
> /somewhat. Even if I would be the only one choosing that option.
I'm sorry about that: I have forgot that this and all similar questions
had triple choice: yes/no/somewhat in the final version of 2007 survey.
I'll correct it.
> > 45. Did you have problems getting GIT help on mailing list or
> > on IRC channel? What were it? What could be improved?
> > (free form)
>
> Yeah, I know who will answer to that, and what... "yaddayadda very
> unfriendly yaddayadda especially that Johannes guy yaddayadda" (you know
> who you are)... *lol*
:-)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] index-pack: never prune base_cache.
From: Johannes Schindelin @ 2008-07-23 13:09 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Pierre Habouzit, spearce, Git ML, Junio C Hamano
In-Reply-To: <20080723125226.GA11679@atjola.homenet>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1097 bytes --]
Hi,
On Wed, 23 Jul 2008, Björn Steinbrink wrote:
> On 2008.07.23 14:11:18 +0200, Pierre Habouzit wrote:
> > It may belong to something (stdin) that is consumed.
>
> Probably thanks to me, babbling about stdin without having a clue what
> I'm talking about, that rationale is wrong.
>
> We may not prune base_cache since that object might come from a
> different pack than the one that we are processing. In such a case, we
> would try to restore the data for that object from the pack we're
> processing and fail miserably.
Then the proper fix would be to load the object from that pack again.
> The patch itself should be fine.
No, since it opens the whole issue of memory explosion again, the same
issue Shawn's original patch tried to fix.
Ciao,
Dscho
P.S.: Could you please, please, please cull the part you are not
responding to? This mailing list is read by more than 50 people. If you
sum up the time it takes them to realize that that quoted part was
irrelevant, I am sure you will end up with a larger number of minutes than
it would take you to just delete it.
Thanks.
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Ingo Molnar @ 2008-07-23 13:17 UTC (permalink / raw)
To: git
In-Reply-To: <20080723130518.GA17462@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> I have thought of using the last CommitDate of the topic branch and
> compare it with the last CommitDate of the master branch [and i can
> trust those values] - that would be a lot faster - but maybe i'm
> missing something trivial that makes that approach unworkable. It
> would also be nice to have a builtin shortcut for that instead of
> having to go via "git-log --pretty=fuller" to dump the CommitDate
> field.
hm, this method would be fragile if done purely within my integration
script, as the timestamp of the head would have to be updated
atomically, while always merging all the topic branches in one such
transaction. (so that the timestamps do not get out of sync and a topic
branch is not skipped by accident)
So i guess it's better to just create a separate .git/refs/merge-cache/
hierarchy with timestamps of last merged branches and their head sha1
... but maybe i'm banging on open doors?
Ingo
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Johannes Schindelin @ 2008-07-23 13:18 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <200807231508.42334.jnareb@gmail.com>
Hi,
On Wed, 23 Jul 2008, Jakub Narebski wrote:
> On Wed, 23 Jul 2008, Johannes Schindelin wrote:
> > On Wed, 23 Jul 2008, Jakub Narebski wrote:
> >
> > Some people prefer to stay anonymous, so I think email is out.
> >
> > > 04. Which programming languages you are proficient with?
> > > (The choices include programming languages used by git)
> > > (zero or more: multiple choice)
> > > - C, shell, Perl, Python, Tcl/Tk
> > > + (should we include other languages, like C++, Java, PHP,
> > > Ruby,...?)
> >
> > Yes, I think this should be a long list.
>
> I'd rather not have a "laundry list" of languages. I have put C++
> because QGit uses it, Java because of egit/jgit, PHP for web
> interfaces, Ruby because of GitHub and because of Ruby comminity
> choosing Git. I should perhaps add Emacs Lisp, HTML+CSS and
> JavaScript here. What other languages should be considered?
C# at least, since we had one (pretty unsuccessful) attempt at
reimplementing Git in it.
> > > 07. What helped you most in learning to use it?
> > > (free form question)
> >
> > Is it possible to have multiple choice, with "other" (free-form)?
>
> But perhaps multiple choice with free-form "other" choice would be the
> best?
Uhm, yes, you are right. Why not have multiple choice, with "other")
(free-form)?
> > > 42. Do you find traffic levels on Git mailing list OK.
> > > - yes/no? (optional)
> >
> > /too low? *ducksandrunsforcover*
>
> ???
Well, was worth a try ;-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] index-pack: never prune base_cache.
From: Pierre Habouzit @ 2008-07-23 13:20 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Björn Steinbrink, spearce, Git ML, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807231407040.8986@racer>
[-- Attachment #1: Type: text/plain, Size: 1077 bytes --]
On Wed, Jul 23, 2008 at 01:09:40PM +0000, Johannes Schindelin wrote:
> On Wed, 23 Jul 2008, Björn Steinbrink wrote:
> > The patch itself should be fine.
>
> No, since it opens the whole issue of memory explosion again, the same
> issue Shawn's original patch tried to fix.
No it won't. Indeed the issue is with fix_unresolved_deltas that
sometimes put at the root of the chain (in base_cache) something that
comes from our store, not the pack we are writing. Then starts a delta
chain resolution.
It won't explode in memory at all, we just keep the first data of a
delta chain in memory, that's all. It indeed consumes more memory, but
we talk about *one* single object per delta chain because we're too lazy
to memorize where it comes from. It's probably not much of an explosion.
We also waste that object even when it's from our own pack. Well, I'd
say "too bad".
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Andreas Ericsson @ 2008-07-23 13:40 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080723130518.GA17462@elte.hu>
Ingo Molnar wrote:
> I've got the following, possibly stupid question: is there a way to
> merge a healthy number of topic branches into the master branch in a
> quicker way, when most of the branches are already merged up?
>
> Right now i've got something like this scripted up:
>
> for B in $(git-branch | cut -c3- ); do git-merge $B; done
>
> It takes a lot of time to run on even a 3.45GHz box:
>
> real 0m53.228s
> user 0m41.134s
> sys 0m11.405s
>
> I just had a workflow incident where i forgot that this script was
> running in one window (53 seconds are a _long_ time to start doing some
> other stuff :-), i switched branches and the script merrily chugged away
> merging branches into a topic branch i did not intend.
>
> It iterates over 140 branches - but all of them are already merged up.
>
With the builtin merge (which is in next), this should be doable with
an octopus merge, which will eliminate the branches that are already
fully merged, resulting in a less-than-140-way merge (thank gods...).
It also doesn't have the 24-way cap that the scripted version suffers
from.
If it does a good job at your rather extreme use-case, I'd say it's
good enough for 'master' pretty soon :-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] index-pack: never prune base_cache.
From: Björn Steinbrink @ 2008-07-23 13:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Pierre Habouzit, spearce, Git ML, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807231407040.8986@racer>
On 2008.07.23 14:09:40 +0100, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 23 Jul 2008, Björn Steinbrink wrote:
>
> > On 2008.07.23 14:11:18 +0200, Pierre Habouzit wrote:
> > > It may belong to something (stdin) that is consumed.
> >
> > Probably thanks to me, babbling about stdin without having a clue what
> > I'm talking about, that rationale is wrong.
> >
> > We may not prune base_cache since that object might come from a
> > different pack than the one that we are processing. In such a case, we
> > would try to restore the data for that object from the pack we're
> > processing and fail miserably.
>
> Then the proper fix would be to load the object from that pack again.
Actually, my analysis was total bullshit. Right after reading the object
from the foreign pack, we also call append_obj_to_pack, so we are
actually able to reread that object just fine. The real issue seems to
be that we just forget to initialize some fields.
This patch fixes the issue for me, but I guess it's not quite the right
way to do it, pure guesswork.
Björn
---
diff --git a/index-pack.c b/index-pack.c
index ac20a46..33ba8ef 100644
--- a/index-pack.c
+++ b/index-pack.c
@@ -699,6 +699,9 @@ static struct object_entry *append_obj_to_pack(
write_or_die(output_fd, header, n);
obj[0].idx.crc32 = crc32(0, Z_NULL, 0);
obj[0].idx.crc32 = crc32(obj[0].idx.crc32, header, n);
+ obj[0].hdr_size = n;
+ obj[0].type = type;
+ obj[0].size = size;
obj[1].idx.offset = obj[0].idx.offset + n;
obj[1].idx.offset += write_compressed(output_fd, buf, size, &obj[0].idx.crc32);
hashcpy(obj->idx.sha1, sha1);
^ permalink raw reply related
* Re: [PATCH] index-pack: never prune base_cache.
From: Johannes Schindelin @ 2008-07-23 13:46 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Björn Steinbrink, spearce, Git ML, Junio C Hamano
In-Reply-To: <20080723132031.GC20614@artemis.madism.org>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1220 bytes --]
Hi,
On Wed, 23 Jul 2008, Pierre Habouzit wrote:
> On Wed, Jul 23, 2008 at 01:09:40PM +0000, Johannes Schindelin wrote:
> > On Wed, 23 Jul 2008, Björn Steinbrink wrote:
> > > The patch itself should be fine.
> >
> > No, since it opens the whole issue of memory explosion again, the same
> > issue Shawn's original patch tried to fix.
>
> No it won't. Indeed the issue is with fix_unresolved_deltas that
> sometimes put at the root of the chain (in base_cache) something that
> comes from our store, not the pack we are writing. Then starts a delta
> chain resolution.
If it comes from our store, we should have _no_ problem reconstructing the
object.
> It won't explode in memory at all, we just keep the first data of a
> delta chain in memory, that's all. It indeed consumes more memory, but
> we talk about *one* single object per delta chain because we're too lazy
> to memorize where it comes from. It's probably not much of an explosion.
"Probably".
> We also waste that object even when it's from our own pack. Well, I'd
> say "too bad".
And I say it's dirty, and since the pack code traditionally is one of the
cleanest parts of Git, coming from Nico, let's not change that, okay?
Ciao,
Dscho
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Ingo Molnar @ 2008-07-23 13:49 UTC (permalink / raw)
To: git
In-Reply-To: <20080723131736.GA9100@elte.hu>
* Ingo Molnar <mingo@elte.hu> wrote:
> So i guess it's better to just create a separate
> .git/refs/merge-cache/ hierarchy with timestamps of last merged
> branches and their head sha1 ... but maybe i'm banging on open doors?
here's the git-fastmerge script i've whipped up in 10 minutes. It does
the trick nicely for me:
first run:
real 0m53.228s
user 0m41.134s
sys 0m11.405s
second run:
real 0m2.751s
user 0m1.280s
sys 0m1.491s
or a 20x speedup. Yummie! :-)
It properly notices when i commit to a topic branch, and it maintains a
proper matrix of <A> <- <B> merge timestamps. It even embedds the sha1's
in the timestamp path so it should be quite complete. It should work
fine across resets, re-merges, etc. too i think. It should work well
with renamed branches as well i think. (although i dont do that all that
often)
In fact even if i delete the whole .git/mergecache/ hierarchy and run a
'cold' merge, it's much faster:
real 0m32.129s
user 0m24.456s
sys 0m7.603s
Because many of the branches have the same sha1 so it's already
half-optimized even on the first run.
Much of the remaining 2.7 seconds overhead comes from the git-log runs
to retrieve the sha1s, so i guess it could all be made even faster.
Now this scheme assumes that there's a sane underlying filesystem that
can take these long pathnames and which has good timestamps (which i
have, so it's not a worry for me).
Hm?
Ingo
-----------------{ git-fastmerge }--------------------->
#!/bin/bash
usage () {
echo 'usage: git-fastmerge <refspec>..'
exit -1
}
[ $# = 0 ] && usage
BRANCH=$1
MERGECACHE=.git/mergecache
[ ! -d $MERGECACHE ] && { mkdir $MERGECACHE || usage; }
HEAD_SHA1=$(git-log -1 --pretty=format:"%H")
BRANCH_SHA1=$(git-log -1 --pretty=format:"%H" $BRANCH)
CACHE=$MERGECACHE/$HEAD_SHA1/$BRANCH_SHA1
[ -f "$CACHE" -a "$CACHE" -nt .git/refs/heads/$BRANCH_SHA1 ] && {
echo "merge-cache hit on HEAD <= $1"
exit 0
}
git-merge $1 && {
mkdir -p $(dirname $CACHE)
touch $CACHE
}
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: SZEDER Gábor @ 2008-07-23 13:56 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080723130518.GA17462@elte.hu>
Hi,
On Wed, Jul 23, 2008 at 03:05:18PM +0200, Ingo Molnar wrote:
> I've got the following, possibly stupid question: is there a way to
> merge a healthy number of topic branches into the master branch in a
> quicker way, when most of the branches are already merged up?
>
> Right now i've got something like this scripted up:
>
> for B in $(git-branch | cut -c3- ); do git-merge $B; done
you cound use 'git branch --no-merged' to list only those branches
that have not been merged into your current HEAD.
Üdv,
Gábor
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Sergey Vlasov @ 2008-07-23 13:41 UTC (permalink / raw)
To: Ingo Molnar; +Cc: git
In-Reply-To: <20080723130518.GA17462@elte.hu>
[-- Attachment #1: Type: text/plain, Size: 889 bytes --]
On Wed, 23 Jul 2008 15:05:18 +0200 Ingo Molnar wrote:
> Anyone can simulate it by switching to the linus/master branch of the
> current Linux kernel tree, and doing:
>
> time for ((i=0; i<140; i++)); do git-merge v2.6.26; done
>
> real 1m26.397s
> user 1m10.048s
> sys 0m13.944s
Timing results here (E6750 @ 2.66GHz):
41.61s user 3.71s system 99% cpu 45.530 total
However, testing whether there is something new to merge could be
performed significantly faster:
$ time sh -c 'for ((i=0; i<140; i++)); do [ -n "$(git rev-list --max-count=1 v2.6.26 ^HEAD)" ]; done'
sh -c 5.49s user 0.26s system 99% cpu 5.786 total
The same loop with "git merge-base v2.6.26 HEAD" takes about 40
seconds here - apparently finding the merge base is the expensive
part, and it makes sense to avoid it if you expect that most of your
branches do not contain anything new to merge.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: q: faster way to integrate/merge lots of topic branches?
From: Ingo Molnar @ 2008-07-23 14:02 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <488734D9.9070703@op5.se>
* Andreas Ericsson <ae@op5.se> wrote:
> Ingo Molnar wrote:
>> I've got the following, possibly stupid question: is there a way to
>> merge a healthy number of topic branches into the master branch in a
>> quicker way, when most of the branches are already merged up?
>>
>> Right now i've got something like this scripted up:
>>
>> for B in $(git-branch | cut -c3- ); do git-merge $B; done
>>
>> It takes a lot of time to run on even a 3.45GHz box:
>>
>> real 0m53.228s
>> user 0m41.134s
>> sys 0m11.405s
>>
>> I just had a workflow incident where i forgot that this script was
>> running in one window (53 seconds are a _long_ time to start doing some
>> other stuff :-), i switched branches and the script merrily chugged
>> away merging branches into a topic branch i did not intend.
>>
>> It iterates over 140 branches - but all of them are already merged up.
>>
>
> With the builtin merge (which is in next), this should be doable with
> an octopus merge, which will eliminate the branches that are already
> fully merged, resulting in a less-than-140-way merge (thank gods...).
> It also doesn't have the 24-way cap that the scripted version suffers
> from.
>
> If it does a good job at your rather extreme use-case, I'd say it's
> good enough for 'master' pretty soon :-)
hm, while i do love octopus merges [*] for release and bisection-quality
purposes, for throw-away (delta-)integration runs it's more manageable
to do a predictable series of one-on-one merges.
It results in better git-rerere behavior, has easier (to the human)
conflict resolutions and the octopus merge also falls apart quite easily
when it runs into conflicts. Furthermore, i've often seen octopus merges
fail while a series of 1:1 merges succeeded.
What i could try is to do a speculative octopus merge, in the hope of it
just going fine - and then fall back to the serial merge if it fails?
The git-fastmerge approach is probably still faster though - and
certainly simpler from a workflow POV.
Ingo
[*] take a look at these in the Linux kernel -git repo:
gitk 3c1ca43fafea41e38cb2d0c1684119af4c1de547
gitk 6924d1ab8b7bbe5ab416713f5701b3316b2df85b
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox