* What's cooking in git.git (Feb 2010, #02; Sun, 07)
From: Junio C Hamano @ 2010-02-08 2:19 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 integration branches, but I am
still holding onto them.
There shouldn't be anything exciting to see here right now. Please test
"master" branch to avoid giving regressions to end users; we are at
1.7.0-rc2 and I am hoping that we can release the 1.7.0 on the 10th.
--------------------------------------------------
[New Topics]
* sp/maint-push-sideband (2010-02-05) 6 commits
- receive-pack: Send hook output over side band #2
- receive-pack: Wrap status reports inside side-band-64k
- receive-pack: Refactor how capabilities are shown to the client
- send-pack: demultiplex a sideband stream with status data
- run-command: support custom fd-set in async
- run-command: Allow stderr to be a caller supplied pipe
(this branch is used by sp/push-sideband.)
Based on 1.6.5 maintenance track
* sp/push-sideband (2010-02-05) 0 commits
(this branch uses sp/maint-push-sideband.)
And my conflict resolution in #ifdef WINDOWS codepath (meaning: untested,
please check).
* ac/cvsimport-revision-mapping (2010-02-06) 1 commit
- cvsimport: new -R option: generate .git/cvs-revisions mapping
* jc/maint-1.6.3-imap-send-bool-config-fix (2010-02-06) 1 commit
- imap-send: fix longstanding configuration parser bug
* js/rebase-origin-x (2010-02-05) 1 commit
- [RFC w/o test and incomplete] rebase: add -x option to record original commit name
* rs/git-dir-cleanup (2010-02-06) 2 commits
(merged to 'next' on 2010-02-06 at ef8ab9b)
+ Resurrect "git grep --no-index"
+ setenv(GIT_DIR) clean-up
* jc/typo (2010-02-03) 1 commit
- Typofixes outside documentation area
* jk/grep-double-dash (2010-02-06) 1 commit
(merged to 'next' on 2010-02-07 at 2ac040d)
+ accept "git grep -- pattern"
--------------------------------------------------
[Cooking]
* jn/maint-makedepend (2010-01-26) 5 commits
- Makefile: drop dependency on $(wildcard */*.h)
- Makefile: clean up http-walker.o dependency rules
- Makefile: remove wt-status.h from LIB_H
- Makefile: make sure test helpers are rebuilt when headers change
- Makefile: add missing header file dependencies
(this branch is used by jn/makedepend and jn/master-makedepend.)
These look sensible clean-up that could go to maint later.
* jn/master-makedepend (2010-01-26) 0 commits
(this branch uses jn/maint-makedepend; is used by jn/makedepend.)
This is to help merging the clean-up to "master".
* jn/makedepend (2010-01-31) 9 commits
- Makefile: always remove .depend directories on 'make clean'
- Makefile: tuck away generated makefile fragments in .depend
- Teach Makefile to check header dependencies
- Makefile: list standalone program object files in PROGRAM_OBJS
- Makefile: lazily compute header dependencies
- Makefile: list generated object files in OBJECTS
- Makefile: disable default implicit rules
- Makefile: rearrange dependency rules
- Makefile: transport.o depends on branch.h now
(this branch uses jn/maint-makedepend and jn/master-makedepend.)
And this is to build on top. I don't want to touch build infrastructure
during the pre-release freeze too much to avoid the last minute hassles
that is only discovered when I try to cut RPMs; hence this will stay out
of 'master' until 1.7.0 ships.
* jc/checkout-detached (2010-01-29) 1 commit
- Reword "detached HEAD" notification
* jc/maint-fix-test-perm (2010-01-30) 2 commits
- lib-patch-mode.sh: Fix permission
- t6000lib: Fix permission
* jh/gitweb-caching (2010-01-30) 1 commit
- gitweb: Add an option to force version match
* jn/makefile-script-lib (2010-01-31) 1 commit
- Do not install shell libraries executable
* mv/request-pull-modernize (2010-01-29) 1 commit
- request-pull: avoid mentioning that the start point is a single commit
* cc/reset-keep (2010-01-19) 5 commits
- reset: disallow using --keep when there are unmerged entries
- reset: disallow "reset --keep" outside a work tree
- Documentation: reset: describe new "--keep" option
- reset: add test cases for "--keep" option
- reset: add option "--keep" to "git reset"
* jh/notes (2010-01-27) 23 commits
- builtin-notes: Add "add" subcommand for appending to note objects
- builtin-notes: Add "list" subcommand for listing note objects
- Documentation: Generalize git-notes docs to 'objects' instead of 'commits'
- builtin-notes: Add "prune" subcommand for removing notes for missing objects
- Notes API: prune_notes(): Prune notes that belong to non-existing objects
- t3305: Verify that removing notes triggers automatic fanout consolidation
- builtin-notes: Add "remove" subcommand for removing existing notes
- Teach builtin-notes to remove empty notes
- Teach notes code to properly preserve non-notes in the notes tree
- t3305: Verify that adding many notes with git-notes triggers increased fanout
- t3301: Verify successful annotation of non-commits
- Builtin-ify git-notes
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: write_notes_tree(): Store the notes tree in the database
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: remove_note(): Remove note objects from the notes tree structure
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Add tests for checking correct handling of $GIT_NOTES_REF and core.notesRef
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Cosmetic fixes to notes.c
* jc/grep-author-all-match-implicit (2010-01-17) 1 commit
- "log --author=me --grep=it" should find intersection, not union
^ permalink raw reply
* [PATCH] filter-branch: Fix error message for --prune-empty --commit-filter
From: Jacob Helwig @ 2010-02-08 2:36 UTC (permalink / raw)
To: git; +Cc: Jacob Helwig
Running filter-branch with --prune-empty and --commit-filter, no longer
incorrectly reports that you had tried to run '--filter-commit' in
combination with '--prune-empty'.
---
This problem with filter-branch's error message was originally brought up by
hipe in the IRC channel.
git-filter-branch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index e95845c..88fb0f0 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -207,7 +207,7 @@ t,)
,*)
;;
*)
- die "Cannot set --prune-empty and --filter-commit at the same time"
+ die "Cannot set --prune-empty and --commit-filter at the same time"
esac
case "$force" in
--
1.7.0.rc1.50.g8424
^ permalink raw reply related
* [PATCH] filter-branch: Fix error message for --prune-empty --commit-filter
From: Jacob Helwig @ 2010-02-08 2:38 UTC (permalink / raw)
To: git; +Cc: Jacob Helwig
In-Reply-To: <1265596587-9949-1-git-send-email-jacob.helwig@gmail.com>
Running filter-branch with --prune-empty and --commit-filter, no longer
incorrectly reports that you had tried to run '--filter-commit' in
combination with '--prune-empty'.
Signed-off-by: Jacob Helwig <jacob.helwig@gmail.com>
---
Sorry for the re-send. Forgot the SOB...
git-filter-branch.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index e95845c..88fb0f0 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -207,7 +207,7 @@ t,)
,*)
;;
*)
- die "Cannot set --prune-empty and --filter-commit at the same time"
+ die "Cannot set --prune-empty and --commit-filter at the same time"
esac
case "$force" in
--
1.7.0.rc1.50.g8424
^ permalink raw reply related
* Re: Implement --password option for git svn perl script
From: Laszlo Papp @ 2010-02-08 6:29 UTC (permalink / raw)
To: Steve Diver; +Cc: Eric Wong, Frank Li, Tay Ray Chuan, git
In-Reply-To: <4B6CA33B.8050200@googlemail.com>
Any workflow in this task ? :((
Best Regards,
Laszlo Papp
^ permalink raw reply
* Re: [PATCH] Add a test for a problem in "rebase --whitespace=fix"
From: Björn Gustavsson @ 2010-02-08 7:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vbpg060qx.fsf@alter.siamese.dyndns.org>
2010/2/8 Junio C Hamano <gitster@pobox.com>:
> You cannot go by the line numbers on the "@@ -l,k +m,n @@" header line you
> see in the second patch you received. On that line, only k and n are
> reliable numbers (the must match the patch text). l and m are unreliable;
> being able to apply even if the text you have at hand does not exactly
> match l and m is the whole point of transmitting the change in the patch
> format. The _only_ information you have usable at that point is that
> there are _at least_ 3 blank lines before the addition, and perhaps the
> fact that the hunk ends without post context lines. The latter tells you
> that it must apply at the end, but still doesn't tell you how many blanks
> you need to add back at EOF before applying the patch.
I agree. The information is not enough if you apply one patch
at the time.
But my usage case that my test tries to demonstrate is different:
I already have a number of commits in my repository (received
either by pulling or applying a whole series of patches at once).
I then do, for example:
git rebase --whitespace=fix HEAD~4
to clean up the existing commits.
That rebase uses "git apply" internally seems like an implementation
detail that I as a user of rebase don't care about. I just expect it
to work.
I see at least two possible ways to implement that:
1. Have "git rebase" give "git apply" a special option so that it
will apply patches beyond the end of file (and trusting the
line numbers in the chunks).
2. Having "git rebase" remember the number of blanks line that
was removed in each previous file in previous fixed commits
and add them back just before invoking "git apply".
It is possible that it is too much work to implement it to be
worthwhile (especially solution 2), but I do think it is possible.
If you don't agree, fair enough. In that case I will hold on
to the test case and only re-submit it if I can also include
a fix.
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
^ permalink raw reply
* Re: What's cooking in git.git (Feb 2010, #02; Sun, 07)
From: Johannes Sixt @ 2010-02-08 8:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhbpswju3.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> * sp/maint-push-sideband (2010-02-05) 6 commits
> - receive-pack: Send hook output over side band #2
> - receive-pack: Wrap status reports inside side-band-64k
> - receive-pack: Refactor how capabilities are shown to the client
> - send-pack: demultiplex a sideband stream with status data
> - run-command: support custom fd-set in async
> - run-command: Allow stderr to be a caller supplied pipe
> (this branch is used by sp/push-sideband.)
>
> Based on 1.6.5 maintenance track
>
> * sp/push-sideband (2010-02-05) 0 commits
> (this branch uses sp/maint-push-sideband.)
>
> And my conflict resolution in #ifdef WINDOWS codepath (meaning: untested,
> please check).
The resolution is correct. I'm using this branch in my private build on
Windows; so far it works as expected.
-- Hannes
^ permalink raw reply
* Re: [PATCH] git gui spanish translation.
From: Peter Krefting @ 2010-02-08 8:44 UTC (permalink / raw)
To: Alejandro Riveira Fernández; +Cc: Wincent Colaiuta, git
In-Reply-To: <1265229474.23299.15.camel@varda>
Hi!
Some general translation comments (I don't particularly know about Spanish).
Alejandro Riveira Fernández:
> I'm open to sugestions. the same problem with "commit" (either verb or
> noun) tracking branch, push ( propagar is ok? ) etc...
For my translation, I used the translated versions of "check-in" (as in to
check-in to a flight) for "commit", for "branch" I used the same word as for
a branch on a tree, and for "push", I translated as "send". If you can't
find a direct translation, finding a simpler synonym in English is usually a
good way to go.
Also do check if there are translated GUIs for other version control
software, and try to be consistent with them.
>> I'm not sure what the standard translation of EOF is, but seeing as it
>> stands for "End Of File" it wouldn't surprise me if there is something
>> similar in Spanish like "FDA" (Fin De Archivo) or something similar...?
>
> I think people use the EOF just like they use NULL or cd-rom or many other
> neologism
If there is doubt, it is usually better to spell it out, possibly keeping
the original abbreviation (such as writing "EOF (end of file)", with "end of
file" translated).
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [PATCH] gitweb: Die if there are parsing errors in config file
From: Jakub Narebski @ 2010-02-08 8:48 UTC (permalink / raw)
To: J.H.; +Cc: git
In-Reply-To: <4B6E9BBB.4000904@eaglescrag.net>
On Sun, 7 Feb 2010, J.H. wrote:
> I'd sign-off that, I've probably run into it a couple of times myself.
>
> - John 'Warthog9' Hawley
I think you meant ACK, not sign-off...
> On 02/07/2010 01:40 AM, Jakub Narebski wrote:
> > Otherwise the errors can propagate, and show in damnest places, and
> > you would spend your time chasing ghosts instead of debugging real
> > problem (yes, it is from personal experience).
> >
> > This follows (parts of) advice in `perldoc -f do` documentation.
> >
> > Signed-off-by: Jakub Narebski <jnareb@gmail.com>
> > ---
> > This is fallout from my work on [split] "Gitweb output caching" series.
> > Before I used `die $@ if $@;' in t/t9503/test_cache_interface.pl, tests
> > failed for no discernable reason...
> >
> > So I think the same should be done for the gitweb config file.
[...]
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH] filter-branch: Fix error message for --prune-empty --commit-filter
From: Michael J Gruber @ 2010-02-08 10:10 UTC (permalink / raw)
To: Jacob Helwig; +Cc: git
In-Reply-To: <1265596681-10561-1-git-send-email-jacob.helwig@gmail.com>
Jacob Helwig venit, vidit, dixit 08.02.2010 03:38:
> Running filter-branch with --prune-empty and --commit-filter, no longer
> incorrectly reports that you had tried to run '--filter-commit' in
> combination with '--prune-empty'.
In order to understand this sentence, I had to look twice at the patch text.
What's going on is that that typo was there from the beginning, right?
(Induced from the name of a script variable, I see.) How about:
Running filter-branch with --prune-empty and --commit-filter reports
"Cannot set --prune-empty and --filter-commit at the same time".
Change it to use the correct name "--commit-filter" of the option.
> Signed-off-by: Jacob Helwig <jacob.helwig@gmail.com>
> ---
>
> Sorry for the re-send. Forgot the SOB...
>
> git-filter-branch.sh | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> index e95845c..88fb0f0 100755
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -207,7 +207,7 @@ t,)
> ,*)
> ;;
> *)
> - die "Cannot set --prune-empty and --filter-commit at the same time"
> + die "Cannot set --prune-empty and --commit-filter at the same time"
> esac
>
> case "$force" in
^ permalink raw reply
* Re: notes metadata?
From: Giuseppe Bilotta @ 2010-02-08 10:32 UTC (permalink / raw)
To: Johan Herland; +Cc: Git List, Junio C Hamano, Jon Seymour, Jeff King
In-Reply-To: <201002072357.24021.johan@herland.net>
On Sun, Feb 7, 2010 at 11:57 PM, Johan Herland <johan@herland.net> wrote:
> On Sunday 07 February 2010, Giuseppe Bilotta wrote:
>> Hello all,
>>
>> ok, this may sound a little odd especially with the 'notes vs
>> metadata' thread going on, but I was wondering: do we store _any_ kind
>> of metadata _about_ the notes themselves? If I'm reading the code
>> correctly, we have neither author nor date information about the notes
>> themselves, so we don't know who added them or when. Is it too late to
>> suggest that this kind of metadata be added to notes? Making them
>> full-blown commit-style objects is probalby overengineered and wrong
>> under many points of view (not to mention probably incompatible with
>> current storage), but maybe we can set up a convention that notes
>> SHOULD be in pseudo-mbox format? This would mean that when a note is
>> created, the template starts with a 'From ' line including the user's
>> name & email and note creation date; when editing, the note is again
>> augmented with the new author name email and date. Of course the users
>> are then free do expunge the From lines if they don't want it (just
>> commenting it would be enough, of course). How does the idea sound?
>
> NAK
>
> Notes are stored in a notes tree that is changed by making commits on the
> notes ref (see commit_notes() in builtin-notes.c in 'pu'). The commits on
> the notes ref are regular commits with the usual commit metadata (author,
> date, etc.), so if you're interested in who/when a given note was written,
> you can simply point 'git (gui) blame' at the notes tree.
Yup, I was totally overseeing the obvious thing about the notes
commit, and up until this morning I thought that settled the issue.
However, this morning I read Junio's posts about the issue of merging notes
http://permalink.gmane.org/gmane.comp.version-control.git/139252 and
thought that this might be a possible solution.
Junio's root issue is basically that you can only have one note per
commit per namespace, and that normally notes from different
developers grow from different root commits and are thus unmergeable.
I see two possible solutions to this:
* one is to allow more than one note per commit per namespace, which
moves a little towards the 'note as a tree' idea, but with severe
restrictions (the tree would be flat and each blob in it would be a
note)
* the other is to keep the notes as single files, but give them a
little bit of structure to make merging easier: my mbox-style idea
would of course only be an idea, but in general by keeping the notes
'sectioned', merging could be reduced to concatenation most of the
times. The mbox approach also has the benefit that you'd have more
information about the single section, so that you could for example
keep them sorted etc.
Just brainstorming here, so feel free to tear down this idea too 8-)
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: [msysGit] upload-pack timing issue on windows?
From: Erik Faye-Lund @ 2010-02-08 11:18 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, Git Mailing List
In-Reply-To: <201002062318.59180.j6t@kdbg.org>
On Sat, Feb 6, 2010 at 11:18 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Samstag, 6. Februar 2010, Erik Faye-Lund wrote:
>> However, I have tracked down a bit of what goes on in the client.
>> There's a call to read_in_full, called from pack-write.c, line 246
>> that fails in the failure-case, but not in the success-case. This is
>> where the client expects "pack\tSHA-1" or "keep\tSHA-1". There "fatal:
>> early EOF"-messages seems to originate from index-pack.c, line 197.
>> This is the first line of code in parse_pack_header(), it's also
>> AFAICT the first call-site for any read(0, <...>) (though fill()).
>
> This looks like upload-pack died without sending enough to fill a pack header.
>
> Try merging this branch:
>
> git://repo.or.cz/git/mingw/j6t.git async-in-thread
>
> It contains your changes to start_async plus a refinement of die() when it is
> called from the async procedure (it passes t5530, for example). It is also
> converted to pthreads, and therefore also works on Unix. The new
> implementation of start_async is more careful about the file handles, though
> not so much on Windows.
>
> If there's no change for you, then you could look into implementing
> fcntl(F_GETFD/SETFD, FD_CLOEXEC), which are currently ignored, on top of this
> branch, using Get/SetHandleInformation().
>
Thanks a lot. I tried merging it, but the issue still pops up. I also
tried to implement fcntl(F_GETFD/SETFD, FD_CLOEXEC), still no dice.
I'm not entirely sure if I did it correctly, though.
> Background: On Unix, we need FD_CLOEXEC so that the fds that are meant for the
> async thread do not remain open in an unrelated child process; on Windows, we
> are just lucky and can get away without FD_CLOEXEC because our pipe()s are
> non-inheritable and async only work with pipes. But once we pass other fds to
> the async procedure, we need a working FD_CLOEXEC. Perhaps something in this
> direction is related to your problem.
>
> You could push out your current state of the git-daemon and a recipe to
> reproduce the problem. Perhaps I find some time to look into it.
>
Sure. You can find my current version at
git://repo.or.cz/git/kusma.git work/daemon-fcntl
This branch includes your branch and my fcntl-attempt, as well as an
almost-fixed-up version of the last daemon-win32 series I sent out
(still lacking critical sections when saving process ids, as you
suggested).
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Unix root dir as a work tree
From: João Carlos Mendes Luís @ 2010-02-08 12:17 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <fcaeb9bf1002071803o343bed87u2e1df2ef77db607f@mail.gmail.com>
Nguyen Thai Ngoc Duy wrote:
> 2010/2/8 João Carlos Mendes Luís <jonny@jonny.eng.br>:
>
>> Hi,
>>
>> Sorry if this is a FAQ, but I could not find any reference.
>>
>> I have been using CVS as a version control system for unix configuration
>> files for a long time. I know it has some limitations, and I know git also
>> has its. But I expect to work around all of them using etckeeper.
>>
>> The problem is that etckeeper was created with /etc only in mind, and I
>> want to keep track of important files everywhere, not only below /etc (think
>> /opt, /usr/local). The obvious solution appear to create the repository at
>> the system root, and not at /etc, but it did not work. I think, because of
>> a bug.
>>
>> Now, I have a patch that appears to work, but since I am a beginner to git,
>> I don't know if this is the best way to implement it, if it has any side
>> effects, or even if it works for other operating systems (probably they
>> don't even have the bug). Would any git wizard care to look at it, check if
>> it is ok, and maybe commit in HEAD or give me any advice against my patch?
>>
>
> How did you set GIT_DIR and GIT_WORK_TREE? What command failed?
>
Did not set any env special variable. I expect git to find those
automatically.
Any command which needs a work tree fails. git-add, git-status, etc.
It thinks that its root is "/.git", instead of "/". Easy to repeat.
cd /
git init
git add etc/motd # this works
cd etc
git add resolv.conf # this does not work without my patch
^ permalink raw reply
* [stgit] Documentation build error in proposed branch
From: Gustav Hållberg @ 2010-02-08 13:00 UTC (permalink / raw)
To: Catalin Marinas; +Cc: git
As of recently, I cannot compile documentation in
git://repo.or.cz/stgit.git proposed:
lux:~/devel/stgit$ git ls-files -o | xargs rm
lux:~/devel/stgit$ git rev-parse HEAD
c7506039d0299c093140857b7a617ec6bcdbfc13
lux:~/devel/stgit$ make all doc
:
cd Documentation && make all
make[1]: Entering directory `/home/gustav/devel/stgit/Documentation'
rm -f doc.dep+ doc.dep
perl ./build-docdep.perl >doc.dep+
mv doc.dep+ doc.dep
make[1]: Leaving directory `/home/gustav/devel/stgit/Documentation'
make[1]: Entering directory `/home/gustav/devel/stgit/Documentation'
../stg-build --cmd-list > command-list.txt
Traceback (most recent call last):
File "../stg-build", line 41, in <module>
main()
File "../stg-build", line 31, in main
commands.get_commands(allow_cached = False), sys.stdout)
File "/home/gustav/devel/stgit/stgit/commands/__init__.py", line 89,
in asciidoc_command_list
for kind, cmds in _command_list(commands):
File "/home/gustav/devel/stgit/stgit/commands/__init__.py", line 72,
in _command_list
yield kind, sorted(kinds[kind].iteritems())
KeyError: 'Alias commands'
make[1]: *** [command-list.txt] Error 1
make[1]: Leaving directory `/home/gustav/devel/stgit/Documentation'
make: *** [doc] Error 2
- Gustav
^ permalink raw reply
* Re: A generalization of git notes from blobs to trees - git metadata?
From: Steven E. Harris @ 2010-02-08 2:03 UTC (permalink / raw)
To: git
In-Reply-To: <7v8wb4aj4m.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> It's like "keeping track of /etc" (or "your home directory"). It is a
> misguided thing to do because you are throwing in records of the
> states of totally unrelated things into a single history.
I've recently tried doing this again with Git, so this comment piqued my
interest. (That is, tracking changes to my various configuration files.)
I agree that browsing the history in toto is jarring, though the history
of a particular file may be telling.
Is there an alternative you'd recommend?
--
Steven E. Harris
^ permalink raw reply
* [PATCH] Support working directory located at root
From: Nguyễn Thái Ngọc Duy @ 2010-02-08 14:53 UTC (permalink / raw)
To: git, João Carlos Mendes Luís, Junio C Hamano
Cc: Nguyễn Thái Ngọc Duy
Git should work regardless where the working directory is located,
even at root. This patch fixes two places where it assumes working
directory always have parent directory.
In setup_git_directory_gently(), when Git goes up to root and finds
.git there, it happily sets worktree to "".
In prefix_path(), loosen the outside repo check a little bit. Usually
when a path XXX is inside worktree /foo, it must be either "/foo", or
"/foo/...". When worktree is simply "/", we can safely ignore the
check: we have a slash at the beginning already.
Not related to worktree, but also set gitdir correctly if a bare repo
is placed (insanely?) at root.
Thanks João Carlos Mendes Luís for pointing out this problem.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
Tell me if this patch is rejected, I'll send another one that makes
setup_git_* die() if worktree/gitdir is to be set empty. I don't think we
expect gitdir or worktree to be empty anywhere.
setup.c | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/setup.c b/setup.c
index b38cbee..0fcd2fd 100644
--- a/setup.c
+++ b/setup.c
@@ -25,7 +25,7 @@ const char *prefix_path(const char *prefix, int len, const char *path)
len = strlen(work_tree);
total = strlen(sanitized) + 1;
if (strncmp(sanitized, work_tree, len) ||
- (sanitized[len] != '\0' && sanitized[len] != '/')) {
+ (len > 1 && sanitized[len] != '\0' && sanitized[len] != '/')) {
error_out:
die("'%s' is outside repository", orig);
}
@@ -403,7 +403,7 @@ const char *setup_git_directory_gently(int *nongit_ok)
if (!work_tree_env)
inside_work_tree = 0;
if (offset != len) {
- cwd[offset] = '\0';
+ cwd[offset ? offset : 1] = '\0';
set_git_dir(cwd);
} else
set_git_dir(".");
@@ -427,6 +427,8 @@ const char *setup_git_directory_gently(int *nongit_ok)
inside_git_dir = 0;
if (!work_tree_env)
inside_work_tree = 1;
+ if (offset == 0) /* reached root, set worktree to '/' */
+ offset = 1;
git_work_tree_cfg = xstrndup(cwd, offset);
if (check_repository_format_gently(nongit_ok))
return NULL;
--
1.7.0.rc0.54.gd33ef
^ permalink raw reply related
* Re: [ANNOUNCE] Git 1.7.0.rc2
From: Erik Faye-Lund @ 2010-02-08 15:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljf4wjuo.fsf@alter.siamese.dyndns.org>
On Mon, Feb 8, 2010 at 3:18 AM, Junio C Hamano <gitster@pobox.com> wrote:
> A release candidate Git 1.7.0.rc2 is available at the usual places
> for testing:
>
Is there a reason why the repo.or.cz mirror isn't updated?
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Gmail and unwanted line-wrapping
From: Erik Faye-Lund @ 2010-02-08 15:20 UTC (permalink / raw)
To: Jay Soffian; +Cc: David Aguilar, Sverre Rabbelier, Aaron Crane, git
In-Reply-To: <76718491002061650ge299426s22de5e00b26af108@mail.gmail.com>
On Sun, Feb 7, 2010 at 1:50 AM, Jay Soffian <jaysoffian@gmail.com> wrote:
>> I've added it to the Git Wiki:
>> http://git.wiki.kernel.org/index.php/GitTips#Using_gmail_to_send_your_patches
>
> If you're on MacOS X and have MacPorts installed, then install both
> the curl and msmtp packages, then use an .msmtprc as follows:
>
There's also an article on the msysGit-wiki about using msmtp to send patches:
http://code.google.com/p/msysgit/wiki/UsingSendEmail
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* [PATCH] Revert "pack-objects: fix pack generation when using pack_size_limit"
From: Nicolas Pitre @ 2010-02-08 15:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
This reverts most of commit a2430dde8ceaaaabf05937438249397b883ca77a.
That commit made the situation better for repositories with relatively
small number of objects. However with many objects and a small pack size
limit, the time required to complete the repack tends towards O(n^2),
or even much worse with long delta chains.
Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
---
Fixing this doesn't appear to be as trivial as I initially thought.
Although I do have some ideas, they're not appropriate so late in
the -rc period.
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index dcfe62a..e1d3adf 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -445,13 +445,9 @@ static int write_one(struct sha1file *f,
if (e->idx.offset || e->preferred_base)
return -1;
- /*
- * If we are deltified, attempt to write out base object first.
- * If that fails due to the pack size limit then the current
- * object might still possibly fit undeltified within that limit.
- */
- if (e->delta)
- write_one(f, e->delta, offset);
+ /* if we are deltified, write out base object first. */
+ if (e->delta && !write_one(f, e->delta, offset))
+ return 0;
e->idx.offset = *offset;
size = write_object(f, e, *offset);
@@ -505,9 +501,11 @@ static void write_pack_file(void)
sha1write(f, &hdr, sizeof(hdr));
offset = sizeof(hdr);
nr_written = 0;
- for (i = 0; i < nr_objects; i++)
- if (write_one(f, objects + i, &offset) == 1)
- display_progress(progress_state, written);
+ for (; i < nr_objects; i++) {
+ if (!write_one(f, objects + i, &offset))
+ break;
+ display_progress(progress_state, written);
+ }
/*
* Did we write the wrong # entries in the header?
@@ -582,7 +580,7 @@ static void write_pack_file(void)
written_list[j]->offset = (off_t)-1;
}
nr_remaining -= nr_written;
- } while (nr_remaining);
+ } while (nr_remaining && i < nr_objects);
free(written_list);
stop_progress(&progress_state);
diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
index 1058d98..7649b81 100755
--- a/t/t5300-pack-object.sh
+++ b/t/t5300-pack-object.sh
@@ -389,7 +389,7 @@ test_expect_success 'verify resulting packs' '
test_expect_success 'tolerate packsizelimit smaller than biggest object' '
git config pack.packSizeLimit 1 &&
packname_11=$(git pack-objects test-11 <obj-list) &&
- test 3 = $(ls test-11-*.pack | wc -l)
+ test 5 = $(ls test-11-*.pack | wc -l)
'
test_expect_success 'verify resulting packs' '
^ permalink raw reply related
* Re: [PATCH] git-gui: check whether systems nice command works or disable it
From: Shawn O. Pearce @ 2010-02-08 15:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Heiko Voigt, git
In-Reply-To: <7vhbps4lwr.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> > diff --git a/git-gui/git-gui.sh b/git-gui/git-gui.sh
> > index 1fb3cbf..eec2dc9 100755
> > --- a/git-gui/git-gui.sh
> > +++ b/git-gui/git-gui.sh
> > @@ -388,6 +388,9 @@ proc _lappend_nice {cmd_var} {
> >
> > if {![info exists _nice]} {
> > set _nice [_which nice]
> > + if {[catch {exec $_nice git version}]} {
> > + set _nice {}
> > + }
>
> Where does the output from this "git version" invocation go?
By default Tcl exec returns stdout's contents. So in this case,
its passed to catch, which discards it, because catch returns true
if exec crashed, false if it ran without error.
Patch looks fine to me as-is.
--
Shawn.
^ permalink raw reply
* [RFC PATCH] ls-tree: dump full tree if it was named as such
From: Thomas Rast @ 2010-02-08 15:59 UTC (permalink / raw)
To: git
git-ls-tree acted weird when it was called in a subdirectory but with
a tree (not commit) argument. For example,
# in git.git
mkdir valgrind
cd valgrind
git ls-tree HEAD:t
would list the contents of HEAD:t/valgrind even though the user is
looking at /valgrind.
Fix this by not doing the implied-prefix logic when the specified
object is a tree (as in 'HEAD:t' or 'HEAD:'), as opposed to a commit
('HEAD').
To this end, we first introduce a variant of parse_tree_indirect()
that also reports back how many levels it had to traverse. Then we
teach cmd_ls_tree() to ignore the prefix if that depth was 0.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
---
RFC because I'm breaking an existing test, though I can't see why
anyone would rely on such weird behaviour.
builtin-ls-tree.c | 9 +++++++--
t/t3101-ls-tree-dirname.sh | 19 ++++++++++++++++++-
tree.c | 11 ++++++++++-
tree.h | 1 +
4 files changed, 36 insertions(+), 4 deletions(-)
diff --git a/builtin-ls-tree.c b/builtin-ls-tree.c
index 4484185..04c6a65 100644
--- a/builtin-ls-tree.c
+++ b/builtin-ls-tree.c
@@ -121,6 +121,7 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
unsigned char sha1[20];
struct tree *tree;
int full_tree = 0;
+ int depth;
const struct option ls_tree_options[] = {
OPT_BIT('d', NULL, &ls_options, "only show trees",
LS_TREE_ONLY),
@@ -166,10 +167,14 @@ int cmd_ls_tree(int argc, const char **argv, const char *prefix)
if (get_sha1(argv[0], sha1))
die("Not a valid object name %s", argv[0]);
- pathspec = get_pathspec(prefix, argv + 1);
- tree = parse_tree_indirect(sha1);
+ tree = parse_tree_indirect_depth(sha1, &depth);
if (!tree)
die("not a tree object");
+ if (!depth) {
+ ls_tree_prefix = prefix = NULL;
+ chomp_prefix = 0;
+ }
+ pathspec = get_pathspec(prefix, argv + 1);
read_tree_recursive(tree, "", 0, 0, pathspec, show_tree, NULL);
return 0;
diff --git a/t/t3101-ls-tree-dirname.sh b/t/t3101-ls-tree-dirname.sh
index 06654c6..a3cd80a 100755
--- a/t/t3101-ls-tree-dirname.sh
+++ b/t/t3101-ls-tree-dirname.sh
@@ -37,6 +37,7 @@ test_expect_success \
find *.txt path* \( -type f -o -type l \) -print |
xargs git update-index --add &&
tree=`git write-tree` &&
+ commit=`echo dummy | git commit-tree $tree` &&
echo $tree'
test_output () {
@@ -142,7 +143,7 @@ test_expect_success 'ls-tree filter is leading path match' '
test_expect_success 'ls-tree --full-name' '
(
cd path0 &&
- git ls-tree --full-name $tree a
+ git ls-tree --full-name $commit a
) >current &&
cat >expected <<\EOF &&
040000 tree X path0/a
@@ -224,4 +225,20 @@ EOF
test_output
'
+test_expect_success 'ls-tree $tree does not restrict to pwd' '
+ (
+ cd path0 &&
+ git ls-tree $tree
+ ) >current &&
+ cat >expected <<\EOF &&
+100644 blob X 1.txt
+100644 blob X 2.txt
+040000 tree X path0
+040000 tree X path1
+040000 tree X path2
+040000 tree X path3
+EOF
+ test_output
+'
+
test_done
diff --git a/tree.c b/tree.c
index 5ab90af..e9e8481 100644
--- a/tree.c
+++ b/tree.c
@@ -266,9 +266,11 @@ int parse_tree(struct tree *item)
return parse_tree_buffer(item, buffer, size);
}
-struct tree *parse_tree_indirect(const unsigned char *sha1)
+struct tree *parse_tree_indirect_depth(const unsigned char *sha1,
+ int *depth)
{
struct object *obj = parse_object(sha1);
+ *depth = 0;
do {
if (!obj)
return NULL;
@@ -282,5 +284,12 @@ struct tree *parse_tree_indirect(const unsigned char *sha1)
return NULL;
if (!obj->parsed)
parse_object(obj->sha1);
+ (*depth)++;
} while (1);
}
+
+struct tree *parse_tree_indirect(const unsigned char *sha1)
+{
+ int unused;
+ return parse_tree_indirect_depth(sha1, &unused);
+}
diff --git a/tree.h b/tree.h
index 2ff01a4..97f171c 100644
--- a/tree.h
+++ b/tree.h
@@ -18,6 +18,7 @@ struct tree {
int parse_tree(struct tree *tree);
/* Parses and returns the tree in the given ent, chasing tags and commits. */
+struct tree *parse_tree_indirect_depth(const unsigned char *sha1, int *depth);
struct tree *parse_tree_indirect(const unsigned char *sha1);
#define READ_TREE_RECURSIVE 1
--
1.7.0.rc2.178.g109e1
^ permalink raw reply related
* Re: [PATCH] git gui spanish translation.
From: Alejandro Riveira Fernández @ 2010-02-08 16:00 UTC (permalink / raw)
To: Peter Krefting; +Cc: Wincent Colaiuta, git
In-Reply-To: <alpine.DEB.2.00.1002080941040.28237@ds9.cixit.se>
[-- Attachment #1: Type: text/plain, Size: 553 bytes --]
El lun, 08-02-2010 a las 09:44 +0100, Peter Krefting escribió:
> Hi!
>
> Some general translation comments (I don't particularly know about Spanish).
>
Thank you I will try to keep the suggestions in mind. in future
revisions :)
--
The idea that Bill Gates has appeared like a knight in shining armour to
lead all customers out of a mire of technological chaos neatly ignores
the fact that it was he who, by peddling second-rate technology, led
them into it in the first place.
Douglas Adams
[-- Attachment #2: Esto es una parte de mensaje firmado digitalmente --]
[-- Type: application/pgp-signature, Size: 835 bytes --]
^ permalink raw reply
* Re: git gc / git repack not removing unused objects?
From: Jon Nelson @ 2010-02-08 17:12 UTC (permalink / raw)
Cc: git
In-Reply-To: <alpine.LFD.2.00.1002071937000.1681@xanadu.home>
On Sun, Feb 7, 2010 at 8:11 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
> On Sun, 7 Feb 2010, Jon Nelson wrote:
>> On Sat, Feb 6, 2010 at 7:16 PM, Nicolas Pitre <nico@fluxnic.net> wrote:
>> >On Sat, 6 Feb 2010, Jon Nelson wrote:
>> >> packsizelimit = 256m
>> >
>> > Why are you using this?
>>
>> I didn't want my pack files to be too huge. I've bumped that up to 2G.
>>
>> >> pack.packsizelimit=2M
>>
>> My ~/.gitconfig normally uses 2M for easy rsyncing. In this repo I
>> thought the value was overridden by the project's config (which was
>> specifying 256m and now specifies 2048m).
>
> Why do you synchronize with rsync? Why not a simple 'git fetch' which
> is likely to be much faster in any case?
Often I need to sync the entire config, and am frequently rsyncing
(although not in this case) rsyncing repos made with git-svn. I've had
trouble using git clone on these repos, as I really want the duplicate
repo to use the svn upstream and not the git repo it was cloned from.
..
> You previously had 2408195 packed objects and after the repack this is
> 2674504. The difference is 266309, which incidentally is the number of
> objects 'git repack' counted.
>
> If that 266309 object count is stable between repack attempts (and it
> should), then something is failing to clean up the old packs. If I
> remember right, you were playing with modifications to git-repack.sh
> lately? It is well possible that you broke it.
Indeedly do I did.
The (now expected) results:
turnip:/mnt/backups.git # du -sh ; echo ; git count-objects -v ; echo
; git repack -ad ; echo ; git count-objects -v ; echo ; du -sh
204G .
count: 0
size: 0
in-pack: 2939744
packs: 694
size-pack: 213284091
prune-packable: 0
garbage: 0
Counting objects: 266309, done.
Compressing objects: 100% (205176/205176), done.
Writing objects: 100% (266309/266309), done.
Total 266309 (delta 47781), reused 230413 (delta 47770)
count: 0
size: 0
in-pack: 266309
packs: 11
size-pack: 21590451
prune-packable: 0
garbage: 0
21G .
turnip:/mnt/backups.git #
and of course now everything is nice and (reasonably) fast.
Thanks for the help, and pointing out that the problem was .. me.
--
Jon
^ permalink raw reply
* error: packfile size changed
From: Erik Faye-Lund @ 2010-02-08 17:17 UTC (permalink / raw)
To: Git Mailing List, msysGit
I was just about to push out a branch to a remote repo, and got a
quite worrying error message:
$ git push kusma work/git-svn-autocrlf
Counting objects: 3475, done.
Delta compression using up to 8 threads.
Compressing objects: 100% (1132/1132), done.
Writing objects: 100% (2503/2503), 933.82 KiB, done.
Total 2503 (delta 1909), reused 1927 (delta 1362)
error: packfile
./objects/pack/pack-165dacbd05ac0aa1634eb220f2b6d3be05b2bd3c.pack size
changed
error: packfile
./objects/pack/pack-165dacbd05ac0aa1634eb220f2b6d3be05b2bd3c.pack
cannot be accessed
error: unpack should have generated
83d114b6781e06b422a2062854dd3dede3795079, but I can't find it!
To ssh://kusma@repo.or.cz/srv/git/git/kusma.git
! [remote rejected] work/git-svn-autocrlf -> work/git-svn-autocrlf (bad pack)
error: failed to push some refs to
'ssh://kusma@repo.or.cz/srv/git/git/kusma.git'
The push was attempted with git v1.7.0.rc2. It fails with v1.6.6.1
(and msysgit's devel-branch, 1.6.5.1.1375.gc836) as well.
I tried running "git fsck --full", but it didn't report anything apart
from dangling objects.
Any ideas, anyone?
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH] Documentation/SubmittingPatches: fix Gmail workaround advice
From: Junio C Hamano @ 2010-02-08 17:42 UTC (permalink / raw)
To: Jonathan Nieder
Cc: Aaron Crane, Tom Preston-Werner, git, Sverre Rabbelier,
Jacob Helwig, David Aguilar, Jay Soffian, John Tapsell
In-Reply-To: <20100207221645.GA2862@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Scratch that: it looks like it once did.
>
> http://thread.gmane.org/gmane.comp.version-control.git/99721/focus=99775
>
> Tom, any clues? Are you still able to avoid spurious line wrapping in
> gmail?
The example Tom cites $gmane/99759 does not have long enough lines to be
linewrapped, so perhaps the problem was there from day one but was not
noticed.
I just tried it myself (I don't even regularly use Gmail), following the
procedure outlined in SubmittingPatches. It does look like Gmail web
interface mangles longer lines in the message.
^ permalink raw reply
* Re: [PATCH] Support working directory located at root
From: Junio C Hamano @ 2010-02-08 17:43 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy
Cc: git, João Carlos Mendes Luís
In-Reply-To: <1265640810-6361-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> Git should work regardless where the working directory is located,
> even at root. This patch fixes two places where it assumes working
> directory always have parent directory.
>
> In setup_git_directory_gently(), when Git goes up to root and finds
> .git there, it happily sets worktree to "".
If you mean "instead set it to "/" and things will work much better."
I agree with the reasoning (not suggesting to reword---just trying to
make sure I understood what you meant).
> In prefix_path(), loosen the outside repo check a little bit. Usually
> when a path XXX is inside worktree /foo, it must be either "/foo", or
> "/foo/...". When worktree is simply "/", we can safely ignore the
> check: we have a slash at the beginning already.
The logic for the "are we inside?" check above sounds correct. When
work_tree is at root, have "/" in it, and len inside the "if orig is
absolute" block is 1, so memmove() strips out the leading '/' and makes
the result relative to the root level. Am I reading the code right?
> Not related to worktree, but also set gitdir correctly if a bare repo
> is placed (insanely?) at root.
Yuck, but looks correct.
^ 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