* Re: [PATCH] add -u: do not fail to resolve a path as deleted
From: Junio C Hamano @ 2009-01-29 0:13 UTC (permalink / raw)
To: git
In-Reply-To: <7viqnzj9ay.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> This is wrong; breaks t3702.
Ugh; that is a bogus test. Please disregard.
^ permalink raw reply
* Re: Valgrind updates
From: Mark Adler @ 2009-01-29 0:15 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Linus Torvalds, Jean-loup Gailly, Mark Brown, Jeff King,
Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0901290024290.3586@pacific.mpi-cbg.de>
On Jan 28, 2009, at 3:27 PM, Johannes Schindelin wrote:
> On Wed, 28 Jan 2009, Mark Adler wrote:
>> 2. Can someone send me the input and the 58 bytes of output from
>> this
>> case?
>
> I did better than that already...
> http://article.gmane.org/gmane.comp.version-control.git/107391
Johannes,
Thanks for the input and code. When I run it, the byte in question at
offset 51 is 0x2c. The output decompresses fine and the result
matches the input. If I change the 0x2c to anything else,
decompression fails. The 58 bytes are below.
Can you also send me the 58 bytes of output that you get when you run
it? Thanks.
Mark
78 01 2b 29 4a 4d 55 30 34 33 65 30 34 30 30 33
31 51 48 cb cc 49 35 64 10 60 c0 04 48 0a 8c 18
14 30 e5 91 4d 30 66 30 c0 af c0 84 c1 01 bf 02
53 86 00 2c 0a 00 86 79 13 07
^ permalink raw reply
* Re: [PATCH/RFC v1 5/6] combine-diff.c: remove a call to fstat() inside show_patch_diff()
From: Junio C Hamano @ 2009-01-29 1:16 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git
In-Reply-To: <7v63jznp58.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Kjetil Barvik <barvik@broadpark.no> writes:
>
>> Currently inside show_patch_diff() we have and fstat() call after an
>> ok lstat() call. Since we before the call to fstat() have already
>> test for the link case with S_ISLNK() the fstat() can be removed.
>
> Good eyes. Thanks.
Heh, I noticed you will update the commit log message, so I'll dequeue
this and wait for an update.
^ permalink raw reply
* git reset --merge misdocumented?
From: Johannes Schindelin @ 2009-01-29 1:17 UTC (permalink / raw)
To: git
Hi,
from the man page I thought that --merge would be just another way to say
"git read-tree -u -m".
In particular, the man page says _nothing_ about resetting HEAD to
something else.
Maybe somebody with l33ter dox skillz than me would like to fix that.
Ciao,
Dscho
^ permalink raw reply
* Git SVN fetch failing on large commit
From: Andrew Selder @ 2009-01-29 1:24 UTC (permalink / raw)
To: git
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
error closing pipe: Bad file descriptor at /usr/local/libexec/git-core//git-svn
line 0
error closing pipe: Bad file descriptor at /usr/local/libexec/git-core//git-svn
line 0
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)
Help would be greatly appreciated.
^ permalink raw reply
* Re: do you recommend "git" (over svn) for a 1-person team???
From: Greg Hauptmann @ 2009-01-29 1:25 UTC (permalink / raw)
To: git
In-Reply-To: <d30068860901281718x363348caya2dc94e798cc8091@mail.gmail.com>
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)
Tks
^ permalink raw reply
* Re: do you recommend "git" (over svn) for a 1-person team???
From: Sverre Rabbelier @ 2009-01-29 1:38 UTC (permalink / raw)
To: Greg Hauptmann; +Cc: git
In-Reply-To: <d30068860901281725t14d19c1vc0557182bca3eb8d@mail.gmail.com>
Heya,
On Thu, Jan 29, 2009 at 02:25, Greg Hauptmann
<greg.hauptmann.ruby@gmail.com> wrote:
> Do you recommend "git" (over svn) for a 1-person team??? (the
> ability to commit whilst offline on my laptop sounds potentially
> enough reason)
Are you seriously asking if you should git instead of svn on the git
mailing list, or am I missing something? :P.
Seriously though, yes, git works very nicely for 1-person teams as
well as for large teams. Especially the ability to "git init && git
add . && git commit -m 'got part of the assignment done'" has helped
me a lot.
Before I started using git I would come to the point where I thought
'ah, good, it almost works, now all I have to do is add feature x, and
then 10 minutes later I'd be wishing I had used some form of revision
control so I could go back to that working version!
</testemonial>
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] builtin-apply.c: do not set bogus mode in check_preimage() for deleted path
From: Don Zickus @ 2009-01-29 1:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Alexander Potashev
In-Reply-To: <7vocxrj9j9.fsf@gitster.siamese.dyndns.org>
On Wed, Jan 28, 2009 at 03:27:54PM -0800, Junio C Hamano wrote:
> Also I suspect this codepath has been broken the use case 7a07841
> (git-apply: handle a patch that touches the same path more than once
> better, 2008-06-27) wanted to support, and if that is the case, this
> would fix it.
Actually deleting patches weren't that interesting to me, I deal more with
patches modifying the same patch repeatedly. Regardless the patch below
seems ok to me.
Acked-by: Don Zickus <dzickus@redhat.com>
>
> builtin-apply.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/builtin-apply.c b/builtin-apply.c
> index b415daf..1e7f917 100644
> --- a/builtin-apply.c
> +++ b/builtin-apply.c
> @@ -2453,7 +2453,7 @@ static int check_preimage(struct patch *patch, struct cache_entry **ce, struct s
> if (st_mode != patch->old_mode)
> fprintf(stderr, "warning: %s has type %o, expected %o\n",
> old_name, st_mode, patch->old_mode);
> - if (!patch->new_mode)
> + if (!patch->new_mode && !patch->is_delete)
> patch->new_mode = st_mode;
> return 0;
>
> --
> 1.6.1.1.278.g6a817
>
^ permalink raw reply
* Re: do you recommend "git" (over svn) for a 1-person team???
From: david @ 2009-01-29 2:57 UTC (permalink / raw)
To: Greg Hauptmann; +Cc: git
In-Reply-To: <d30068860901281725t14d19c1vc0557182bca3eb8d@mail.gmail.com>
On Thu, 29 Jan 2009, 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)
well, if you use svn just put the svn repository on your laptop.
but if you use multiple systems you aren't really a 1-person team, you
just happen to be one person working in different places.
also the distributed nature of git will make doing (and maintaining)
backups easier, as well as recovering from the inevitable cases where you
do development seperatly on your different machines and then need to
combine them.
David Lang
^ permalink raw reply
* Re: Valgrind updates
From: Linus Torvalds @ 2009-01-29 1:56 UTC (permalink / raw)
To: Johannes Schindelin
Cc: zlib, valgrind-users, Mark Brown, Jeff King, Junio C Hamano,
Git Mailing List
In-Reply-To: <alpine.DEB.1.00.0901272241250.14855@racer>
On Tue, 27 Jan 2009, Johannes Schindelin wrote:
>
> To help ye Gods, I put together this almost minimal C program:
This one is buggy.
> out = fopen("/dev/null", "w");
> fwrite(compressed + 51, 51, 1, out);
> fwrite(compressed + 51, 1, 1, stderr);
> fflush(out);
> fclose(out);
The problem is that the first argument to that first "fwrite()" is simply
wrong. It shouldn't be "compressed + 51", it should be just "compressed".
As it is, you're writing 51 bytes, starting at 51 bytes in, and that's
obviously not correct (you only got 58 bytes from deflate()).
So valgrind does complain about it, but for a perfectly valid reason.
So I think your minimal C program isn't actually showing what you wanted
to show, and isn't showing the behaviour you see in git.
Linus
^ permalink raw reply
* What's in git.git (Jan 2009, #04; Wed, 28)
From: Junio C Hamano @ 2009-01-29 2:06 UTC (permalink / raw)
To: git
Folks at Github found that v1.6.1 clients barf when pushing over git
protocol to v1.6.1 server if (1) the repository pushed into borrows
objects from another repository, and (2) the repository that lends the
objects has updates the pusher does not have. The 'maint' branch has a
fix for it which 1.6.1.2 will contain when it comes out.
The master has accumulated enough new features; we should start the -rc
freeze soon (with the topics we have in 'next' as of today).
* The 'maint' branch has these fixes since the last announcement.
Johannes Schindelin (2):
get_sha1_basic(): fix invalid memory access, found by valgrind
test-path-utils: Fix off by one, found by valgrind
Junio C Hamano (2):
GIT 1.6.1.1
send-pack: do not send unknown object name from ".have" to pack-objects
* The 'master' branch has these since the last announcement
in addition to the above.
Benjamin Kramer (1):
Ignore test-ctype
Boyd Stephen Smith Jr (2):
color-words: Support diff.wordregex config option
Change the spelling of "wordregex".
Clemens Buchacher (2):
clean up pathspec matching
remove pathspec_match, use match_pathspec instead
Eric Wong (1):
git-svn: fix memory leak when checking for empty symlinks
Giuseppe Bilotta (6):
gitweb: channel image in rss feed
gitweb: feed generator metadata
gitweb: rss feed managingEditor
gitweb: rss channel date
gitweb: last-modified time should be commiter, not author
gitweb: check if-modified-since for feeds
Jay Soffian (1):
git-am: minor cleanups
Johannes Schindelin (7):
Add color_fwrite_lines(), a function coloring each line individually
color-words: refactor word splitting and use ALLOC_GROW()
color-words: change algorithm to allow for 0-character word boundaries
color-words: take an optional regular expression describing words
revision walker: include a detached HEAD in --all
Fix parsing of @{-1}@{1}
rebase -i --root: fix check for number of arguments
Johannes Sixt (1):
Windows: Fix intermittent failures of t7701
Junio C Hamano (10):
checkout: implement "@{-N}" shortcut name for N-th last branch
bundle: allow the same ref to be given more than once
interpret_nth_last_branch(): avoid traversing the reflog twice
Fix reflog parsing for a malformed branch switching entry
interpret_nth_last_branch(): plug small memleak
Introduce for_each_recent_reflog_ent().
Simplify parsing branch switching events in reflog
http-push.c: style fixes
rebase -i: correctly remember --root flag across --continue
tests: Avoid single-shot environment export for shell function invocation
Kjetil Barvik (5):
lstat_cache(): more cache effective symlink/directory detection
lstat_cache(): introduce has_symlink_or_noent_leading_path() function
lstat_cache(): introduce has_dirs_only_path() function
lstat_cache(): introduce invalidate_lstat_cache() function
lstat_cache(): introduce clear_lstat_cache() function
Miklos Vajna (1):
gittutorial: remove misleading note
Nanako Shiraishi (1):
Mention "local convention" rule in the CodingGuidelines
Serge van den Boom (1):
Makefile: Make 'configure --with-expat=path' actually work
Sverre Rabbelier (1):
Allow cloning an empty repository
Ted Pavlic (1):
make: Remove -pthread on Darwin (it is included by cstdlib).
Teemu Likonen (1):
diff-options.txt: Fix asciidoc markup issue
Thomas Rast (7):
color-words: enable REG_NEWLINE to help user
color-words: expand docs with precise semantics
color-words: make regex configurable via attributes
sha1_name: tweak @{-N} lookup
sha1_name: support @{-N} syntax in get_sha1()
checkout: implement "-" abbreviation, add docs and tests
t1505: remove debugging cruft
Vitaly \"_Vi\" Shukela (3):
git-svn: add --ignore-paths option for fetching
git-svn: documented --ignore-paths
git-svn: Add test for --ignore-paths parameter
^ permalink raw reply
* 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
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