* Re: Memory issue with fast-import, why track branches?
From: Felipe Contreras @ 2008-12-21 11:23 UTC (permalink / raw)
To: John Chapman; +Cc: git list
In-Reply-To: <1229847042.798.5.camel@therock.nsw.bigpond.net.au>
On Sun, Dec 21, 2008 at 10:10 AM, John Chapman <thestar@fussycoder.id.au> wrote:
> My first response was along the lines of "Why the heck are you storing
> sha1's like that!?", until I realised that you're not storing actual git
> sha1's, but mtn's hashes, which does make sense.
Yes :)
> I'm doing something very similar with my perforce scripts, however I am
> doing a bit more magic instead of making so many branches.
>
> Instead of making branches, I make a tag instead, for each and every
> changeset. Every time I make a new git commit, if I need to do it from
> a tag, I first read the tag and determine the sha1 I should use, and use
> that instead.
Well, simple tags and branches are exactly the same thing: refs. tags
are in 'refs/tags' and branches in 'refs/heads'; 'refs/mtn' are not
really branches.
> Alternatively, you could choose to manage your mapping yourself, and
> write them to a .git/mtg-git-map file.
The advantage of my approach is that the git tools handle all the mtn
sha1's almost as good as git sha1's, I just need to prepend 'mtn/'.
Also, git name-rev finds the mtn revision of a git commit. It' all so
convenient.
The only problem is that fast-import seems to be doing something wrong
with those "branches".
--
Felipe Contreras
^ permalink raw reply
* What's in git.git (Dec 2008, #03; Sun, 21)
From: Junio C Hamano @ 2008-12-21 12:22 UTC (permalink / raw)
To: git
Cc: Johannes Schindelin, Johannes Sixt, Paul Mackerras,
Robin Rosenberg, Boyd Stephen Smith Jr.
The 'maint' branch is at 1.6.0.6, which hopefully will be the last
maintenance release until 1.6.1 final.
Earlier I said I'd like to have 1.6.1 final this weekend, but I'd rather
play safe and tag -rc4 tonight (gee, it is already 04:00am), and leave the
final 1.6.0 as Christmas present to git users.
* Paul has one patch on his gitk branch I have fetched but not merged yet;
waiting for his go-ahead.
* I am undecided whether I should include the "rebase -i -p" patch from
j6t in 1.6.1 and have been waiting for comments from Dscho.
* A documentation patch from Boyd Stephen Smith Jr. to add a reference to
the new HowTo page from git-revert manpage and an additional warning to
git-revert from Robin Rosenberg are still not in yet, but I would like
to have them with updates in 1.6.1 final.
Other than that, the 'master' I am pusing out is pretty much it for
1.6.1.
By the way, 'master' and 'maint' of git.git repository are also mirrored
at git://git.sourceforge.jp/gitroot/git-core/git.git (and they have gitweb
http://git.sourceforge.jp/view?p=git-core/git.git). People who are
following my blog may already have been aware of this, though.
----------------------------------------------------------------
* The 'master' branch has these since the last announcement.
Alexander Gavrilov (3):
git-gui: Fix handling of relative paths in blame.
git-gui: Fix commit encoding handling.
Documentation: Describe git-gui Tools menu configuration options.
Arjen Laarhoven (1):
Enable threaded delta search on Mac OS X/Darwin
Christian Stimming (1):
git-gui: Update German (completed) translation.
Fredrik Skolmli (1):
git-gui: Starting translation for Norwegian
Johannes Schindelin (2):
Get rid of the last remnants of GIT_CONFIG_LOCAL
git-gui: Get rid of the last remnants of GIT_CONFIG_LOCAL
Junio C Hamano (6):
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()
Make sure lockfiles are unlocked when dying on SIGPIPE
send-email: futureproof split_addrs() sub
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 (5):
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/git-show-branch: work around "single quote" typesetting
glitch
Michael J Gruber (1):
test overlapping ignore patterns
Michele Ballabio (1):
git gui: update Italian translation
Miklos Vajna (3):
git-gui: Update Hungarian translation for 0.12
git-daemon documentation: use {tilde}
githooks documentation: add a note about the +x mode
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
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
Shawn O. Pearce (2):
git-gui: Update po template to include 'Mirroring %s' message
git-gui 0.12
YONETANI Tomokazu (1):
git-fast-import possible memory corruption problem
^ permalink raw reply
* What's cooking in git.git (Dec 2008, #03; Sun, 21)
From: Junio C Hamano @ 2008-12-21 12:23 UTC (permalink / raw)
To: git; +Cc: Johannes Sixt, Johannes Schindelin, Simon Schubert
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.
As we have already passed -rc3, things queued in 'next' let alone 'pu' are
unlikely to be merged to 'master' by the end of year unless otherwise
noted.
----------------------------------------------------------------
[New Topics]
* mk/gitweb-feature (Mon Dec 15 22:16:19 2008 -0800) 1 commit
- gitweb: unify boolean feature subroutines
* cb/merge-recursive-fix (Mon Dec 15 02:41:24 2008 -0800) 3 commits
- Merge branch 'cb/maint-merge-recursive-fix' into cb/merge-
recursive-fix
- merge-recursive: do not clobber untracked working tree garbage
- modify/delete conflict resolution overwrites untracked file
* cb/maint-merge-recursive-fix (Sun Dec 14 19:40:09 2008 -0800) 2 commits
- merge-recursive: do not clobber untracked working tree garbage
- modify/delete conflict resolution overwrites untracked file
* js/notes (Sat Dec 20 13:06:03 2008 +0100) 4 commits
- Add an expensive test for git-notes
- Speed up git notes lookup
- Add a script to edit/inspect notes
- Introduce commit notes
* js/rebase-i-p (Mon Dec 15 11:05:31 2008 +0100) 2 commits
- rebase -i -p: Fix --continue after a merge could not be redone
- Show a failure of rebase -p if the merge had a conflict
I am undecided whether I should include these in 1.6.1 and have been
waiting for comments from Dscho.
----------------------------------------------------------------
[Post 1.6.1 items]
* wp/add-p-goto (Thu Dec 4 10:22:40 2008 +0000) 2 commits
+ Add 'g' command to go to a hunk
+ Add subroutine to display one-line summary of hunks
* jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits
- gitweb: cache $parent_commit info in git_blame()
- gitweb: A bit of code cleanup in git_blame()
- gitweb: Move 'lineno' id from link to row element in git_blame
I've briefly looked at the resurrection of Ajaxy blame that comes on top
of this series and it looked promising.
* mv/um-pdf (Wed Dec 10 23:44:50 2008 +0100) 1 commit
- Add support for a pdf version of the user manual
I do not have a new enough combination of dblatex and asciidoc myself but
this may help interested people.
* np/auto-thread (Mon Dec 15 20:44:30 2008 +0100) 3 commits
+ Force t5302 to use a single thread
+ pack-objects: don't use too many threads with few objects
+ autodetect number of CPUs by default when using threads
* 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
* gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
- gitweb: link to patch(es) view in commit(diff) and (short)log view
- gitweb: add patches view
- gitweb: change call pattern for git_commitdiff
- gitweb: add patch view
Updated series.
* lt/reset-merge (Wed Dec 3 18:00:12 2008 -0800) 2 commits
+ Document "git-reset --merge"
+ Add 'merge' mode to 'git reset'
* 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
I am still holding onto this earlier topic to add '/' subcommand to allow
finding a hunk with given text, but I'd rather not merge/rebase it on top
of wp/add-p-goto series myself. Waiting for a reroll.
* cb/mergetool (Fri Dec 12 21:48:41 2008 +0000) 4 commits
- mergetool: Don't keep temporary merge files unless told to
- mergetool: Add prompt to continue after failing to merge a file
- Add -y/--no-prompt option to mergetool
- Fix some tab/space inconsistencies in git-mergetool.sh
Updated series. Waiting for comments from the original author (Ted) and
other interested parties.
----------------------------------------------------------------
[Graduated to "master"]
Nothing cooking was "not so trivial but want to have in final".
----------------------------------------------------------------
[Will merge to "master" soon]
What are you looking for? We are in -rc ;-)
----------------------------------------------------------------
[On Hold]
* kb/am-directory (Fri Aug 29 15:27:50 2008 -0700) 1 commit
. git-am: Pass the --directory option through to git-apply
A reroll of this by Simon Schubert triggered a series to fix a parameter
propagation bug, and another reroll to add "git am --directory=path/"
should be much easier now. I am not likely to use the feature myself, so
it is up to intrested volunteers to carry it 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
* ds/uintmax-config (Mon Nov 3 09:14:28 2008 -0900) 1 commit
- autoconf: Enable threaded delta search when pthreads are supported
Rebased to 'master', that introduced NO_PTHREADS.
* cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
- bisect: add "--no-replace" option to bisect without using replace
refs
- rev-list: make it possible to disable replacing using "--no-
bisect-replace"
- bisect: use "--bisect-replace" options when checking merge bases
- merge-base: add "--bisect-replace" option to use fixed up revs
- commit: add "bisect_replace_all" prototype to "commit.h"
- rev-list: add "--bisect-replace" to list revisions with fixed up
history
- Documentation: add "git bisect replace" documentation
- bisect: add test cases for "git bisect replace"
- bisect: add "git bisect replace" subcommand
I really hate the idea of introducing a potentially much more useful
replacement of the existing graft mechanism and tie it very tightly to
bisect, making it unusable from outside.
(1) I do not think "bisect replace" workflow is a practical and usable
one;
(2) The underlying mechanism to express "this object replaces that other
object" is much easier to work with than what the graft does which is
"the parents of this commit are these", and idea to use the normal
ref to point at them means this can potentially be used for
transferring the graft information across repositories, which the
current graft mechanism cannot do.
(3) Because I like the aspect (2) of this series so much, it deeply
disappoints and troubles me that this is implemented minimally near
the surface, and that it is controlled by the "bisect" Porcelain
alone, by explicitly passing command line arguments.
I think a mechanism like this should be added to replace grafts, but it
should always be enabled for normal revision traversal operation, while
always disabled for object enumeration and transfer operation (iow, fsck,
fetch and push should use the real ancestry information recorded in the
underlying objects, while rev-list, log, etc. should always use the
replaced objects). I have a suspicion that even cat-file could honor it.
* nd/narrow (Sun Nov 30 17:54:38 2008 +0700) 17 commits
- wt-status: show sparse checkout info
- Introduce default sparse patterns (core.defaultsparse)
- checkout: add new options to support sparse checkout
- clone: support sparse checkout with --sparse-checkout option
- unpack_trees(): add support for sparse checkout
- unpack_trees(): keep track of unmerged entries
- Introduce "sparse patterns"
- Merge branch 'master' into nd/narrow
+ t2104: touch portability fix
+ grep: skip files outside sparse checkout area
+ checkout_entry(): CE_NO_CHECKOUT on checked out entries.
+ Prevent diff machinery from examining worktree outside sparse
checkout
+ ls-files: Add tests for --sparse and friends
+ update-index: add --checkout/--no-checkout to update
CE_NO_CHECKOUT bit
+ update-index: refactor mark_valid() in preparation for new options
+ ls-files: add options to support sparse checkout
+ Introduce CE_NO_CHECKOUT bit
Kicked back to 'on hold' until 1.6.1 final by popular demand; will be
dropped from 'next' (see recent discussion on the interaction between the
checkout area and commands such as "grep").
* jc/clone-symref-2 (Sat Nov 29 23:38:21 2008 -0800) 7 commits
- clone: test the new HEAD detection logic
- Merge commit 'HEAD@{2}' into HEAD
- upload-pack: send the HEAD information
- clone: find the current branch more explicitly
- connect.c::read_extra_info(): find where HEAD points at
- connect.c::read_extra_info(): prepare to receive more than server
capabilities
- get_remote_heads(): refactor code to read "server capabilities"
This is no way meant for 1.6.1, let alone next, yet.
* jc/send-pack-tell-me-more (Thu Mar 20 00:44:11 2008 -0700) 1 commit
- "git push": tellme-more protocol extension
This seems to have a deadlock during communication between the peers.
Someone needs to pick up this topic and resolve the deadlock before it can
continue.
* 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
This would be the right thing to do for command line use,
but gitk will be hit due to tcl/tk's limitation, so I am holding
this back for now.
* 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
* jc/clone-symref (Sat Nov 29 23:38:21 2008 -0800) 6 commits
. clone: test the new HEAD detection logic
. Merge sender side of "symbolic-ref" protocol extension
. upload-pack: implement protocol extension "symbolic-ref"
. clone: find the current branch more explicitly
. get_remote_heads(): do not assume that the operation is one-way
. upload-pack.c: refactor receive_needs()
* jk/valgrind (Thu Oct 23 04:30:45 2008 +0000) 2 commits
. valgrind: ignore ldso errors
. add valgrind support in test scripts
* jc/apply (Sun Sep 7 14:36:24 2008 -0700) 1 commit
. WIP
^ permalink raw reply
* Change author in commits
From: Ángel Eduardo @ 2008-12-21 12:27 UTC (permalink / raw)
To: git
Hello.
I've started a repository in a project of mine, but I forgot to change the
commiter name to the nickname and email I'll use in the project along with
my teammates.
So, it's there a way to change them it in the commits I've done?
Thanks a lot in advance!
--
View this message in context: http://n2.nabble.com/Change-author-in-commits-tp1686491p1686491.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Change author in commits
From: David Symonds @ 2008-12-21 13:26 UTC (permalink / raw)
To: Ángel Eduardo; +Cc: git
In-Reply-To: <1229862451693-1686491.post@n2.nabble.com>
On Sun, Dec 21, 2008 at 11:27 PM, Ángel Eduardo <arcnorj@yahoo.es> wrote:
> I've started a repository in a project of mine, but I forgot to change the
> commiter name to the nickname and email I'll use in the project along with
> my teammates.
>
> So, it's there a way to change them it in the commits I've done?
If you haven't published your changes, simply rewrite your history via
git filter-branch; see its manpage for details.
If you *have* published your changes, you can't change committer
details without changing the SHA1 of the commits.
Dave.
^ permalink raw reply
* Re: Retrieving last tag of a working tree
From: Sitaram Chamarty @ 2008-12-21 14:53 UTC (permalink / raw)
To: git
In-Reply-To: <21071491.post@talk.nabble.com>
On 2008-12-18, the_jack <josip@yopmail.com> wrote:
>
> output. This works, but it's not quite reliable. There has to be a better
> way for getting the last tag of current working tree. If I checkout an
git describe?
^ permalink raw reply
* Re: Retrieving last tag of a working tree
From: Thomas Rast @ 2008-12-21 15:28 UTC (permalink / raw)
To: the_jack; +Cc: git
In-Reply-To: <21071491.post@talk.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 828 bytes --]
the_jack wrote:
> Precompiler assigns this string to a variable. At this moment, version.h is
> filled by python script that calls "git-describe --tag HEAD" and parses the
> output. This works, but it's not quite reliable. There has to be a better
> way for getting the last tag of current working tree. If I checkout an
> earlier tagged version (0.70), I would need to automatically get 0.70 inside
> version.h
'git describe' is indeed the tool for this. You have not said in what
way it fails, so here's an educated guess:
Up until 7e425c4 (describe: Make --tags and --all match lightweight
tags more often, 2008-10-13) which will only be in 1.6.1, using --tags
does not match a lightweight tag if there is also an annotated tag
available.
-Thomas
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [PATCH] doc/git-fsck: change the way for getting heads' SHA1s
From: Markus Heidelberg @ 2008-12-21 16:30 UTC (permalink / raw)
To: gitster; +Cc: git
The straightforward way with using 'cat .git/refs/heads/*' doesn't work
with packed refs as well as branches of the form topic/topic1. So let's
use git-for-each-ref for getting the heads' SHA1s in this example.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
Documentation/git-fsck.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-fsck.txt b/Documentation/git-fsck.txt
index d5a7647..287c4fc 100644
--- a/Documentation/git-fsck.txt
+++ b/Documentation/git-fsck.txt
@@ -79,7 +79,8 @@ that aren't readable from any of the specified head nodes.
So for example
- git fsck --unreachable HEAD $(cat .git/refs/heads/*)
+ git fsck --unreachable HEAD \
+ $(git for-each-ref --format="%(objectname)" refs/heads)
will do quite a _lot_ of verification on the tree. There are a few
extra validity tests to be added (make sure that tree objects are
--
1.6.1.rc3.54.g7bef0
^ permalink raw reply related
* Re: Applying patches from a patch set
From: Mark Ryden @ 2008-12-21 18:34 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <slrngkrv22.knd.sitaramc@sitaramc.homelinux.net>
Hello,
Thanks a lot for your answer ! I was not aware of the option using a
newsreader like slrn to access the list via gmane.
The list I want to work with **does** have a gmane interface.
It is :
http://thread.gmane.org/gmane.linux.kernel.wireless.general
However, after I tried:
setenv NNTPSERVER gmane.linux.kernel.wireless.general
and
slrn -f /root/.jnewsrc --create
I got:
slrn 0.9.8.1pl2 [2005-02-17]
Reading startup file /etc/slrn.rc.
Using newsrc file /root/.jnewsrc for server gmane.linux.kernel.wireless.general.
Connecting to host gmane.linux.kernel.wireless.general ...
Failed to resolve gmane.linux.kernel.wireless.general
Run-Time Error
slrn fatal error:
Failed to initialize server.
I assume that this is some silly mistake I had done,.Any ideas?
Rgs,
Mark
On Sun, Dec 21, 2008 at 10:20 AM, Sitaram Chamarty <sitaramc@gmail.com> wrote:
> On 2008-12-20, Mark Ryden <markryde@gmail.com> wrote:
>
>> I am subscribed to some linux kernel subsystem mailing list; in this
>> list there are sometimes patchsets with more than
>> 30-40 patches.
>> I am using gmail web interface client.
>
> solution 1: see if that list is mirrored by gmane and use a
> newsreader like slrn to access the list via gmane
>
> solution 2: enable pop/imap access on your gmail account and
> pull emails from there using whatever command line mail
> client you like (like mutt maybe). Not tested, but should
> work. For some definition of "work" (not sure how gmail's
> "tags" map to imap folders, which might trip you...)
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Applying patches from a patch set
From: Jakub Narebski @ 2008-12-21 18:53 UTC (permalink / raw)
To: Mark Ryden; +Cc: Sitaram Chamarty, git
In-Reply-To: <dac45060812211034w38691627scf2a36ed814353f9@mail.gmail.com>
"Mark Ryden" <markryde@gmail.com> writes:
> However, after I tried:
> setenv NNTPSERVER gmane.linux.kernel.wireless.general
This is not a _NNTP server_; this is _news group_ name.
You should use news.gmane.org for NNTPSERVER.
> I assume that this is some silly mistake I had done,.Any ideas?
setenv NNTPSERVER news.gmane.org
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2008, #03; Sun, 21)
From: Jakub Narebski @ 2008-12-21 19:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Sixt, Johannes Schindelin, Simon Schubert
In-Reply-To: <7vr641pvid.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> ----------------------------------------------------------------
> [New Topics]
>
> * mk/gitweb-feature (Mon Dec 15 22:16:19 2008 -0800) 1 commit
> - gitweb: unify boolean feature subroutines
The last version, I assume? IMHO it is a good change.
> * js/notes (Sat Dec 20 13:06:03 2008 +0100) 4 commits
> - Add an expensive test for git-notes
> - Speed up git notes lookup
> - Add a script to edit/inspect notes
> - Introduce commit notes
Nice to see it resurrected.
> * jn/gitweb-blame (Thu Dec 11 01:33:29 2008 +0100) 3 commits
> - gitweb: cache $parent_commit info in git_blame()
> - gitweb: A bit of code cleanup in git_blame()
> - gitweb: Move 'lineno' id from link to row element in git_blame
>
> I've briefly looked at the resurrection of Ajaxy blame that comes on top
> of this series and it looked promising.
There are a few issues to test and to resolve with Ajaxy blame
(blame_incremental):
* does it work correctly with browsers other than Mozilla 1.17.2
and Konqueror 3.5.3?
* what gives better performance, and better visible performance
on the client side: onreadystatechange or setInterval (and what
interval)?
* is it better to do more work on the server side, and for example
send JSON with ready commits data; it is better to enable autoflush
if sending raw "git blame --incremental" output?
* the 'how long it took to generate page' patch should be decoupled,
improved, and send separately...
> * 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
I think it is not yet finished, but it looks nice.
> * gb/gitweb-patch (Thu Dec 18 08:13:19 2008 +0100) 4 commits
> - gitweb: link to patch(es) view in commit(diff) and (short)log view
> - gitweb: add patches view
> - gitweb: change call pattern for git_commitdiff
> - gitweb: add patch view
>
> Updated series.
I'd have to review resend series, but I think it would get Ack from
me.
> * cc/bisect-replace (Mon Nov 24 22:20:30 2008 +0100) 9 commits
> * nd/narrow (Sun Nov 30 17:54:38 2008 +0700) 17 commits
> * jc/clone-symref-2 (Sat Nov 29 23:38:21 2008 -0800) 7 commits
> * jc/clone-symref (Sat Nov 29 23:38:21 2008 -0800) 6 commits
Those are interesting...
> * jc/apply (Sun Sep 7 14:36:24 2008 -0700) 1 commit
> . WIP
Uh?
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Make git revert warn the user when reverting a merge commit.
From: Boyd Stephen Smith Jr. @ 2008-12-21 19:59 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Junio C Hamano, git
In-Reply-To: <200812211109.36788.robin.rosenberg.lists@dewire.com>
[-- Attachment #1: Type: text/plain, Size: 1431 bytes --]
On Sunday 2008 December 21 04:09:36 Robin Rosenberg wrote:
> söndag 21 december 2008 04:11:13 skrev Boyd Stephen Smith Jr.:
> > On Saturday 2008 December 20 20:37:16 Junio C Hamano wrote:
> > > Robin Rosenberg <robin.rosenberg.lists@dewire.com> writes:
> > > > An alternative, would be "removing changes relative to .."
> > > > (mainline).
> > >
> > > But that is exactly what "This reverts commit X" means, isn't it?
> >
> > When X is a merge commit, the phrase "the reverts commit X" is ambiguous.
> > Did you revert the tree to X^, X^2, or X^8? I'd be fine with "This
> > reverts commit X to X^y", but we definitely need some mention of X^y.
>
> One could consider keeping the contributions from ^1 a special case and not
> mention the parent, making it look like any revert commit. I guess most
> merge reverts are like this in practice.
Then why not have "-m 1" be assumed instead of forcing the user to specify it?
If we force the user to specify that information, shouldn't we hold the code
to the same standard and have it output a message with that information?
I think git should mention the parent to which we reverted whenever there are
multiple parents.
--
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] Make git revert warn the user when reverting a merge commit.
From: Junio C Hamano @ 2008-12-21 20:23 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: Robin Rosenberg, git
In-Reply-To: <200812211359.31991.bss@iguanasuicide.net>
"Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> Then why not have "-m 1" be assumed instead of forcing the user to specify it?
The reason we don't is because until very recently we did not even allow
you to revert a merge relative to any parent. We wanted to avoid
surprising people who are _relying on_ that behaviour to make sure that
they do not revert a merge by accident.
We could certainly do what you suggest to imply "-m 1" when the commit
requested to be reverted happens to be a merge, but we shouldn't be doing
that without thinking things through. It will break people's longstanding
expectations.
^ permalink raw reply
* Re: [PATCH] Make git revert warn the user when reverting a merge commit.
From: Boyd Stephen Smith Jr. @ 2008-12-21 21:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Robin Rosenberg, git
In-Reply-To: <7vwsdtmg5m.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1485 bytes --]
On Sunday 2008 December 21 14:23:17 Junio C Hamano wrote:
> "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> > Then why not have "-m 1" be assumed instead of forcing the user to
> > specify it?
>
> The reason we don't is because until very recently we did not even allow
> you to revert a merge relative to any parent. We wanted to avoid
> surprising people who are _relying on_ that behaviour to make sure that
> they do not revert a merge by accident.
That makes sense.
> We could certainly do what you suggest to imply "-m 1" when the commit
> requested to be reverted happens to be a merge, but we shouldn't be doing
> that without thinking things through. It will break people's longstanding
> expectations.
I wasn't really suggesting that. I was pointing out what I thought was an
inconsistency: making the user specify the parent but not making the commit
message specify the parent.
I still think the parent we are reverting to should be mentioned in the
automatically generated commit message, even if it is the first parent. Even
if it is decided to elide that information for the first parent, I agree
that, at least for now, the "-m" should still be required when reverting a
merge commit.
--
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
* [PATCHv2] Have manpage reference new documentation on reverting merges.
From: Boyd Stephen Smith Jr. @ 2008-12-21 21:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Nanako Shiraishi
In-Reply-To: <7vtz8ytft0.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Boyd Stephen Smith Jr <bss@iguanasuicide.net>
---
On Saturday 2008 December 20 20:36:43 Junio C Hamano wrote:
> "Boyd Stephen Smith Jr." <bss@iguanasuicide.net> writes:
> > + Reverting a merge commit does not completely "undo" the effect of the
> > + merge and it may make future merges more difficult. For more details,
> > + please read Documentation/howto/revert-a-faulty-merge.txt.
>
> I think these new lines need to be dedented, and the previous blank line
> should be turned into a line with a single '+'.
Fixed, I wasn't familiar with asciidoc.
> I'd also suggest removing "does not ... merge and it" from the above
> sentence to avoid confusing readers, because people who read only the
> above and do not read the howto document may get a wrong impression that
> the resulting tree may have some changes that came from the merge even
> after the revert, which is not the case.
>
> An alternative is to give a complete but brief explanation. Perhaps like
> this:
I took the alternative approach.
Documentation/git-revert.txt | 7 +++++++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-revert.txt b/Documentation/git-revert.txt
index caa0729..daa77a9 100644
--- a/Documentation/git-revert.txt
+++ b/Documentation/git-revert.txt
@@ -44,6 +44,13 @@ 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 to git that you will never want the tree
+changes brought in by the merge but never alters the history changes caused by
+the merge. The history allows git to remember you rejected the tree changes
+and, as a result, later merges will only bring in changes introduced by commits
+that are not ancestors of the revert commit. This may or may not be what you
+want. See the 'revert-a-faulty-merge' HOWTO for more details.
--no-edit::
With this option, 'git-revert' will not start the commit
--
1.5.6
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
^ permalink raw reply related
* Dynamically adjusting packed_git_window_size
From: R. Tyler Ballance @ 2008-12-21 21:37 UTC (permalink / raw)
To: git
Internally we are using a custom build of Git, and one of the patches
that I apply to newer builds of Git is one to adjust the
DEFAULT_PACKED_GIT_WINDOW_SIZE in git-compat-util.h so Git won't trample
all over our ulimit values on the 64-bit dev machines.
To do away with this, I've got these two (really one) set of patches to
adjust the packed_git_window_size when setup_git_env() is called to a
fraction of the "addressspace" limit (RLIMIT_AS). If the user's
environment defines "ulimit -v" as "unlimited", this code will not take
effect.
It's worth noting that this doesn't force Git to respect these limits,
I'm still tracking down an issue hiding in get_revision() where I'm
experiencing mmap(2) failures executing a `git log` command with
restrictive ulimit settings (Linus, since you were so "pleased" with my
last epic gdb fail, here's today's):
(gdb)
open_packed_git (p=0x71f2e0) at sha1_file.c:733
733 /* We leave these file descriptors open with sliding mmap;
(gdb)
735 */
(gdb)
741 return error("cannot set FD_CLOEXEC");
(gdb)
746 if (hdr.hdr_signature != htonl(PACK_SIGNATURE))
(gdb)
Recursive internal problem.
[1] 17381 abort GIT_PAGER= gdb git
tyler@starfruit:~/source/git/main>
Oi vei.
Cheers,
-R. Tyler Ballance
^ permalink raw reply
* [PATCH] Add support for changing packed_git_window_size at process start time
From: R. Tyler Ballance @ 2008-12-21 21:37 UTC (permalink / raw)
To: git; +Cc: R. Tyler Ballance
In-Reply-To: <1229895454-19498-1-git-send-email-tyler@slide.com>
"Works" insofar that it will alter the packed_git_window_size variable in environment.c
when the environment is set up. It /doesn't/ work when commands like git-diff(1) and git-log(1)
call get_revision() which seems to disregard the setting if the packed_window_size is set to something
low (i.e. ulimit -v 32768)
Signed-off-by: R. Tyler Ballance <tyler@slide.com>
---
environment.c | 10 ++++++++++
git-compat-util.h | 4 ++++
2 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/environment.c b/environment.c
index e278bce..a3b6bab 100644
--- a/environment.c
+++ b/environment.c
@@ -7,6 +7,9 @@
* even if you might want to know where the git directory etc
* are.
*/
+#include <sys/time.h>
+#include <sys/resource.h>
+
#include "cache.h"
char git_default_email[MAX_GITNAME];
@@ -75,6 +78,13 @@ static void setup_git_env(void)
git_graft_file = getenv(GRAFT_ENVIRONMENT);
if (!git_graft_file)
git_graft_file = git_pathdup("info/grafts");
+
+ if (DYNAMIC_WINDOW_SIZE) {
+ struct rlimit *as = malloc(sizeof(struct rlimit));
+ if ( (getrlimit(RLIMIT_AS, as) == 0) && ((int)(as->rlim_cur) > 0) )
+ packed_git_window_size = (unsigned int)(as->rlim_cur * DYNAMIC_WINDOW_SIZE_PERCENTAGE);
+ free(as);
+ }
}
int is_bare_repository(void)
diff --git a/git-compat-util.h b/git-compat-util.h
index e20b1e8..9603ca6 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -182,6 +182,8 @@ extern int git_munmap(void *start, size_t length);
/* This value must be multiple of (pagesize * 2) */
#define DEFAULT_PACKED_GIT_WINDOW_SIZE (1 * 1024 * 1024)
+#define DYNAMIC_WINDOW_SIZE 0
+#define DYNAMIC_WINDOW_SIZE_PERCENTAGE 0
#else /* NO_MMAP */
@@ -192,6 +194,8 @@ extern int git_munmap(void *start, size_t length);
(sizeof(void*) >= 8 \
? 1 * 1024 * 1024 * 1024 \
: 32 * 1024 * 1024)
+#define DYNAMIC_WINDOW_SIZE 1
+#define DYNAMIC_WINDOW_SIZE_PERCENTAGE 0.85
#endif /* NO_MMAP */
--
^ permalink raw reply related
* [PATCH] Style changes per suggestions from Junio in #git
From: R. Tyler Ballance @ 2008-12-21 21:37 UTC (permalink / raw)
To: git; +Cc: R. Tyler Ballance
In-Reply-To: <1229895454-19498-2-git-send-email-tyler@slide.com>
Moving includes into git-compat-util.h, move away from malloc(2)
Signed-off-by: R. Tyler Ballance <tyler@slide.com>
---
environment.c | 9 +++------
git-compat-util.h | 2 ++
2 files changed, 5 insertions(+), 6 deletions(-)
diff --git a/environment.c b/environment.c
index a3b6bab..aa36360 100644
--- a/environment.c
+++ b/environment.c
@@ -7,8 +7,6 @@
* even if you might want to know where the git directory etc
* are.
*/
-#include <sys/time.h>
-#include <sys/resource.h>
#include "cache.h"
@@ -80,10 +78,9 @@ static void setup_git_env(void)
git_graft_file = git_pathdup("info/grafts");
if (DYNAMIC_WINDOW_SIZE) {
- struct rlimit *as = malloc(sizeof(struct rlimit));
- if ( (getrlimit(RLIMIT_AS, as) == 0) && ((int)(as->rlim_cur) > 0) )
- packed_git_window_size = (unsigned int)(as->rlim_cur * DYNAMIC_WINDOW_SIZE_PERCENTAGE);
- free(as);
+ struct rlimit as;
+ if (getrlimit(RLIMIT_AS, &as) == 0 && (int)as.rlim_cur > 0)
+ packed_git_window_size = (unsigned int)(as.rlim_cur * DYNAMIC_WINDOW_SIZE_PERCENTAGE);
}
}
diff --git a/git-compat-util.h b/git-compat-util.h
index 9603ca6..dad2dc8 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -188,6 +188,8 @@ extern int git_munmap(void *start, size_t length);
#else /* NO_MMAP */
#include <sys/mman.h>
+#include <sys/time.h>
+#include <sys/resource.h>
/* This value must be multiple of (pagesize * 2) */
#define DEFAULT_PACKED_GIT_WINDOW_SIZE \
--
^ permalink raw reply related
* Re: [PATCHv2] Have manpage reference new documentation on reverting merges.
From: Junio C Hamano @ 2008-12-21 21:54 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git, Nanako Shiraishi
In-Reply-To: <E1LEVxk-0001jS-Cc@rei.iguanasuicide.net>
"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.
Documentation/git-revert.txt | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git c/Documentation/git-revert.txt w/Documentation/git-revert.txt
index caa0729..b87f2b3 100644
--- c/Documentation/git-revert.txt
+++ w/Documentation/git-revert.txt
@@ -44,6 +44,15 @@ OPTIONS
option specifies the parent number (starting from 1) of
the mainline and allows revert to reverse the change
relative to the specified parent.
++
+By reverting a merge, you are telling git that you never want the changes
+the merge made to your tree. If the branch the reverted merge merged is
+updated later, and you merge from it again, git remembers this, and only
+brings in the changes on the branch that are made after the previously
+reverted merge. This may or may not be what you want.
++
+See 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
^ permalink raw reply related
* Re: [PATCH] Style changes per suggestions from Junio in #git
From: Matthieu Moy @ 2008-12-21 22:03 UTC (permalink / raw)
To: R. Tyler Ballance; +Cc: git
In-Reply-To: <1229895454-19498-3-git-send-email-tyler@slide.com>
"R. Tyler Ballance" <tyler@slide.com> writes:
> Moving includes into git-compat-util.h, move away from malloc(2)
Usually, those cleanup patches are merged with the actual patch before
inclusion. This helps review (i.e. let reviewers not have to say or
think "you shouldn't do that - oh, ok, you're actually not doing it"),
and avoids having bad commits at all in Junio's repository.
--
Matthieu
^ permalink raw reply
* Re: [PATCH 1/2] fast-import: add special mode; copy from parent.
From: Shawn O. Pearce @ 2008-12-21 22:07 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1229825502-963-1-git-send-email-felipe.contreras@gmail.com>
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?
> + } else {
> + p = get_mode(p, &mode);
> + if (!p)
> + die("Corrupt mode: %s", command_buf.buf);
> + switch (mode) {
> + case S_IFREG | 0644:
> + case S_IFREG | 0755:
> + case S_IFLNK:
> + case S_IFGITLINK:
> + case 0644:
> + case 0755:
> + /* ok */
> + break;
> + default:
> + die("Corrupt mode: %s", command_buf.buf);
> + }
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] fast-import: add special '-' blob reference to use the previous one.
From: Shawn O. Pearce @ 2008-12-21 22:11 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git
In-Reply-To: <1229825502-963-2-git-send-email-felipe.contreras@gmail.com>
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...
> @@ -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.
--
Shawn.
^ permalink raw reply
* [PATCH] git-status -v: colored diff when color.ui is set
From: Markus Heidelberg @ 2008-12-21 22:14 UTC (permalink / raw)
To: gitster; +Cc: git
When using "git status -v", the diff output wasn't colored, even though
color.ui was set. Only when setting color.diff it worked.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
builtin-commit.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index e88b78f..ac88dc2 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -866,6 +866,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)
if (wt_status_use_color == -1)
wt_status_use_color = git_use_color_default;
+ if (diff_use_color_default == -1)
+ diff_use_color_default = git_use_color_default;
+
argc = parse_and_validate_options(argc, argv, builtin_status_usage, prefix);
index_file = prepare_index(argc, argv, prefix);
--
1.6.1.rc3.62.g7c0a2
^ permalink raw reply related
* [PATCH] git-commit: colored status when color.ui is set
From: Markus Heidelberg @ 2008-12-21 22:15 UTC (permalink / raw)
To: gitster; +Cc: git
When using "git commit" and there was nothing to commit (the editor
wasn't launched), the status output wasn't colored, even though color.ui
was set. Only when setting color.status it worked.
Signed-off-by: Markus Heidelberg <markus.heidelberg@web.de>
---
builtin-commit.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index ac88dc2..7cf227a 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -948,6 +948,9 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
git_config(git_commit_config, NULL);
+ if (wt_status_use_color == -1)
+ wt_status_use_color = git_use_color_default;
+
argc = parse_and_validate_options(argc, argv, builtin_commit_usage, prefix);
index_file = prepare_index(argc, argv, prefix);
--
1.6.1.rc3.62.g7c0a2
^ permalink raw reply related
* Re: Memory issue with fast-import, why track branches?
From: Shawn O. Pearce @ 2008-12-21 22:17 UTC (permalink / raw)
To: Felipe Contreras; +Cc: git list
In-Reply-To: <94a0d4530812202154l26dfe0dfm49397c63dbfdfdf9@mail.gmail.com>
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.
--
Shawn.
^ 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