* Move-delete merge conflict is not displayed using git ls-files --unmerged
From: Constantine Plotnikov @ 2008-12-22 14:29 UTC (permalink / raw)
To: git
Lets consider repository state created with the following script (git
version 1.6.0.4).
mkdir test-move-delete
cd test-move-delete
git init
echo test1 >file.txt
echo test2 >>file.txt
echo test3 >>file.txt
echo test4 >>file.txt
git add file.txt
git commit -m "start"
git checkout -b moved master
git mv file.txt copy.txt
git commit -m "moved"
git checkout -b deleted master
git rm file.txt
git commit -m "deleted"
git merge moved
The last merge command fails with move-delete conflict.
CONFLICT (rename/delete): Renamed file.txt->copy.txt in moved and
deleted in HEAD
Automatic merge failed; fix conflicts and then commit the result.
However git ls-files --unmerged does not list any conflict in that
case and it is possible to execute git commit command right away
without doing anything with the repository.
I think that if git merge reports the conflicts, such conflicts should
be discoverable using git ls-files and prevent commit with resolving
the conflict like it is done with modify-delete conflicts.
Regards,
Constantine
^ permalink raw reply
* [RFC] Automagic patch merge ack emails
From: Richard Hartmann @ 2008-12-22 14:07 UTC (permalink / raw)
To: git
Hi all,
I poked around the docs, but I could not find any option to have git
send email to people who signed off a patch when it's merged.
I only realized the two patches I sent were merged because they were
listed in the RC changelog summary and would have followed up my patch
email in a about a week, asking about its status.
Does anyone else think this is useful? Does anyone else think it should
make it into main so it can be enabled via config, not via a hook that
needs to be imported into each and every repo?
Richard
^ permalink raw reply
* Perl 5 now uses Git for version control
From: demerphq @ 2008-12-22 11:32 UTC (permalink / raw)
To: git
In-Reply-To: <a92222c80812212356p766345aaj5f4dc31ebba616aa@mail.gmail.com>
HOLLAND, Michigan - The Perl Foundation has migrated Perl 5 to the Git
version control system, making it easier than ever for Perl's development
team to continue to improve the language that powers many websites.
Moving from Perforce to git provides a number of benefits to the Perl
community:
- With a public repository and Git's extensive support for distributed
and offline work, working on Perl 5's source becomes easier for everyone
involved.
- Because Git is open source, all developers now have equal access to
the tools required to work on Perl's codebase.
- Core committers have less administrative work to do when integrating
contributed changes.
- Developers outside the core team can more easily work on experimental
changes to Perl before proposing them for inclusion in the next release.
- A vast array of improved repository and change analysis tools are now
available to Perl's developers.
- The new Git repository includes every version of Perl 5 ever released,
as well as every revision made during development.
Interested developers can get a copy of the Perl 5 Git repository at
at http://perl5.git.perl.org/perl.git
In true open source style, Sam Vilain converted Perl's history from
Perforce to Git. He did the work both in his spare time and in time
donated by his employer, Catalyst IT. He spent more than a year building
custom tools to transform 21 years of Perl history into the first
ever unified repository of every single change to Perl. In addition
to changes from Perforce, Sam patched together a comprehensive view
of Perl's history incorporating publicly available snapshot releases,
changes from historical mailing list archives and patch sets recovered
from the hard drives of previous Perl release engineers.
Perl 5 is used by businesses around the world including the BBC,
Amazon.com, LiveJournal, Ticketmaster, Craigslist and IMDb. Larry Wall
created Perl in 1987 while working as a systems administrator for NASA.
Larry released Perl 1.000 on December 18th 1987. Over the past 21 years,
Perl has grown into a high-level, general-purpose, dynamic programming
language and is widely used for Web development, Systems Administration,
Genomics and in many other disciplines. The most recent major version
of Perl 5 (5.10.0) was released one year ago.
Git is an open source version control system designed to handle very
large projects with speed and efficiency. Created by Linus Torvalds,
the inventor of Linux to handle the vast number of contributions to
the Linux Kernel, Git is highly flexible and extensible. Perl's motto,
"There's More Than One Way To Do It!" perfectly matches the Git workflow.
Nicholas Clark, the manager for Perl 5.8.9 which was released this week,
said "I'm looking forward to Git giving me the ability to work either
online or offline. Perforce is great when I have a network connection,
but until now those times when I've been trying to develop on trains
or planes, at stations or airports, I'm back in the 'dark ages' before
version control. Git solves this problem and more".
The hardware behind this and the systems administration time to maintain
it is donated by Booking.com. Booking.com has also recently donated
$50,000 to The Perl Foundation, to aid in the further development and
maintenance of the Perl programming language in general, and Perl 5.10
in particular.
Perl originally used the Revision Control System (RCS) until March
1997 when it switched to the Perforce Software Configuration Management
System. The Perforce repository was graciously hosted and maintained,
free of charge, by ActiveState. Perforce provided the core developers
with powerful tools, but these tools were not available to users outside
the core team. The switch to Git removes this barrier.
About The Perl Foundation (http://www.perlfoundation.org/) | The Perl
Foundation is dedicated to the advancement of the Perl programming
language through open discussion, collaboration, design, and code. The
Perl Foundation coordinates the efforts of numerous grass-roots Perl-based
groups, including: International Yet Another Perl Conferences (YAPC's),
Carries the legal responsibility for Perl 5 and Perl 6 and the Artistic
and Artistic 2.0 licenses, perl.org, Perl Mongers, and PerlMonks.
About Booking.com (http://www.booking.com/) | Booking.com is part of
Priceline.com (Nasdaq: PCLN). Its website attracts an average of 30
million unique visitors each month. Booking.com works with more than
57,000 affiliated hotels in 15,000 destinations around the world. Its
services are available in 21 languages. Booking.com currently has 24
offices in Amsterdam, Athens, Barcelona, Berlin, Cambridge, Cape Town,
Dubai, Dublin, London, Loulé (Portugal), Lyon, Madrid, Moscow, Munich,
New York, Orlando, Paris, Rome, San Francisco, Sydney, Singapore,
Stockholm, Vienna and Warsaw.
About Catalyst IT (NZ) Ltd (http://www.catalyst.net.nz/) | Catalyst IT
is New Zealand's premiere Open Source development house. Catalyst looks
after the development requirements for the NZ Electoral Enrolment Centre,
manage the .NZ registry, the largest NZ newspaper's online presence,
the NZ TAB and many other exciting projects, and are organising the 2010
Australasian Linux Conference to be held in Wellington, New Zealand.
http://use.perl.org/articles/08/12/22/0830205.shtml
--
perl -Mre=debug -e "/just|another|perl|hacker/"
^ permalink raw reply
* [ANNOUNCE] GIT 1.6.1-rc4
From: Junio C Hamano @ 2008-12-22 9:54 UTC (permalink / raw)
To: git
This hopefully will be the last -rc before 1.6.1 becomes your Christmas
present.
Changes since v1.6.1-rc3 are minor and boring details.
Alexander Gavrilov (2):
git-gui: Fix handling of relative paths in blame.
git-gui: Fix commit encoding handling.
Arjen Laarhoven (1):
Enable threaded delta search on Mac OS X/Darwin
Boyd Stephen Smith Jr (1):
git-revert documentation: refer to new HOWTO on reverting faulty merges
Christian Stimming (3):
git-gui: Update German (completed) translation.
gitk: Mark forgotten strings (header sentence parts in color chooser) for translation
gitk: Update German translation
David Aguilar (1):
git-mergetool: properly handle "git mergetool -- filename"
Fredrik Skolmli (1):
git-gui: Starting translation for Norwegian
Giuseppe Bilotta (1):
gitk: Map / to focus the search box
Johannes Schindelin (3):
fast-import: close pack before unlinking it
git-gui: Get rid of the last remnants of GIT_CONFIG_LOCAL
fast-export: deal with tag objects that do not have a tagger
Johannes Sixt (3):
gitk: Use check-buttons' -text property instead of separate labels
gitk: Ensure that "Reset branch" menu entry is enabled
gitk: Force the focus to the main window on Windows
Junio C Hamano (12):
git-show: do not segfault when showing a bad tag
pager: do not dup2 stderr if it is already redirected
gitweb: do not run "git diff" that is Porcelain
GIT 1.5.4.7
gitweb: do not run "git diff" that is Porcelain
make_absolute_path(): check bounds when seeing an overlong symlink
builtin-blame.c: use strbuf_readlink()
combine-diff.c: use strbuf_readlink()
fast-import: make tagger information optional
Make sure lockfiles are unlocked when dying on SIGPIPE
send-email: futureproof split_addrs() sub
GIT 1.6.1-rc4
Kevin Ballard (1):
gitk: Allow unbalanced quotes/braces in commit headers
Kirill A. Korinskiy (1):
Remove the requirement opaquelocktoken uri scheme
Lee Marlow (2):
bash completion: Sort config completion variables
bash completion: Sync config variables with their man pages
Linus Torvalds (5):
Add generic 'strbuf_readlink()' helper function
Make 'ce_compare_link()' use the new 'strbuf_readlink()'
Make 'index_path()' use 'strbuf_readlink()'
Make 'diff_populate_filespec()' use the new 'strbuf_readlink()'
Make 'prepare_temp_file()' ignore st_size for symlinks
Marcel M. Cary (1):
git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
Markus Heidelberg (7):
Documentation: fix description for enabling hooks
doc/git-reset: add reference to git-stash
Documentation: sync example output with git output
Documentation: fix typos, grammar, asciidoc syntax
Documentation: fix typos, grammar, asciidoc syntax
Documentation/git-show-branch: work around "single quote" typesetting glitch
doc/git-fsck: change the way for getting heads' SHA1s
Michael J Gruber (1):
test overlapping ignore patterns
Michele Ballabio (1):
git gui: update Italian translation
Miklos Vajna (4):
git-gui: Update Hungarian translation for 0.12
git-daemon documentation: use {tilde}
githooks documentation: add a note about the +x mode
SubmittingPatches: mention the usage of real name in Signed-off-by: lines
Nanako Shiraishi (3):
git-gui: Update Japanese translation for 0.12
Clarify documentation of "git checkout <tree-ish> paths" syntax
Add a documentat on how to revert a faulty merge
Paul Mackerras (1):
gitk: Fix bugs in blaming code
Peter Krefting (2):
git-gui: Updated Swedish translation (515t0f0u).
git-gui: Fixed typos in Swedish translation.
René Scharfe (3):
Fix type-mismatch compiler warning from diff_populate_filespec()
connect.c: stricter port validation, silence compiler warning
fast-import.c: stricter strtoul check, silence compiler warning
Richard Hartmann (2):
Make help entries alphabetical
Always show which directory is not a git repository
Robin Rosenberg (1):
git-revert: record the parent against which a revert was made
Shawn O. Pearce (2):
git-gui: Update po template to include 'Mirroring %s' message
git-gui 0.12
Wu Fengguang (1):
git-send-email: handle email address with quoted comma
^ permalink raw reply
* Re: Git with Hudson
From: Jean-Baptiste Quenot @ 2008-12-22 9:34 UTC (permalink / raw)
To: git
In-Reply-To: <20081218160734.b1992eb8.stephen@exigencecorp.com>
2008/12/18 Stephen Haberman <stephen@exigencecorp.com>:
>
> We tried using the Hudson git plugin that you can download from the
> Hudson site and ended up with problems--whether we had too many branches
> or something, the plugin has some funny "figure out what needs to be
> built" logic that issued near-constant git rev-list commands. To the
> point where our own "git fetch" calls would get starved for 20-30
> seconds.
>
> We eventually wrote our own Hudson git plugin that is simpler and
> doesn't do any funny rev-listing/walking. It just stores last hash
> built and rebuilds once that doesn't match the branch tip. Once that
> was in place, it worked great.
>
> I've got permission to publish it if you're interested--just haven't
> yet.
Good idea! I'm also affected by this problem, although the
git-rev-list is not an issue anymore since version 0.5. Simplifying
the checkout() is still in my plans though, so your contribution comes
at the right moment. Once the code will be made available we'll be
able to take the best of the two Git plugins and merge them into one.
WDYT?
--
Jean-Baptiste Quenot
http://jbq.caraldi.com/
^ permalink raw reply
* [patch v2] documentation: Explain how to free up space after filter-branch
From: Thomas Jarosch @ 2008-12-22 9:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Explain how to free up space after filter-branch.
Thanks to Björn Steinbrink for pointing me in the right direction.
The v2 version of this patch uses "git repack -a -d"
instead of "git repack -a -d --depth=250 --window=250"
as this nocked down a box with 4GB of ram using a repository
with medium sized binary files (50 - 100mb).
Signed-off-by: Thomas Jarosch <thomas.jarosch@intra2net.com>
diff --git a/Documentation/git-filter-branch.txt b/Documentation/git-filter-
branch.txt
index fed6de6..1432380 100644
--- a/Documentation/git-filter-branch.txt
+++ b/Documentation/git-filter-branch.txt
@@ -319,6 +319,18 @@ git filter-branch --index-filter \
mv $GIT_INDEX_FILE.new $GIT_INDEX_FILE' HEAD
---------------------------------------------------------------
+Free up the space in .git if the rewritten version is correct
+by deleting refs/original and pruning the reflog:
+
+----------------------------------------------------
+git for-each-ref --format='%(refname)' refs/original
+ | xargs -i git update-ref -d {}
+
+git reflog expire --expire=0 --all
+git repack -a -d
+git prune
+----------------------------------------------------
+
Author
------
^ permalink raw reply related
* Re: git-svn and empty directories
From: Thomas Jarosch @ 2008-12-22 8:58 UTC (permalink / raw)
To: Eric Wong; +Cc: Deskin Miller, git
In-Reply-To: <20081221070854.GA22014@hand.yhbt.net>
Hello Eric,
On Sunday, 21. December 2008 08:08:54 Eric Wong wrote:
> Modern git-svn never touches the working tree during fetch, it hashes
> objects into the database and adds those to the indexes directly.
Ok
> However, I don't think your proposal is a good idea since it adds too
> much "magic". Complex special cases for delta application if the
> .gitignore gets real content and backwards-incompatibility since I know
> some git-svn users already rely on pushing .gitignore files (empty or
> otherwise) to an upstream SVN repo.
>
> The minor problem of missing empty directories isn't big enough to be
> worth the trouble IMHO.
Ok, this seems to be too much effort to fix. I manually added the directories
to my HEAD version and really hope I don't have to ever checkout
and build something from the past *fingers crossed* :-)
Cheers,
Thomas
^ permalink raw reply
* Re: [PATCH v3] git-svn: Make following parents atomic
From: Thomas Jarosch @ 2008-12-22 8:41 UTC (permalink / raw)
To: Deskin Miller
Cc: Eric Wong, git, Junio C Hamano, Thomas Leonard,
Björn Steinbrink
In-Reply-To: <200812161422.58814.thomas.jarosch@intra2net.com>
On Tuesday, 16. December 2008 14:22:44 Thomas Jarosch wrote:
> This patch has a very nice side effect, it seems to fix a long standing
> problem with subversion imports. Here's the original report:
> https://kerneltrap.org/mailarchive/git/2008/4/8/1377514/thread
>
> Many of the 121 tags in my SVN tree were created by cvs2svn,
> which often created tags by copying older revisions
> of sub paths into the current tree.
>
> I've written a small script that checks out the same tag via git and SVN.
> It runs a diff against those two trees and saves the result to a file
> so I can manually check it. With git-svn from 1.6.0.5, the results are
> horrible: Over 30% of the tags didn't match the code in SVN.
>
> With git-svn from 1.6.1rc3, my first two manual probes look very good.
> Right now I'm reimporting the svn tree and will have the results
> of the complete "checkout comparison" tomorrow.
Yipeee, our SVN repository is fully migrated to git and split into handy 3-5GB
repositories. All the git tags match the code from the SVN tags,
so I guess this was a good stress test for git-svn 1.6.0.6 :-)
Cheers,
Thomas
^ permalink raw reply
* Re: git-diff should not fire up $PAGER, period!
From: Junio C Hamano @ 2008-12-22 8:30 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Miles Bader, jidanni, git
In-Reply-To: <494F47E1.8070105@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Miles Bader schrieb:
>> Just (setenv "PAGER" "cat") in .emacs.
>>
>> [I actually have it set to /bin/cat, not sure if that's meaningful or not.]
>
> No, really, you should set it to plain "cat": As a special case git
> recognizes this token and does not run any pager. If you set it to
> "/bin/cat" it does run a pager, namely /bin/cat.
But that would not hurt ;-).
On the other hand, using PAGER=cat or PAGER=/bin/cat is the right thing to
do in compilation and shell modes in Emacs, regardless of your use of git.
^ permalink raw reply
* Re: git-diff should not fire up $PAGER, period!
From: Johannes Sixt @ 2008-12-22 7:55 UTC (permalink / raw)
To: Miles Bader; +Cc: jidanni, git
In-Reply-To: <buo3aggyjmy.fsf@dhapc248.dev.necel.com>
Miles Bader schrieb:
> Just (setenv "PAGER" "cat") in .emacs.
>
> [I actually have it set to /bin/cat, not sure if that's meaningful or not.]
No, really, you should set it to plain "cat": As a special case git
recognizes this token and does not run any pager. If you set it to
"/bin/cat" it does run a pager, namely /bin/cat.
-- Hannes
^ permalink raw reply
* Re: [PATCH] Add support for changing packed_git_window_size at process start time
From: R. Tyler Ballance @ 2008-12-22 6:25 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081221222848.GE17355@spearce.org>
[-- Attachment #1: Type: text/plain, Size: 1772 bytes --]
On Sun, 2008-12-21 at 14:28 -0800, Shawn O. Pearce wrote:
>
> I think this is a good idea, trying to fit within the ulimit
> rather than assuming we can take whatever we please. But you
> also need to drop the packed_git_limit down.
>
> My suggestion is this:
>
> packed_git_limit = as->rlim_cur * 0.85;
> packed_git_window_size = packed_git_limit / 4;
>
> or maybe / 2. You really want at least 2 windows available within
> your limit.
Ah, gotcha, sounds like a good idea. I went ahead and added the change
and I'm still getting the memory issues.
I'm not as familiar with using gdb(1), so I'm having trouble tracking
down the issue in a limited session, I get loads of issues like the
following when trying to step through an execution of `git log`
1368 if (diff_setup_done(&revs->diffopt) < 0)
(gdb)
utils.c:1065: internal-error: virtual memory exhausted: can't
allocate 4064 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n
utils.c:1065: internal-error: virtual memory exhausted: can't
allocate 4064 bytes.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Create a core file of GDB? (y or n) y
(gdb) q
The program is running. Quit anyway (and kill it)? (y or n) y
tyler@starfruit:~/source/git/main>
Is there a means in which I can cause a core dump on an ENOMEM error passed back from mmap(2)? That or a way to impose these limits on the gdb git-subprocess but not on the gdb process?
Appreciate the help :)
Cheers
--
-R. Tyler Ballance
Slide, Inc.
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-diff should not fire up $PAGER, period!
From: Miles Bader @ 2008-12-22 3:28 UTC (permalink / raw)
To: Linus Torvalds; +Cc: jidanni, git
In-Reply-To: <alpine.LFD.2.00.0812171401300.14014@localhost.localdomain>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> And then you have the _gall_ to talk about "unix design"...
Another beer?
-Miles
--
Suburbia: where they tear out the trees and then name streets after them.
^ permalink raw reply
* Re: git-diff should not fire up $PAGER, period!
From: Miles Bader @ 2008-12-22 3:27 UTC (permalink / raw)
To: jidanni; +Cc: git
In-Reply-To: <8763lixyps.fsf_-_@jidanni.org>
Just (setenv "PAGER" "cat") in .emacs.
[I actually have it set to /bin/cat, not sure if that's meaningful or not.]
-Miles
--
.Numeric stability is probably not all that important when you're guessing.
^ permalink raw reply
* Re: Git weekly links: 2008-51
From: Felipe Contreras @ 2008-12-22 3:04 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git list
In-Reply-To: <m3ej02d3tq.fsf@localhost.localdomain>
On Sat, Dec 20, 2008 at 9:50 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> "Felipe Contreras" <felipe.contreras@gmail.com> writes:
>
>> This week tortoisegit stole the spotlight. Maybe there weren't many
>> other links, or maybe I failed to notice them. Also, many people liked
>> the comment of Linus Torvalds regarding C++ in git.
>>
>> blog version:
>> http://gitlog.wordpress.com/2008/12/20/git-weekly-links-2008-51/
>>
>> == Articles ==
>>
>> Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
>> Linus Torvalds creates some buzz
>> http://lwn.net/Articles/249460/
>
> A not countered counter:
> C++ is a horrible language
> http://skepticalmethodologist.wordpress.com/2008/12/17/c-is-a-horrible-language/
>
>> == General links ==
>>
>> tortoisegit
>> http://code.google.com/p/tortoisegit/
>
> What about "Git Extensions":
> https://sourceforge.net/projects/gitextensions/
> http://github.com/spdr870/gitextensions/
>
> And "TortoiseGit Challenge":
> http://github.com/blog/256-tortoisegit-challenge
I didn't see many people bookmarking those links, but I added them to
the blog post as your picks.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] bash completion: add 'rename' subcommand to git-remote
From: Markus Heidelberg @ 2008-12-22 2:56 UTC (permalink / raw)
To: gitster; +Cc: git
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
contrib/completion/git-completion.bash | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 108859e..e0d96f3 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1367,7 +1367,7 @@ _git_config ()
_git_remote ()
{
- local subcommands="add rm show prune update"
+ local subcommands="add rename rm show prune update"
local subcommand="$(__git_find_subcommand "$subcommands")"
if [ -z "$subcommand" ]; then
__gitcomp "$subcommands"
@@ -1375,7 +1375,7 @@ _git_remote ()
fi
case "$subcommand" in
- rm|show|prune)
+ rename|rm|show|prune)
__gitcomp "$(__git_remotes)"
;;
update)
--
1.6.1.rc3.64.ga0b5a
^ permalink raw reply related
* Re: Memory issue with fast-import, why track branches?
From: Felipe Contreras @ 2008-12-22 2:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git list
In-Reply-To: <20081221221702.GC17355@spearce.org>
On Mon, Dec 22, 2008 at 12:17 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> I tracked down an issue I have when importing a big repository. For
>> some reason memory usage keeps increasing until there is no more
>> memory.
>>
>> After looking at the code my guess is that I have a humongous amount
>> of branches.
>>
>> Actually they are not really branches, but refs. For each git commit
>> there's an original mtn ref that I store in 'refs/mtn/sha1', but since
>> I'm using 'commit refs/mtn/sha1' to store it, a branch is created for
>> every commit.
>>
>> I guess there are many ways to fix the issue, but for starters I
>> wonder why is fast-import keeping track of all the branches? In my
>> case I would like fast-import to work exactly the same if I specify
>> branches or not (I'll update them later).
>
> Because fast-import has to buffer them until the pack file is done.
> The objects aren't available to the repository until after a
> checkpoint is sent or until the stream ends. Either way until
> then fast-import has to buffer the refs so they don't get exposed
> to other git processes reading that same repository, because they
> would point to objects that the process cannot find.
>
> I guess it could release the brnach memory after it dumps the
> branches in a checkpoint, but its memory allocators work under an
> assumption that strings (like branch and file names) will be reused
> heavily by the frontend and thus they are poooled inside of a string
> pool. The branch objects are also pooled inside of a common alloc
> pool, to ammortize the cost of malloc's block headers out over the
> data used.
>
> IOW, fast-import was designed for ~5k branches, not ~1 million
> unique branches.
My point is: why is it not designed for 0 branches? In many places in
the code there's the assumption that the tree = branch, but that's not
always the case. You can specify a 'from sha1' and then the branch
becomes irrelevant.
In fact in monotone some commits are not part of any branch, and many
are part of multiple branches. Those cases can't be handled by
fast-import right now. Not to mention random refs like 'ref/mtn/foo'
which would come in handy for my script.
Now my question is: would it be possible to get rid of the notion of
branches on fast-import and go for refs instead?
On the other hand if branch memory is freed after a checkpoint then
there's no limit to how many 'branches' can be handled.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/2] fast-import: add special mode; copy from parent.
From: Felipe Contreras @ 2008-12-22 2:25 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
In-Reply-To: <1229825502-963-1-git-send-email-felipe.contreras@gmail.com>
On Sun, Dec 21, 2008 at 4:11 AM, Felipe Contreras
<felipe.contreras@gmail.com> wrote:
> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
> ---
> Documentation/git-fast-import.txt | 1 +
> fast-import.c | 41 +++++++++++++++++++++---------------
> 2 files changed, 25 insertions(+), 17 deletions(-)
Please disregard this patch, it doesn't work as I expected. I'll send
an updated one soon.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 1/2] fast-import: add special mode; copy from parent.
From: Felipe Contreras @ 2008-12-22 2:23 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081221220757.GA17355@spearce.org>
On Mon, Dec 22, 2008 at 12:07 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> + if (!prefixcmp(p, "- ")) {
>> + mode = 0;
>> + p += 2;
>
> This part made me wonder, why are we always doing "S_IFREG | mode"
> further down?
My guess is because 0644 and 0755; doing S_IFREG | mode doesn't
achieve anything for the other modes.
I just sent a patch that I hope makes that more visible.
--
Felipe Contreras
^ permalink raw reply
* [PATCH] fast-import: Cleanup mode setting.
From: Felipe Contreras @ 2008-12-22 2:19 UTC (permalink / raw)
To: git; +Cc: Felipe Contreras
"S_IFREG | mode" probably is only required for 0644 and 0755.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
---
fast-import.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index a6bce66..f0e08ac 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -1872,12 +1872,13 @@ static void file_change_m(struct branch *b)
if (!p)
die("Corrupt mode: %s", command_buf.buf);
switch (mode) {
+ case 0644:
+ case 0755:
+ mode |= S_IFREG;
case S_IFREG | 0644:
case S_IFREG | 0755:
case S_IFLNK:
case S_IFGITLINK:
- case 0644:
- case 0755:
/* ok */
break;
default:
@@ -1944,7 +1945,7 @@ static void file_change_m(struct branch *b)
typename(type), command_buf.buf);
}
- tree_content_set(&b->branch_tree, p, sha1, S_IFREG | mode, NULL);
+ tree_content_set(&b->branch_tree, p, sha1, mode, NULL);
}
static void file_change_d(struct branch *b)
--
1.6.0.6.5.ga66c
^ permalink raw reply related
* Re: [PATCH 2/2] fast-import: add special '-' blob reference to use the previous one.
From: Felipe Contreras @ 2008-12-22 2:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20081221223335.GF17355@spearce.org>
On Mon, Dec 22, 2008 at 12:33 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>>
>> > Hmph, so if create a new path with a blob of "-" the repository
>> > will be corrupt because the zero id was used and error was produced.
>> >
>> > Actually I think you have the same bug in the prior patch with the
>> > mode being inherited. I wonder if we shouldn't put error checking
>> > in too to validate that versions[0] describes a file entry.
>>
>> Why are these patches necessary?
Yeah, I realized I didn't explain that after sending the patches.
>> The proposed commit message describes what it does, but does not give hint
>> to even guess being able to use this new feature helps in what situation.
>> As far as I can see, these changes allow the exporter to say "this aspect
>> of the new data is the same as the previous one", but I thought that the
>> way in which fast-import works already revolves around "you have this
>> tree, and the next tree is different from it in this and that way." Why
>> does one need be able to mention "this is the same as the previous one"
>> explicitly in the first place?
>
> Hmm. Actually, imagine you were dumping from git-diff output style
> stream into a fast-import stream.
>
> If a file changes only content, the mode is shown in the index line.
> Yay us. But what if the index line wasn't present in the diff? You
> don't know the prior mode of the file, but you do have its content.
>
> If a file changes only mode, we get no content hints in the diff.
> How do you send that into fast-import without making the frontend
> keep track of every path's current mode?
>
> Though I agree, these details should be described in the commit
> messages, not left as an exercise for the maintainer to make up.
Exactly. That's what happens with monotone; you usually have the
contents or the new mode, but not both at the same time.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH 2/2] fast-import: add special '-' blob reference to use the previous one.
From: Felipe Contreras @ 2008-12-22 2:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081221221149.GB17355@spearce.org>
On Mon, Dec 22, 2008 at 12:11 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Felipe Contreras <felipe.contreras@gmail.com> wrote:
>> @@ -1862,7 +1864,7 @@ static void file_change_m(struct branch *b)
>> const char *endp;
>> struct object_entry *oe = oe;
>> unsigned char sha1[20];
>> - uint16_t mode, inline_data = 0;
>> + uint16_t mode, inline_data = 0, empty_blob = 0;
>
> Its not the empty blob, its the inherited/assumed blob...
Right. I thought: in order to use the inherited blob, you should not
specify any blob (leave it empty, or blank).
But yeah, 'inherited' does the job too.
>> @@ -1893,6 +1895,10 @@ static void file_change_m(struct branch *b)
>> } else if (!prefixcmp(p, "inline")) {
>> inline_data = 1;
>> p += 6;
>> + } else if (!prefixcmp(p, "- ")) {
>> + hashclr(sha1);
>> + empty_blob = 1;
>> + p += 1;
>
> Hmph, so if create a new path with a blob of "-" the repository
> will be corrupt because the zero id was used and error was produced.
>
> Actually I think you have the same bug in the prior patch with the
> mode being inherited. I wonder if we shouldn't put error checking
> in too to validate that versions[0] describes a file entry.
Yes, in my tests I found that issue in the previous patch and I have a
fix for that (set a default mode), but I haven't fixed this one. Do
you know what should be the behavior? I think it should 'die'.
--
Felipe Contreras
^ permalink raw reply
* [PATCHv3] Have git revert documentation reference new HOWTO on reverting faulty merges.
From: Boyd Stephen Smith Jr. @ 2008-12-22 0:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Nanako Shiraishi
In-Reply-To: <7vy6y9kxdh.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Boyd Stephen Smith Jr <bss@iguanasuicide.net>
---
On Sunday 2008 December 21 15:54:18 Junio C Hamano wrote:
> Thanks. I was thinking about doing this instead; how the reference to the
> HOW-TO is done is different, and I am hoping that it would give better
> result for HTML version at least.
Here's a pruned version of my prose, with your link style. I prefer my prose
because I don't want to use the word "branch", which implies refs having some
important in the later merges, which is not the case from what I understand.
Documentation/git-revert.txt | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index caa0729..ee9cb82 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -44,6 +44,14 @@ OPTIONS
option specifies the parent number (starting from 1) of
the mainline and allows revert to reverse the change
relative to the specified parent.
++
+Reverting a merge commit declares that you will never want the tree changes
+brought in by the merge. As a result, later merges will only bring in tree
+changes introduced by commits that are not ancestors of the revert commit.
+This may or may not be what you want.
++
+See the link:howto/revert-a-faulty-merge.txt[revert-a-faulty-merge How-To] for
+more details.
--no-edit::
With this option, 'git-revert' will not start the commit
--
1.6.0.2
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
^ permalink raw reply related
* Re: [PATCHv2] Have manpage reference new documentation on reverting merges.
From: Boyd Stephen Smith Jr. @ 2008-12-22 0:04 UTC (permalink / raw)
To: git; +Cc: Nanako Shiraishi
[-- Attachment #1: Type: text/plain, Size: 966 bytes --]
On Sunday 2008 December 21 15:54:18 you wrote:
> "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> > I took the alternative approach.
>
> Thanks. I was thinking about doing this instead; how the reference to the
> HOW-TO is done is different, and I am hoping that it would give better
> result for HTML version at least.
I like the different link style (still learning asciidoc here), although I am
mainly concerned with the manpage output.
However, I intentionally avoided using the word "branch" in my prose, because
that implies (to me) that the ref is what is remembered and important.
That's not technically correct, as refs are not part of the history that is
considered during the later merge.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH] gitk: Swap positions of 'next' and 'prev' buttons in the 'Find' section.
From: Paul Mackerras @ 2008-12-21 22:59 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <4948E779.9080909@viscovery.net>
Johannes Sixt writes:
> The button order 'prev' left of 'next' feels more natural than the other
> way round, in particular, compared to the order of the forward and backward
> arrows that are in the line above.
The next/prev labels are a bit awkward in any case, since "next" finds
an earlier commit - one further down the list, and "prev" finds a
later commit - one further back in the list. A better solution might
be to make images for arrows pointing up and down and use compound
buttons so the buttons say Find ^ and Find v (if you image the ^/v as
up and down arrows).
I also find myself often wanting a "Find first" button, i.e. search
starting at the top of the list.
Paul.
^ permalink raw reply
* Re: What's in git.git (Dec 2008, #03; Sun, 21)
From: Paul Mackerras @ 2008-12-21 23:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Johannes Schindelin, Johannes Sixt, Robin Rosenberg,
Boyd Stephen Smith Jr.
In-Reply-To: <7vskohpvj7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano writes:
> * Paul has one patch on his gitk branch I have fetched but not merged yet;
> waiting for his go-ahead.
Sorry. I have now flushed out my queue of pending patches; please
pull.
Thanks,
Paul.
^ 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