* What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Junio C Hamano @ 2009-01-29 2:06 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the branches, but I am still
holding onto them.
The topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
----------------------------------------------------------------
[New Topics]
* jc/maint-1.6.0-split-diff-metainfo (Mon Jan 26 00:08:24 2009 -0800) 1 commit
+ diff.c: output correct index lines for a split diff
This is slated for maintenance series 1.6.0.X, 1.6.1.X and also for
'master'. I think the change is pretty safe and sane to go directly to
'master' but I had too many other topoics to look at that I did not feel
comfortable enough to do so.
* jc/maint-split-diff-metainfo (Tue Jan 27 01:08:02 2009 -0800) 2 commits
+ Merge branch 'jc/maint-1.6.0-split-diff-metainfo' into jc/maint-
split-diff-metainfo
+ diff.c: output correct index lines for a split diff
Early conflict resolution branch for the above to carry it to 1.6.1X
series.
* js/maint-rebase-i-submodule (Tue Jan 27 12:42:31 2009 +0100) 2 commits
+ Fix submodule squashing into unrelated commit
+ rebase -i squashes submodule changes into unrelated commit
* jg/tag-contains (Mon Jan 26 09:13:25 2009 -0500) 3 commits
+ git-tag: Add --contains option
+ Make has_commit() non-static
+ Make opt_parse_with_commit() non-static
* jk/maint-cleanup-after-exec-failure (Wed Jan 28 02:38:14 2009 -0500) 4 commits
+ git: use run_command() to execute dashed externals
+ run_command(): help callers distinguish errors
+ run_command(): handle missing command errors more gracefully
+ git: s/run_command/run_builtin/
* jc/maint-allow-uninteresting-missing (Tue Jan 27 23:19:30 2009 -0800) 1 commit
+ revision traversal: allow UNINTERESTING objects to be missing
This is a small follow-up to the fix to send-pack in 1.6.1; meant to go in
1.6.1.X maintenance series and newer.
* am/maint-push-doc (Mon Jan 26 00:45:33 2009 +0100) 3 commits
+ Documentation: rework src/dst description in git push
+ Documentation: more git push examples
+ Documentation: simplify refspec format description
* jc/merge-convert (Mon Jan 26 16:45:01 2009 -0800) 1 commit
- git-merge-file: allow converting the results for the work tree
We did not give scripted Porcelains a way to say "this temporary file I am
using for merging is for this path, so use the core.autocrlf and attributes
rules for that final path". Instead, merge-file simply wrote out the
data in the canonical repository representation.
rerere has the same issue, but it is a lot worse. It reads the three
files (preimage, postimage and thisimage) from the work tree in the work
tree representation, merges them without converting them to the canonical
representation first but inserts the conflict markers with the canonical
representation and writes the resulting mess out. It needs to be fixed to
read with convert_to_git(), merge them while they are still in the
canonical representation and possibly add conflict markers, and then write
the results out after convert_to_working_tree(). It also needs to write
in binary mode as well.
* jc/maint-add-u-remove-conflicted (Wed Jan 28 14:24:53 2009 -0800) 1 commit
- add -u: do not fail to resolve a path as deleted
This has been updated from the posted version with a correction.
* ns/am-slacker (Sat Jan 24 10:18:02 2009 +0900) 2 commits
+ git-am: Add --ignore-date option
+ am: Add --committer-date-is-author-date option
It is a (probably) useful new feature with a sort-of cute explanation.
* jc/maint-apply-fix (Sun Jan 25 23:41:26 2009 -0800) 1 commit
+ builtin-apply.c: do not set bogus mode in check_preimage() for
deleted path
----------------------------------------------------------------
[Stalled and may need help and prodding to go forward]
* jc/blame (Wed Jun 4 22:58:40 2008 -0700) 2 commits
+ blame: show "previous" information in --porcelain/--incremental
format
+ git-blame: refactor code to emit "porcelain format" output
This gives Porcelains (like gitweb) the information on the commit _before_
the one that the final blame is laid on, which should save them one
rev-parse to dig further. The line number in the "previous" information
may need refining, and sanity checking code for reference counting may
need to be resurrected before this can move forward.
* db/foreign-scm (Sun Jan 11 15:12:10 2009 -0500) 3 commits
- Support fetching from foreign VCSes
- Add specification of git-vcs helpers
- Add "vcs" config option in remotes
The "spec" did not seem quite well cooked yet, but in the longer term I
think something like this to allow interoperating with other SCMs as if
the other end is a native git repository is a very worthy goal.
* cc/replace (Fri Jan 23 10:07:46 2009 +0100) 7 commits
- environment: add global variable to disable replacement
- mktag: call "check_sha1_signature" with the replacement sha1
- replace_object: add a test case
- object: call "check_sha1_signature" with the replacement sha1
- sha1_file: add a "read_sha1_file_repl" function
- replace_object: add mechanism to replace objects found in
"refs/replace/"
- refs: add a "for_each_replace_ref" function
Nobody has review comments on this yet.
* lh/submodule-tree-traversal (Sun Jan 25 01:52:06 2009 +0100) 6 commits
- archive.c: add support for --submodules[=(all|checkedout)]
- tree.c: allow read_tree_recursive() to traverse gitlink entries
+ Revert round #1 of the series
+ builtin-ls-tree: enable traversal of submodules
+ archive.c: enable traversal of submodules
+ tree.c: add support for traversal of submodules
----------------------------------------------------------------
[Reverted]
* mh/unify-color (Fri Jan 23 01:25:23 2009 -0800) 3 commits
? Revert previous two commits
? move the color variables to color.c
? handle color.ui at a central place
This broke git-format-patch badly.
----------------------------------------------------------------
[Actively cooking]
* js/valgrind (Wed Jan 21 02:36:40 2009 +0100) 2 commits
- valgrind: ignore ldso errors
- Add valgrind support in test scripts
Dscho and Peff had further exchanges on the list; I am sort of waiting for
the conclusion before picking any intermediate version up.
* ks/maint-mailinfo-folded (Tue Jan 13 01:21:04 2009 +0300) 4 commits
+ mailinfo: tests for RFC2047 examples
+ mailinfo: add explicit test for mails like '<a.u.thor@example.com>
(A U Thor)'
+ mailinfo: 'From:' header should be unfold as well
+ mailinfo: correctly handle multiline 'Subject:' header
I just got tired of waiting and cleaned up the series myself.
* js/notes (Tue Jan 13 20:57:16 2009 +0100) 6 commits
+ git-notes: fix printing of multi-line notes
+ notes: fix core.notesRef documentation
+ Add an expensive test for git-notes
+ Speed up git notes lookup
+ Add a script to edit/inspect notes
+ Introduce commit notes
It would be nice to hear a real world success story using the notes
mechanism; Dscho says he also wants to make sure the current choice
of the structure scales well before casting it in stone.
* sc/gitweb-category (Fri Dec 12 00:45:12 2008 +0100) 3 commits
- gitweb: Optional grouping of projects by category
- gitweb: Split git_project_list_body in two functions
- gitweb: Modularized git_get_project_description to be more generic
Design discussion between Jakub and Sebastien continues.
----------------------------------------------------------------
[Graduated to "master"]
* sr/clone-empty (Fri Jan 23 01:07:32 2009 +0100) 1 commit
+ Allow cloning an empty repository
Has anybody actually tried this and made sure the resulting empty clone
works fine after the clone source gets updated with some contents?
* kb/lstat-cache (Sun Jan 18 16:14:54 2009 +0100) 5 commits
+ lstat_cache(): introduce clear_lstat_cache() function
+ lstat_cache(): introduce invalidate_lstat_cache() function
+ lstat_cache(): introduce has_dirs_only_path() function
+ lstat_cache(): introduce has_symlink_or_noent_leading_path()
function
+ lstat_cache(): more cache effective symlink/directory detection
* tr/previous-branch (Wed Jan 21 00:37:38 2009 -0800) 10 commits
+ Simplify parsing branch switching events in reflog
+ Introduce for_each_recent_reflog_ent().
+ interpret_nth_last_branch(): plug small memleak
+ Fix reflog parsing for a malformed branch switching entry
+ Fix parsing of @{-1}@{1}
+ interpret_nth_last_branch(): avoid traversing the reflog twice
+ checkout: implement "-" abbreviation, add docs and tests
+ sha1_name: support @{-N} syntax in get_sha1()
+ sha1_name: tweak @{-N} lookup
+ checkout: implement "@{-N}" shortcut name for N-th last branch
* js/maint-all-implies-HEAD (Sat Jan 17 22:27:08 2009 -0800) 2 commits
+ bundle: allow the same ref to be given more than once
+ revision walker: include a detached HEAD in --all
* cb/add-pathspec (Wed Jan 14 15:54:35 2009 +0100) 2 commits
+ remove pathspec_match, use match_pathspec instead
+ clean up pathspec matching
* js/diff-color-words (Tue Jan 20 22:59:54 2009 -0600) 9 commits
+ Change the spelling of "wordregex".
+ color-words: Support diff.wordregex config option
+ color-words: make regex configurable via attributes
+ color-words: expand docs with precise semantics
+ color-words: enable REG_NEWLINE to help user
+ color-words: take an optional regular expression describing words
+ color-words: change algorithm to allow for 0-character word
boundaries
+ color-words: refactor word splitting and use ALLOC_GROW()
+ Add color_fwrite_lines(), a function coloring each line
individually
----------------------------------------------------------------
[Will merge to "master" soon]
* jg/mergetool (Sat Jan 24 00:12:45 2009 +0100) 1 commit
+ mergetool: Don't repeat merge tool candidates
* cb/mergetool (Wed Jan 21 22:57:48 2009 +0000) 1 commit
+ mergetool: respect autocrlf by using checkout-index
Now Ted told us not to wait for him, we'll go ahead by ourselves ;-).
* jk/signal-cleanup (Thu Jan 22 01:03:28 2009 -0500) 5 commits
+ pager: do wait_for_pager on signal death
+ refactor signal handling for cleanup functions
+ chain kill signals for cleanup functions
+ diff: refactor tempfile cleanup handling
+ Windows: Fix signal numbers
* sp/runtime-prefix (Sun Jan 18 13:00:15 2009 +0100) 7 commits
+ Windows: Revert to default paths and convert them by
RUNTIME_PREFIX
+ Compute prefix at runtime if RUNTIME_PREFIX is set
+ Modify setup_path() to only add git_exec_path() to PATH
+ Add calls to git_extract_argv0_path() in programs that call
git_config_*
+ git_extract_argv0_path(): Move check for valid argv0 from caller
to callee
+ Refactor git_set_argv0_path() to git_extract_argv0_path()
+ Move computation of absolute paths from Makefile to runtime (in
preparation for RUNTIME_PREFIX)
----------------------------------------------------------------
[On Hold]
* jc/commit-assume-also-during-merge (Thu Jan 22 22:21:49 2009 -0800) 3 commits
- git commit: pathspec without -i/-o implies -i semantics during a
merge
- builtin-commit: shorten eye-sore overlong lines
- Add "partial commit" tests during a conflicted merge
This is only meant as a weatherballoon to help facilitate discussion.
* jk/renamelimit (Sat May 3 13:58:42 2008 -0700) 1 commit
. diff: enable "too large a rename" warning when -M/-C is explicitly
asked for
* jc/stripspace (Sun Mar 9 00:30:35 2008 -0800) 6 commits
. git-am --forge: add Signed-off-by: line for the author
. git-am: clean-up Signed-off-by: lines
. stripspace: add --log-clean option to clean up signed-off-by:
lines
. stripspace: use parse_options()
. Add "git am -s" test
. git-am: refactor code to add signed-off-by line for the committer
* jc/post-simplify (Fri Aug 15 01:34:51 2008 -0700) 2 commits
. revision --simplify-merges: incremental simplification
. revision --simplify-merges: prepare for incremental simplification
* jk/valgrind (Thu Oct 23 04:30:45 2008 +0000) 2 commits
. valgrind: ignore ldso errors
. add valgrind support in test scripts
* wp/add-patch-find (Thu Nov 27 04:08:03 2008 +0000) 3 commits
. In add --patch, Handle K,k,J,j slightly more gracefully.
. Add / command in add --patch
. git-add -i/-p: Change prompt separater from slash to comma
^ permalink raw reply
* Re: do you recommend "git" (over svn) for a 1-person team???
From: Ted Pavlic @ 2009-01-29 2:09 UTC (permalink / raw)
To: Greg Hauptmann; +Cc: git
In-Reply-To: <d30068860901281725t14d19c1vc0557182bca3eb8d@mail.gmail.com>
> Do you recommend "git" (over svn) for a 1-person team??? (the
> ability to commit whilst offline on my laptop sounds potentially
> enough reason)
At this point, it is clear that you've bought into using *some* form of
revision control locally. So you are really asking whether DVCS is
appropriate for personal-only use. If all you care about is the ability
to commit locally, then you might as well use vanilla RCS (i.e., the
ultimate "plumbing" behind SVN).
How easy DVCS solutions make merging and rebasing is a secondary feature
for me. Primarily, I like that while doing my work, I don't ever have to
*think* about the revision control. I don't have to check out or lock
files. I don't have to worry about checking in all of my changes. I just
work, and, when I'm ready, the DVCS takes care of everything else. It's
the *overall* ease of use that makes DVCS so valuable to me... (and who
knows... maybe later someone will want to clone my repo and we'll trade
commits back and forth)
[ Keep in mind that git is not the only DVCS. For some of my personal
projects, I use hg (Mercurial), and for others I use git. On none of
them do I use SVN. Unfortunately, the proliferation of SVN on
SourceForge has prevented me from contributed myriad local patches to
projects that are otherwise very important to me. Perhaps another great
reason to use DVCS locally is that you'll be putting implicit pressure
on places like SF to modernize. ]
Best --
Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: do you recommend "git" (over svn) for a 1-person team???
From: James Pickens @ 2009-01-29 2:15 UTC (permalink / raw)
To: Greg Hauptmann; +Cc: git
In-Reply-To: <d30068860901281725t14d19c1vc0557182bca3eb8d@mail.gmail.com>
Greg Hauptmann <greg.hauptmann.ruby@gmail.com> wrote:
> Do you recommend "git" (over svn) for a 1-person team???
Yes, emphatically. I do it myself all the time.
James
^ permalink raw reply
* Re: do you recommend "git" (over svn) for a 1-person team???
From: Garry Dolley @ 2009-01-29 2:21 UTC (permalink / raw)
To: Greg Hauptmann; +Cc: git
In-Reply-To: <d30068860901281725t14d19c1vc0557182bca3eb8d@mail.gmail.com>
On Thu, Jan 29, 2009 at 11:25:56AM +1000, Greg Hauptmann wrote:
> Hi,
>
> Do you recommend "git" (over svn) for a 1-person team??? (the
> ability to commit whilst offline on my laptop sounds potentially
> enough reason)
Absolutely. I have several repos on my filesystem and also a server
that are for myself only.
--
Garry Dolley
ARP Networks, Inc. http://www.arpnetworks.com
Data center, VPS, and IP transit solutions (818) 206-0181
Member Los Angeles County REACT, Unit 336 WQGK336
Blog http://scie.nti.st
^ permalink raw reply
* Re: do you recommend "git" (over svn) for a 1-person team???
From: Martin Langhoff @ 2009-01-29 2:28 UTC (permalink / raw)
To: James Pickens; +Cc: Greg Hauptmann, git
In-Reply-To: <885649360901281815q42199468v8658d864386efe2d@mail.gmail.com>
On Thu, Jan 29, 2009 at 3:15 PM, James Pickens <jepicken@gmail.com> wrote:
> Greg Hauptmann <greg.hauptmann.ruby@gmail.com> wrote:
>> Do you recommend "git" (over svn) for a 1-person team???
>
> Yes, emphatically. I do it myself all the time.
+1!
- offline work on your laptop
- "git stash"
- keep various branches (experimental, feature, stable...), with
untold flexibility for cherrypicking, merges, etc
- bisect!
- visualise things with gitk
- search with gitk for specific bits of code, changes (pickaxe), etc
once you start... it's a bit addictive...
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: (beginner) git rm
From: Björn Steinbrink @ 2009-01-29 2:34 UTC (permalink / raw)
To: Jonathan Wills; +Cc: Junio C Hamano, Zabre, git
In-Reply-To: <6bef44ba0901281711m2d05e70fj4dd3ae03d7fe1052@mail.gmail.com>
On 2009.01.28 17:11:07 -0800, Jonathan Wills wrote:
> This seems like an appropriate thread to ask something I came across today.
> Either I am unclear about the precise semantics of git checkout <branch>
> <path>, or there is a bug in said command. I noticed this when I wanted to
> get a directory to match the same directory in another branch, so I did rm
> -rf dir, followed by git checkout master dir. Afterwards I noticed that
> files in that directory that had previously been in my branch but were not
> in the master branch had returned. Earlier in this thread it was mentioned
> that git checkout will not remove files, but in this case I had already
> removed those files and git checkout actually replaced them (and not from
> the master branch like I asked, but from the current branch).
This is exactly what I meant. Your "rm -rf dir" only removed the
directory from the working tree, but _not_ from the index. And what
"git checkout master -- dir" then does is that it puts all the stuff
that is in master's "dir" into the index, in _addition_ to the stuff
already in the index. And then it puts everything from the index's "dir"
into the working tree. This is really a two step process and in each
step the pathspec is matched separately.
So the working tree doesn't have "dir" at all.
In the index you still have:
whatever
dir/file (index version)
dir/other_file
In master you have:
whatever_2
dir/file (master version)
dir/yet_another_file
Then you do "git checkout master -- dir".
In the first step, that "dir" pathspec matches these files from master:
dir/file
dir/yet_another_file
So those are added to the index, and the index will have:
whatever
dir/file (master version)
dir/other_file
dir/yet_another_file
So "dir/file" was replaced, and "dir/yet_another_file" was added. But
"dir/other_file" is still around.
And then comes the index -> working tree step. The pathspec matches all
three files in "dir" in the index, and so they appear in the working
tree.
To get what you expected, you have several options:
a)
rm -rf dir
git add -u dir (drops it from the index)
git checkout master -- dir
b)
git rm -rf dir
git checkout master -- dir
Just saves the "git add -u" step.
c)
rm -rf dir
git reset master -- dir
git checkout -- dir
The reset makes "dir" in the index equal to master's "dir" (ok,
technically that's wrong, as the index doesn't even know about "dir" on
its own, but my brain fails to produce a correct description).
Björn
^ permalink raw reply
* Re: do you recommend "git" (over svn) for a 1-person team???
From: Greg Hauptmann @ 2009-01-29 2:46 UTC (permalink / raw)
To: Martin Langhoff; +Cc: James Pickens, git
In-Reply-To: <46a038f90901281828t16ace3bdocc897eb5235d7c30@mail.gmail.com>
does the concept of me setting up my own central git server as well
make any sense from the point of view of a way to ensure I can (when
I'm not remote) "check-in" to the central git server & thereby keep a
separate copy of my code (i.e. effectively a backup)
2009/1/29 Martin Langhoff <martin.langhoff@gmail.com>:
> On Thu, Jan 29, 2009 at 3:15 PM, James Pickens <jepicken@gmail.com> wrote:
>> Greg Hauptmann <greg.hauptmann.ruby@gmail.com> wrote:
>>> Do you recommend "git" (over svn) for a 1-person team???
>>
>> Yes, emphatically. I do it myself all the time.
>
> +1!
>
> - offline work on your laptop
> - "git stash"
> - keep various branches (experimental, feature, stable...), with
> untold flexibility for cherrypicking, merges, etc
> - bisect!
> - visualise things with gitk
> - search with gitk for specific bits of code, changes (pickaxe), etc
>
> once you start... it's a bit addictive...
>
>
> m
> --
> martin.langhoff@gmail.com
> martin@laptop.org -- School Server Architect
> - ask interesting questions
> - don't get distracted with shiny stuff - working code first
> - http://wiki.laptop.org/go/User:Martinlanghoff
>
--
Greg
http://blog.gregnet.org/
^ permalink raw reply
* Re: How to install and use a custom merge driver
From: Jeff King @ 2009-01-29 3:25 UTC (permalink / raw)
To: Alec Clews; +Cc: git
In-Reply-To: <loom.20090128T230123-889@post.gmane.org>
On Wed, Jan 28, 2009 at 11:04:02PM +0000, Alec Clews wrote:
> I fixed that problem -- however it did not make any difference.
Can you post an exact recipe for recreating the problem? It works just
fine here, using:
-- >8 --
commit() {
echo $1 >file && git add file && git commit -m $1
}
mkdir repo && cd repo && git init
commit base
commit branch-master
git checkout -b other HEAD^
commit branch-other
echo '* merge=overwrite' >.git/info/attributes
cat >>.git/config <<'EOF'
[merge "overwrite"]
name = overwrite using cp
driver= cp %B %A
EOF
git merge master
-- 8< --
I get an automatic merge with the contents from "master" (and without
the merge config, there is obviously a conflict).
> Is there someway to enable logging to see how git is making this choice?
You can try "git check-attr merge file" to be sure that it is picking up
the attribute.
-Peff
^ permalink raw reply
* Re: do you recommend "git" (over svn) for a 1-person team???
From: Ted Pavlic @ 2009-01-29 3:27 UTC (permalink / raw)
To: Martin Langhoff; +Cc: James Pickens, Greg Hauptmann, git
In-Reply-To: <46a038f90901281828t16ace3bdocc897eb5235d7c30@mail.gmail.com>
> - "git stash"
Not to mention StGit, which can achieve many of the same things as "git
stash" while also letting you toy with your changeset history (which is
definitely permissible on personal repos).
> - visualise things with gitk
> - search with gitk for specific bits of code, changes (pickaxe), etc
Not to mention tig, the wonderful ncurses (i.e., Terminal-based) tool
recently announced on this mailing list.
(and "git grep", of course)
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: do you recommend "git" (over svn) for a 1-person team???
From: Ted Pavlic @ 2009-01-29 3:31 UTC (permalink / raw)
To: Greg Hauptmann; +Cc: Martin Langhoff, James Pickens, git
In-Reply-To: <d30068860901281846v65baf431mdab5fe961ef9407d@mail.gmail.com>
> does the concept of me setting up my own central git server as well
> make any sense from the point of view of a way to ensure I can (when
> I'm not remote) "check-in" to the central git server& thereby keep a
> separate copy of my code (i.e. effectively a backup)
You can always keep local clones that serve as "stable" backup repos.
However, I think most people would suggest you just create
stable/experimental branches and merge from one to the other as
appropriate.
If you need some nice working examples of people using git for personal
projects, I recommend you search Google for the many ways of using git
to manage home directories. Applying git to home directory management
involves many of the same questions (and answers) as what you're
bringing up here, and it probably will give you some ideas about the
most effective git usage for your case.
--Ted
--
Ted Pavlic <ted@tedpavlic.com>
Please visit my ALS association page:
http://web.alsa.org/goto/tedpavlic
My family appreciates your support in the fight to defeat ALS.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Jeff King @ 2009-01-29 3:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vwscej26i.fsf@gitster.siamese.dyndns.org>
On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:
> * js/valgrind (Wed Jan 21 02:36:40 2009 +0100) 2 commits
> - valgrind: ignore ldso errors
> - Add valgrind support in test scripts
>
> Dscho and Peff had further exchanges on the list; I am sort of waiting for
> the conclusion before picking any intermediate version up.
I think I gave an OK to the last version posted, but then the last thing
I saw from Dscho was "I have a new patch, but I'm not posting it right
this second":
http://article.gmane.org/gmane.comp.version-control.git/107300
followed by much "is zlib broken" discussion which I think doesn't hold
us up (either it is a bug in zlib, in which case it is not our problem,
or it is a false positive, in which case we just add a suppression).
So I think we are waiting for the next round from Johannes.
> * jk/valgrind (Thu Oct 23 04:30:45 2008 +0000) 2 commits
> . valgrind: ignore ldso errors
> . add valgrind support in test scripts
I think it probably makes sense to drop these at this point. Dscho's
more recent work should be the basis to which new patches are compared.
-Peff
^ permalink raw reply
* Re: Git SVN fetch failing on large commit
From: Andrew Selder @ 2009-01-29 3:43 UTC (permalink / raw)
To: git
In-Reply-To: <loom.20090129T011905-417@post.gmane.org>
Andrew Selder <aselder <at> mac.com> writes:
>
> Hi,
>
> I'm trying to import an SVN repository and I'm running into trouble on a huge
> SVN revision.
>
> One of the revisions in SVN has a 1.25 GB file. When the git svn fetch process
> gets to this revision, it crashed with the following message:
>
> fatal: Out of memory, malloc failed
> hash-object -w --stdin-paths: command returned error: 128
> This is running on a machine with 3 GB of memory (2.5 GB free before starting
> git svn), Git 1.6.1, Git-svn 1.6.1(svn 1.5.1)
Upgraded to Git 1.6.1.1, but still the same results. I saw the --ignore-paths
option online, but it doesn't seem to be in the lastest version. This would
probably work for me. Does anybody know when that feature is scheduled for
release?
^ permalink raw reply
* Re: [StGit PATCH] Check for local changes with "goto"
From: Karl Hasselström @ 2009-01-29 3:45 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
In-Reply-To: <20090128231305.16133.29214.stgit@localhost.localdomain>
On 2009-01-28 23:13:05 +0000, Catalin Marinas wrote:
> This is done by default, unless the --keep option is passed, for
> consistency with the "pop" command. The index is checked in the
> Transaction.run() function so that other commands could benefit from
> this feature (off by default).
This looks good, except for ...
> + # Check for not clean index
> + if check_clean and iw and not iw.index.is_clean():
> + self.__halt('Repository not clean. Use "refresh" or '
> + '"status --reset"')
... this, which doesn't do what I think you think it does.
Index.is_clean() calls "git update-index --refresh", which checks for
changes in the worktree relative to the index. It's bad design to have
it in Index rather than IndexAndWorktree, but that's my fault, not
yours. ;-) But the point that breaks your patch is that it doesn't
check for changes between index and HEAD -- try it and see.
The fix I'd suggest is to move the existing is_clean() method to
IndexAndWorktree, and call it maybe worktree_clean(). And create a
method in Index() called is_clean(tree) that checks whether the index
is clean with respect to the given Tree (I think this method should
just call "git diff-index --quiet --cached <tree>".). Then call both
of these methods.
Sorry if I just keep creating more work for you. :-/
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Jeff King @ 2009-01-29 3:51 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, git
In-Reply-To: <7vwscej26i.fsf@gitster.siamese.dyndns.org>
On Wed, Jan 28, 2009 at 06:06:45PM -0800, Junio C Hamano wrote:
> * sr/clone-empty (Fri Jan 23 01:07:32 2009 +0100) 1 commit
> + Allow cloning an empty repository
>
> Has anybody actually tried this and made sure the resulting empty clone
> works fine after the clone source gets updated with some contents?
Hmm. It sort of works:
$ mkdir parent && (cd parent && git init)
Initialized empty Git repository in /home/peff/parent/.git/
$ git clone parent child
Initialized empty Git repository in /home/peff/child/.git/
warning: You appear to have cloned an empty repository.
So far so good...
$ (cd parent && echo content >file && git add file && git commit -m one)
[normal commit output]
$ (cd child && git fetch)
[normal fetch output]
But:
$ (cd child && git pull)
You asked me to pull without telling me which branch you
want to merge with, and 'branch.master.merge' in
...
So it's not quite seamless. The problem is that we're not setting up the
branch.master.* config on the empty clone. Nor do we set up
refs/remotes/origin/HEAD.
On top of that, I get funniness between versions:
$ ssh peff.net 'git version && mkdir foo && cd foo && git init'
git version 1.5.6.5
Initialized empty Git repository in /mnt/data/home/peff/foo/.git/
$ git clone peff.net:foo
Initialized empty Git repository in /home/peff/foo/.git/
warning: You appear to have cloned an empty repository.
$ fatal: The remote end hung up unexpectedly
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Jeff King @ 2009-01-29 4:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, git
In-Reply-To: <20090129035138.GC11836@coredump.intra.peff.net>
On Wed, Jan 28, 2009 at 10:51:38PM -0500, Jeff King wrote:
> But:
>
> $ (cd child && git pull)
> You asked me to pull without telling me which branch you
> want to merge with, and 'branch.master.merge' in
> ...
>
> So it's not quite seamless. The problem is that we're not setting up the
> branch.master.* config on the empty clone. Nor do we set up
> refs/remotes/origin/HEAD.
Hrm. I was thinking we checked out "master" as a branch yet to be born,
but of course that doesn't work because we don't even know that the name
"master" exists on the other side (to do that, we would need an
extension to transmit symref information for a ref yet to be born).
We could always assume the remote side is going to eventually put
content on "master" (we know they aren't using another branch _now_, or
the repo wouldn't be empty, so we are just guessing they will follow the
usual convention). That feels a bit hack-ish, though.
So the current behavior is probably sane. But it is not obvious to a
user how to extend their repo one the upstream isn't empty. Maybe the
"empty repo" warning could mention "git fetch && git checkout -b master
origin/master" (which is the most obvious way I can think of)?
-Peff
^ permalink raw reply
* Re: do you recommend "git" (over svn) for a 1-person team???
From: Jeff King @ 2009-01-29 4:05 UTC (permalink / raw)
To: Greg Hauptmann; +Cc: Martin Langhoff, James Pickens, git
In-Reply-To: <d30068860901281846v65baf431mdab5fe961ef9407d@mail.gmail.com>
On Thu, Jan 29, 2009 at 12:46:56PM +1000, Greg Hauptmann wrote:
> does the concept of me setting up my own central git server as well
> make any sense from the point of view of a way to ensure I can (when
> I'm not remote) "check-in" to the central git server & thereby keep a
> separate copy of my code (i.e. effectively a backup)
Yes, that is exactly what I do, because:
- my central server is backed up, but my workstations are not
- my central server is accessible remotely, but my workstations are
not. So that is how I get code from one box to the other.
-Peff
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #07; Wed, 28)
From: Junio C Hamano @ 2009-01-29 4:22 UTC (permalink / raw)
To: Jeff King; +Cc: Sverre Rabbelier, git
In-Reply-To: <20090129040254.GD11836@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> We could always assume the remote side is going to eventually put
> content on "master" (we know they aren't using another branch _now_, or
> the repo wouldn't be empty, so we are just guessing they will follow the
> usual convention). That feels a bit hack-ish, though.
Now, doesn't "The other end is empty" error start looking much saner than
everybody seems to have thought ;-)?
^ permalink raw reply
* Re: How to install and use a custom merge driver
From: Alec Clews @ 2009-01-29 4:47 UTC (permalink / raw)
To: git
In-Reply-To: <20090129032531.GA11836@coredump.intra.peff.net>
Problem solved.
It appears that TAB is not supported as white space in either attributes or
config files? I removed all the tabs and it works as described on the box
Many many thanks for the help Jeff
- Alec
^ permalink raw reply
* [PATCH] symbolic ref: refuse non-ref targets in HEAD
From: Jeff King @ 2009-01-29 4:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When calling "git symbolic-ref" it is easy to forget that
the target must be a fully qualified ref. E.g., you might
accidentally do:
$ git symbolic-ref HEAD master
Unfortunately, this is very difficult to recover from,
because the bogus contents of HEAD make git believe we are
no longer in a git repository (as is_git_dir explicitly
checks for "^refs/" in the HEAD target). So immediately
trying to fix the situation doesn't work:
$ git symbolic-ref HEAD refs/heads/master
fatal: Not a git repository
and one is left editing the .git/HEAD file manually.
Furthermore, one might be tempted to use symbolic-ref to set
up a detached HEAD:
$ git symbolic-ref HEAD `git rev-parse HEAD`
which sets up an even more bogus HEAD:
$ cat .git/HEAD
ref: 1a9ace4f2ad4176148e61b5a85cd63d5604aac6d
This patch introduces a small safety valve to prevent the
specific case of anything not starting with refs/ to go into
HEAD. The scope of the safety valve is intentionally very
limited, to make sure that we are not preventing any
behavior that would otherwise be valid (like pointing a
different symref than HEAD outside of refs/).
Signed-off-by: Jeff King <peff@peff.net>
---
This is a follow-up to a patch that I posted during the last release
freeze:
http://article.gmane.org/gmane.comp.version-control.git/103445
I know that using symbolic-ref manually is rare, but both I and the
original poster have been bitten by this (and figuring out what is going
on and fixing it is quite painful). But most importantly, I don't think
this can possibly hurt anyone trying to use this legitimately, since the
exact thing it is protecting against corrupts your repo. :)
Please beware that running the test script on the current "master" will
actually hose your git repo (test 3 kills the trash directory's
.git/HEAD, which means test 4 thinks your parent .git/ is its current
repo). Maybe it makes sense to do a precautionary reset in between.
builtin-symbolic-ref.c | 2 ++
t/t1401-symbolic-ref.sh | 27 +++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
create mode 100755 t/t1401-symbolic-ref.sh
diff --git a/builtin-symbolic-ref.c b/builtin-symbolic-ref.c
index bfc78bb..46ea4b2 100644
--- a/builtin-symbolic-ref.c
+++ b/builtin-symbolic-ref.c
@@ -44,6 +44,8 @@ int cmd_symbolic_ref(int argc, const char **argv, const char *prefix)
check_symref(argv[0], quiet);
break;
case 2:
+ if (!strcmp(argv[0], "HEAD") && prefixcmp(argv[1], "refs/"))
+ die("Refusing to point HEAD outside of refs/");
create_symref(argv[0], argv[1], msg);
break;
default:
diff --git a/t/t1401-symbolic-ref.sh b/t/t1401-symbolic-ref.sh
new file mode 100755
index 0000000..1f22009
--- /dev/null
+++ b/t/t1401-symbolic-ref.sh
@@ -0,0 +1,27 @@
+#!/bin/sh
+
+test_description='basic symbolic-ref tests'
+. ./test-lib.sh
+
+test_expect_success 'symbolic-ref writes HEAD' '
+ git symbolic-ref HEAD refs/heads/foo &&
+ echo ref: refs/heads/foo >expect &&
+ test_cmp expect .git/HEAD
+'
+
+test_expect_success 'symbolic-ref reads HEAD' '
+ echo refs/heads/foo >expect &&
+ git symbolic-ref HEAD >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'symbolic-ref refuses non-ref branch for HEAD' '
+ test_must_fail git symbolic-ref HEAD foo
+'
+
+test_expect_success 'symbolic-ref refuses bare sha1' '
+ echo content >file && git add file && git commit -m one
+ test_must_fail git symbolic-ref HEAD `git rev-parse HEAD`
+'
+
+test_done
--
1.6.1.1.424.gac728
^ permalink raw reply related
* Re: How to install and use a custom merge driver
From: Jeff King @ 2009-01-29 5:03 UTC (permalink / raw)
To: Alec Clews; +Cc: git
In-Reply-To: <loom.20090129T044425-689@post.gmane.org>
On Thu, Jan 29, 2009 at 04:47:19AM +0000, Alec Clews wrote:
> It appears that TAB is not supported as white space in either attributes or
> config files? I removed all the tabs and it works as described on the box
That's odd. It should be fine. And if I repeat the test I posted with:
printf '*\tmerge=overwrite\n' >.git/info/attributes
(printf '[merge "overwrite"]\n'
printf '\tname = overwrite using cp\n'
printf '\tdriver = cp %%B %%A\n'
) >>.git/config
it works as before.
What git version are you using? Can you post a shell snippet that breaks
reliably?
-Peff
^ permalink raw reply
* Re: "malloc failed"
From: Jeff King @ 2009-01-29 5:14 UTC (permalink / raw)
To: Pau Garcia i Quiles; +Cc: David Abrahams, git
In-Reply-To: <3af572ac0901281416x5adef0eak89bd4b40fda52c2b@mail.gmail.com>
On Wed, Jan 28, 2009 at 11:16:32PM +0100, Pau Garcia i Quiles wrote:
> My case: I have a 500 MB repository with a 1GB working tree, with
> binary files ranging from 100KB to 50MB and a few thousand source
> files.
>
> I have two branches ('master' and 'cmake') and the latter has suffered
> a huge hierarchy reorganization.
>
> When I merge 'master' in 'cmake', if I use the 'subtree' strategy, it
> works fine. If I use any other strategy, after a couple of minutes I
> receive a "malloc failed" and the tree is all messed up. As I said, on
> Linux it works fine, so maybe it's a Windows-specific problem.
Hmm. It very well might be the rename detection allocating a lot of
memory to do inexact rename detection. It does try to limit the amount
of work, but based on number of files. So if you have a lot of huge
files, that might be fooling it.
Try setting merge.renamelimit to something small (but not '0', which
means "no limit").
-Peff
^ permalink raw reply
* Re: "malloc failed"
From: Jeff King @ 2009-01-29 5:20 UTC (permalink / raw)
To: David Abrahams; +Cc: git
In-Reply-To: <87skn3rn5n.fsf@mcbain.luannocracy.com>
On Wed, Jan 28, 2009 at 07:06:28PM -0500, David Abrahams wrote:
> Well, moving the 2.6G .dar backup binary out of the fileset seems to
> have helped a little, not surprisingly :-P
Ok, that _is_ big. ;) I wouldn't be surprised if there is some corner of
the code that barfs on a single object that doesn't fit in a signed
32-bit integer; I don't think we have any test coverage for stuff that
big.
But it may also just be that we are going to try malloc'ing 2.6G, and
that's making some system limit unhappy.
> I don't know whether anyone on this list should care about that failure
> given the level of abuse I'm inflicting on Git, but keep in mind that
> the system *does* have 8G of memory. Conclude what you will from that,
> I suppose!
Well, I think you said before that you were never getting close to using
up all your memory. Which implies it's some system limit.
-Peff
^ permalink raw reply
* Re: "malloc failed"
From: Jeff King @ 2009-01-29 5:56 UTC (permalink / raw)
To: David Abrahams; +Cc: Junio C Hamano, git
In-Reply-To: <20090129052041.GB31507@coredump.intra.peff.net>
On Thu, Jan 29, 2009 at 12:20:41AM -0500, Jeff King wrote:
> Ok, that _is_ big. ;) I wouldn't be surprised if there is some corner of
> the code that barfs on a single object that doesn't fit in a signed
> 32-bit integer; I don't think we have any test coverage for stuff that
> big.
Sure enough, that is the problem. With the patch below I was able to
"git add" and commit a 3 gigabyte file of random bytes (so even the
deflated object was 3G).
I think it might be worth applying as a general cleanup, but I have no
idea if other parts of the system might barf on such an object.
-- >8 --
Subject: [PATCH] avoid 31-bit truncation in write_loose_object
The size of the content we are adding may be larger than
2.1G (i.e., "git add gigantic-file"). Most of the code-path
to do so uses size_t or unsigned long to record the size,
but write_loose_object uses a signed int.
On platforms where "int" is 32-bits (which includes x86_64
Linux platforms), we end up passing malloc a negative size.
Signed-off-by: Jeff King <peff@peff.net>
---
sha1_file.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 360f7e5..8868b80 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2340,7 +2340,8 @@ static int create_tmpfile(char *buffer, size_t bufsiz, const char *filename)
static int write_loose_object(const unsigned char *sha1, char *hdr, int hdrlen,
void *buf, unsigned long len, time_t mtime)
{
- int fd, size, ret;
+ int fd, ret;
+ size_t size;
unsigned char *compressed;
z_stream stream;
char *filename;
--
1.6.1.1.259.g8712.dirty
^ permalink raw reply related
* Something weird is happening...
From: H. Peter Anvin @ 2009-01-29 6:24 UTC (permalink / raw)
To: Git Mailing List; +Cc: Ingo Molnar
I was investigating a problem that Ingo Molnar reported on the
linux-2.6-tip.git repository on kernel.org. Unfortunately I was not
able to reproduce his problem (which is a problem in itself) but I did
run into another oddity:
: hera 4 ; git fsck
[lots of dangling commits deleted]
missing blob af0e01d4c663a101f48614e40d006ed6272d5c36
: hera 5 ; git cat-file blob af0e01d4c663a101f48614e40d006ed6272d5c36
/*
* debugfs.h - a tiny little debug file system
*
* Copyright (C) 2004 Greg Kroah-Hartman <greg@kroah.com>
* Copyright (C) 2004 IBM Inc.
*
[... rest of blob deleted ...]
Okay, what is going on here?
Since git 1.6.1.1 just got installed on kernel.org, this phenomenon (and
hopefully Ingo's problem, too) maybe has something to do with this new
version?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
^ permalink raw reply
* Re: Something weird is happening...
From: Junio C Hamano @ 2009-01-29 6:56 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: Git Mailing List, Ingo Molnar
In-Reply-To: <49814BA4.6030705@zytor.com>
"H. Peter Anvin" <hpa@zytor.com> writes:
> I was investigating a problem that Ingo Molnar reported on the
> linux-2.6-tip.git repository on kernel.org. Unfortunately I was not
> able to reproduce his problem (which is a problem in itself) but I did
> run into another oddity:
>
> : hera 4 ; git fsck
>
> [lots of dangling commits deleted]
> missing blob af0e01d4c663a101f48614e40d006ed6272d5c36
>
> : hera 5 ; git cat-file blob af0e01d4c663a101f48614e40d006ed6272d5c36
> /*
> * debugfs.h - a tiny little debug file system
> *
> * Copyright (C) 2004 Greg Kroah-Hartman <greg@kroah.com>
> * Copyright (C) 2004 IBM Inc.
> *
> [... rest of blob deleted ...]
>
> Okay, what is going on here?
Does "git fsck --full" report the blob missing?
^ 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