* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Shawn O. Pearce @ 2008-07-21 3:22 UTC (permalink / raw)
To: Jakub Narebski
Cc: git, Sam Vilain, Joshua Roys, Sverre Rabbelier, Sverre Rabbelier,
David Symonds, Lea Wiemann, John Hawley, Marek Zawirski,
Miklos Vajna, Johannes Schindelin, Stephan Beyer,
Christian Couder, Daniel Barkalow
In-Reply-To: <200807210029.31543.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> wrote:
> 1. GitTorrent
>
> Student: Joshua Roys
> Mentor: Sam Vilain
...
> There is some activity there... but no summary of it anywhere I could
> find. (I wonder if this was the project Johannes and Shawn were talking
> about of "going dark" in GSoC 2008 podcast 018...)
Yes, this is the project I referred to in the podcast about going dark.
> 4. Eclipse plugin push support
>
> Student: Marek Zawirski
> Mentor: Shawn O. Pearce
>
> [...] Marek and I simply decided that protocol support was more
> important than really tight network transport at this point in time.
Correction, the "I" in "Marek and I" isn't Jakub, its Shawn. This
is just an editing mistake due to copy and paste from earlier thread.
Apparently my original paragraph here was already a nice summary of
the projects decisions thus far.
I'm likely to be offline much of the rest of this week (I got lucky
and found an open access point just now) but Marek is actively
working on user interface for push support, and I think if he finds
the time is considering adding delta generation. That will be a
lot more time consuming as I think he needs to go back to original
academic papers to learn an LCS algorithm and then implement that.
Copyright and licenses around libxdiff and delta-diff.c won't allow
us to directly port the diff code to Java and our BSD license. No,
I don't want to start a BSD-GPL license war. Our decision to go
BSD in jgit may be a thorn in our side in areas such as this, but it
is probably better for our long-term goals of working more directly
with the Eclipse Foundation and perhaps also the NetBeans folks.
> SUMMARY:
> ========
> From those projects, "git-merge builtin" did what it was meant to do
> already. "Eclipse plugin push support" and "git-statistics" did
> minimum what it was meant to do already, and it looks like it would be
> finished before August 11. "Gitweb caching" is after first round of
> patches, "git-sequencer" looks like already done; I don't know what is
> the state of "GitTorrent" project.
>
> Please correct any mistakes in this summary / writeup. Thanks in
> advance.
I think this is a pretty good summary. I want to go through the
mid-term evaluations and summarize those for the mailing list but
I have not had a chance to do that yet. With network being spotty
for the rest of this week it probably won't happen until the weekend.
I think the quick summary is our students and our mentors think
their projects are going well. Jakub's summary above suggests
very much the same thing. Its hard to claim a GSoC project isn't
meeting its goals when the code is already merged, or is at least
under active patch review. ;-)
--
Shawn.
^ permalink raw reply
* making a branch with just one file and keeping its whole history
From: ncrfgs @ 2008-07-21 4:18 UTC (permalink / raw)
To: git; +Cc: madewokherd, ncrfgs
[-- Attachment #1: Type: text/plain, Size: 3664 bytes --]
Hi,
I have a working local repository and I'd like to make a branch with just one
file (let's say path2/filename2) and to keep its whole history.
At first I've considered creating a fresh new repo and redirecting
`git-log -p --follow path2/filename2` output to some other git command.
When later I've discussed the topic on #git@irc.freenode.net I've been pointed to
git-filter-branch.
Searching for more info about git-filter-branch on the web I've found a couple of
examples that might be close to what I'd like to accomplish:
from http://loupgaroublond.blogspot.com/2007/12/how-to-split-repository-in-git.html
$ git filter-branch --tree-filter 'rm -rf $put_the_files_you_want_to_remove_here' HEAD
$ git reset --hard
$ git gc --aggressive
$ git prune
from http://log.emmanuelebassi.net/archives/2007/09/when-the-levee-breaks/
$ git clone --no-hardlinks /tmp/gtk2-perl Gtk2-SourceView.git
$ git filter-branch --subdirectory-filter Gtk2-SourceView HEAD
$ git reset --hard
$ git gc --aggressive
$ git prune
I've also gone through man pages and I've found something interesting:
$ git-filter-branch --tree-filter 'rm $filename' HEAD
or, as far as I understood, equivalent and faster:
$ git-filter-branch --index-filter 'git-update-index --remove $filename' HEAD
Now, what I'd like to do is complementary to the above example; the difference is
that I don't want to remove just one file and its traces from history; rather I'd
like to have a new repo which includes just that file and its history.
So I would need something like the following command:
$ git-filter-branch --tree-filter 'keep(?) $filename' HEAD
I think one possible solution would be:
$ git-filter-branch --tree-filter 'find ! -type d | grep -v "^./path2/filename2$" | while read FILE; do rm $FILE; done' HEAD
Problems come, I think, if the content you want to keep track of, is placed in a
file that has been renamed. For example, let's say that the content you want to
keep track of was in:
path1/filename1 from commit 1 to commit 1000
path2/filename1 from commit 1001 to commit 2000
path2/filename2 from commit 2001 to commit 3000
In this case I think one possible solution would be:
$ git-filter-branch --tree-filter 'find ! -type d | grep -v "^./path1/filename1$" | grep -v "^./path2/filename1$" | grep -v "^./path2/filename2$" | while read FILE; do rm $FILE; done' HEAD
But what happens if in the meanwhile a new file has been created with one of the
names we used for the content we want to keep track of? Let's say, following the
previous case, that path2/filename1 has been renamed to path2/filename2 with
commit 2001, and that with commit 2500 a new file has been created with name
path1/filename1.
Considering both the solutions I've found on the web and the ones I've been
suggested on #git@irc.freenode.net I've found four/five possible path to follow:
a) git log | another git command (later I've been told that git log --follows leaves out the initial revision)
b) git clone; git filter-branch
c) create a new repo with your one file and make an initial commit
then do: (cd repo-with-one-file; git ls-tree)|(cd repo-where-you-want-the-new-branch; git-mktree)
d) git commit-tree that-tree < file-with-commit-message
then: git checkout -b branchname that-commit
e) git-am or git apply processing the output of git-log or another
similar command
I hope you guys can help me to make some light on this issue.
Thanks in advance. :D
P.S.
Sorry for my bad english but I'm not a native english speaker, I hope that what
I've written made enough sense to you. :)
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Junio C Hamano @ 2008-07-21 4:24 UTC (permalink / raw)
To: sverre; +Cc: Junio C Hamano, Miklos Vajna, git
In-Reply-To: <bd6139dc0807201619g6c268488kd6b45109a246638d@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> On Mon, Jul 21, 2008 at 1:16 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>> On Sun, Jul 20, 2008 at 11:05 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> I could make "What's cooking" not a follow-up to the previous issue, or
>>>> perhaps add "(volume 1.6.0, issue 28)" at the end of the Subject.
>>>
>>> The downside of this is that it'll be less easy to see the difference
>>> with the previous version.
>>
>> My vague recollection is that it was Pasky who complained long time ago
>> when "What's in" was not a follow-up to its previous round, which led me
>> to switch my workflow to send them in the current form. You cannot
>> satisfy certain people no matter what you do.
>
> Add an interdiff at the bottom of the mail? You can't satisfy
> everybody no matter what you do, but you can come quite far, it
> usually means you have to do a lot of work to do so though.
Do you think I have an infinite bandwidth? I don't.
^ permalink raw reply
* Re: [PATCH] Add a notice to the doc of git-ls-tree.
From: Junio C Hamano @ 2008-07-21 4:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: Steve Frécinaux, git
In-Reply-To: <20080721002248.GJ10151@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Sun, Jul 20, 2008 at 05:14:16PM -0700, Junio C Hamano wrote:
>> I never thought you would think "showing relative to tree-root" is even an
>> option.
>
> I assume you mean "not filtering relative to tree-root"?
Sorry, I may have been unclear. I meant "showing relative to tree-root,
unlike showing relative to cwd like we have done forever".
Changing the behaviour would affect usage like this:
$ cd some/where
$ git ls-files
$ git ls-tree --name-only -r HEAD^
cf. http://thread.gmane.org/gmane.comp.version-control.git/13028/focus=13080
^ permalink raw reply
* Re: [PATCHv2] git-mv: Keep moved index entries inact
From: Junio C Hamano @ 2008-07-21 4:36 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <20080721002508.26773.92277.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> This patch introduces rename_index_entry_at() into the index toolkit,
> which will rename an entry while removing any entries the new entry
> might render duplicate. This is then used in git mv instead
> of all the file queues, resulting in a major simplification
> of the code and an inevitable change in git mv -n output format.
>
> A new test has been added to the testsuite to reflect this change.
> Also, based on suggestion by Junio about desired symlink behaviour
> of git mv, I have added two tests for that; however, I do not have
> need or desire to spend time fixing this, so they are expected
> to fail for now until someone gets around to fixing that.
I haven't looked into the builtin-mv changes to see how involved that fix
would be yet (and I do not use "mv" and this is somewhat lower priority
for me myself), but I did look at changes to read-cache.c. I've queued a
fixed up version in 'pu' for now but I am hoping that we can see some
comments from more competent people on the patch and move the review
result to 'next' shortly.
This may be a change in semantics, but after thinking about it a bit more,
I think this can even go into maintenance series. IOW, it is really a
fix. Nobody sane should have been relying on the old behaviour that new
contents of dirty paths are staged in the index sometimes, which was
simply just crazy.
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Steffen Prohaska @ 2008-07-21 5:07 UTC (permalink / raw)
To: Junio C Hamano
Cc: Johannes Schindelin, Fredrik Tolf, Keith Packard, git,
Edward Z. Yang
In-Reply-To: <7vhcak5o6n.fsf@gitster.siamese.dyndns.org>
On Jul 20, 2008, at 9:51 PM, Junio C Hamano wrote:
> I do not know if "plink" is used widely enough to be special cased,
> but if
> so, I think we would better have an explicit support for it.
Our installer on Windows explicitly supports plink as an alternative to
OpenSSH. Putty has a GUI for managing your ssh keys (Pageant). You
need
to type your password only once to unlock a key and make it available to
all connections that you start afterwards.
I think it should be special cased. I use plink myself.
Steffen
^ permalink raw reply
* Re: [PATCH v2 1/4] builtin-add.c: restructure the code for maintainability
From: Junio C Hamano @ 2008-07-21 5:22 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807201529150.3305@eeepc-johanness>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This comment left me scratching my head. While I do see a breakage when
> reading the index first, I had the impression that it should not.
The directory traversal that originates from git-ls-files (not the
"show-index" mode which the command originally was about, but the "show
others" part of the feature that came much later) were primarily designed
for collecting paths that do not appear in the active_cache[]. Very early
version of git-add was about adding untracked paths (and update-index was
to stage changes to tracked files), and did have the fill_directory()
after we have read the index for this exact reason.
That changed late 2006 when Nico allowed git-add to stage already tracked
files as well. We collect the paths in the work tree that match given
pathspec, and for the directory traverser to do that job, you would need
an empty index.
Side note: 366bfcb (make 'git add' a first class user friendly
interface to the index, 2006-12-04) is something to marvel at. It
describes the change with its documentation update fully, changes
the semantics in a drastic way, with so little change.
Documentation/git-add.txt | 53 ++++++++++++-----------
Documentation/tutorial.txt | 46 ++++++++++++++++++---
builtin-add.c | 6 +-
wt-status.c | 2 +-
4 files changed, 72 insertions(+), 35 deletions(-)
Perhaps we can add a bit to the dir_struct we give to the traverser to
tell it to ignore the index even if we have already read one. That would
be a much cleaner API enhancement than reading the index and setting aside
while calling read_directory() which feels like a you know what I would
call it.
Perhaps you can lose that comment like this.
builtin-add.c | 12 ++++--------
dir.c | 12 +++++++++---
dir.h | 1 +
3 files changed, 14 insertions(+), 11 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index fc3f96e..c6185c3 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -58,6 +58,7 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec,
/* Set up the default git porcelain excludes */
memset(dir, 0, sizeof(*dir));
+ dir->ignore_index = 1;
if (!ignored_too) {
dir->collect_ignored = 1;
setup_standard_excludes(dir);
@@ -280,17 +281,12 @@ int cmd_add(int argc, const char **argv, const char *prefix)
}
pathspec = get_pathspec(prefix, argv);
- /*
- * If we are adding new files, we need to scan the working
- * tree to find the ones that match pathspecs; this needs
- * to be done before we read the index.
- */
- if (add_new_files)
- fill_directory(&dir, pathspec, ignored_too);
-
if (read_cache() < 0)
die("index file corrupt");
+ if (add_new_files)
+ fill_directory(&dir, pathspec, ignored_too);
+
if (refresh_only) {
refresh(verbose, pathspec);
goto finish;
diff --git a/dir.c b/dir.c
index 29d1d5b..7447485 100644
--- a/dir.c
+++ b/dir.c
@@ -389,7 +389,7 @@ static struct dir_entry *dir_entry_new(const char *pathname, int len)
struct dir_entry *dir_add_name(struct dir_struct *dir, const char *pathname, int len)
{
- if (cache_name_exists(pathname, len, ignore_case))
+ if (!dir->ignore_index && cache_name_exists(pathname, len, ignore_case))
return NULL;
ALLOC_GROW(dir->entries, dir->nr+1, dir->alloc);
@@ -483,8 +483,14 @@ static enum directory_treatment treat_directory(struct dir_struct *dir,
const char *dirname, int len,
const struct path_simplify *simplify)
{
- /* The "len-1" is to strip the final '/' */
- switch (directory_exists_in_index(dirname, len-1)) {
+ enum exist_status in_index;
+
+ if (dir->ignore_index)
+ in_index = index_nonexistent;
+ else
+ /* The "len-1" is to strip the final '/' */
+ in_index = directory_exists_in_index(dirname, len-1);
+ switch (in_index) {
case index_directory:
return recurse_into_directory;
diff --git a/dir.h b/dir.h
index 2df15de..4ef1c99 100644
--- a/dir.h
+++ b/dir.h
@@ -38,6 +38,7 @@ struct dir_struct {
show_other_directories:1,
hide_empty_directories:1,
no_gitlinks:1,
+ ignore_index:1,
collect_ignored:1;
struct dir_entry **entries;
struct dir_entry **ignored;
^ permalink raw reply related
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Andreas Ericsson @ 2008-07-21 5:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vsku44679.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
>> So here is what I thought about: What about if everyone (except Junio,
>> of course) would change the subject _and_ remove the In-Reply-To: header
>> when replying to those mails?
>>
>> If those large threads just annoys a few people and most people are
>> happy with the current situation then sorry for the noise.
>
> I could make "What's cooking" not a follow-up to the previous issue, or
> perhaps add "(volume 1.6.0, issue 28)" at the end of the Subject.
>
I would very much prefer that (both of them, really). Thunderbird's
threading is not so advanced as mutt's, so I can't break threads so easily.
The most annoying part is that the timebased auto-delete from thunderbird
means I get a new thread spawning in the middle of an old partially deleted
one. It can be very confusing.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* What's cooking in git.git (2008-07 issue #9)
From: Junio C Hamano @ 2008-07-21 5:31 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 topics list the commits in reverse chronological order. The topics
meant to be merged to the maintenance series have "maint-" in their names.
Due to increased activity level from people including GSoC students, I
expect 'next' to stay somewhat more active than previous rounds during the
1.6.0-rc cycle. The request for people who usually follow 'next' is the
same as usual, though. After -rc1 is tagged, please run 'master' for your
daily git use instead, in order to make sure 'master' does what it claims
to do without regression.
Tentative schedule, my wishful thinking:
- 1.6.0-rc0 (Jul 20)
- 1.6.0-rc1 (Jul 23)
- 1.6.0-rc2 (Jul 30)
- 1.6.0-rc3 (Aug 6)
- 1.6.0 (Aug 10)
----------------------------------------------------------------
[New Topics]
* pb/sane-mv (Mon Jul 21 02:25:56 2008 +0200) 2 commits
- git-mv: Keep moved index entries inact
- git-mv: Remove dead code branch
Running "git mv A B" when you have local changes to A automatically staged
it while moving it to B, which was a longstanding nonsense. This attempts
to fix it. Pasky has other plans to build on a more solidified foundation
to enhance the command to work with submodules better on top of this.
----------------------------------------------------------------
[Graduated to "master"]
* ns/am-abort (Wed Jul 16 19:39:10 2008 +0900) 1 commit
+ git am --abort
This one is for Ted; builds on top of the recent "am and rebase leaves
ORIG_HEAD just like reset, merge and pull does" rather nicely.
* jc/rerere-auto-more (Wed Jul 16 20:25:18 2008 -0700) 1 commit
+ rerere.autoupdate: change the message when autoupdate is in effect
This one is for Ingo.
This changes the message rerere issues after reusing previous conflict
resolution from "Resolved" to "Staged" when autoupdate option is in
effect.
It is envisioned that in practice, some auto resolutions are trickier and
iffier than others, and we would want to add a feature to mark individual
resolutions as "this is ok to autoupdate" or "do not autoupdate the result
using this resolution even when rerere.autoupdate is in effect" in the
future. When that happens, these messages will make the distinction
clearer.
* ap/trackinfo (Wed Jul 16 15:19:27 2008 -0400) 1 commit
+ Reword "your branch has diverged..." lines to reduce line length
* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
+ Teach git-merge -X<option> again.
+ Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
+ builtin-merge.c: use parse_options_step() "incremental parsing"
machinery
+ Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
* jc/merge-theirs (Fri Jul 18 02:43:00 2008 -0700) 6 commits
- Document that merge strategies can now take their own options
+ Make "subtree" part more orthogonal to the rest of merge-
recursive.
+ Teach git-pull to pass -X<option> to git-merge
+ Teach git-merge to pass -X<option> to the backend strategy module
+ git-merge-recursive-{ours,theirs}
+ git-merge-file --ours, --theirs
It appears nobody wants "theirs" nor "ours", so I'll soon apply a
wholesale revert for these series to 'next', and then these will be
dropped when we rewind 'next' after 1.6.0 final.
Please make sure next time somebody asks "ours/theirs" merge on the list
and #git s/he is quickly told that it was unanimously rejected so that
people do not have to waste time rehashing the topic ever again.
----------------------------------------------------------------
[Stalled/Needs more work]
* rs/imap (Wed Jul 9 22:29:02 2008 +0100) 5 commits
- Documentation: Improve documentation for git-imap-send(1)
- imap-send.c: more style fixes
- imap-send.c: style fixes
- git-imap-send: Support SSL
- git-imap-send: Allow the program to be run from subdirectories of
a git tree
I said: "Some people seem to prefer having this feature available also
with gnutls. If such a patch materializes soon, that would be good, but
otherwise I'll merge this as-is to 'next'. Such an enhancement can be
done in-tree on top of this series." Anybody?
* gi/cherry-cache (Sat Jul 12 20:14:51 2008 -0700) 1 commit
. cherry: cache patch-ids to avoid repeating work
The discussion suggested that the value of having the cache itself is
iffy, but I should pick up the updated one and look at it.
* lw/gitweb (Fri Jul 11 03:11:48 2008 +0200) 3 commits
. gitweb: use new Git::Repo API, and add optional caching
. Add new Git::Repo API
. gitweb: add test suite with Test::WWW::Mechanize::CGI
* sb/sequencer (Tue Jul 1 04:38:34 2008 +0200) 4 commits
. Migrate git-am to use git-sequencer
. Add git-sequencer test suite (t3350)
. Add git-sequencer prototype documentation
. Add git-sequencer shell prototype
I haven't looked at the updated series yet. I should, but nobody else
seems to be looking at these patches, which is somewhat depressing but
understandable. Summer is slower ;-)
* jc/grafts (Wed Jul 2 17:14:12 2008 -0700) 1 commit
- [BROKEN wrt shallow clones] Ignore graft during object transfer
Cloning or fetching from a repository from grafts did not send objects
that are hidden by grafts, but the commits in the resulting repository do
need these to pass fsck. This fixes object transfer to ignore grafts.
Another fix is needed to git-prune so that it ignores grafts but treats
commits that are mentioned in grafts as reachable.
* 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 is for peeling the line from the blamed version to see what's behind
it, which may or may not help applications like gitweb.
----------------------------------------------------------------
[Dropped]
* xx/merge-in-c-into-next (Wed Jul 9 13:51:46 2008 -0700) 4 commits
+ Teach git-merge -X<option> again.
+ Merge branch 'jc/merge-theirs' into xx/merge-in-c-into-next
+ builtin-merge.c: use parse_options_step() "incremental parsing"
machinery
+ Merge branch 'ph/parseopt-step-blame' into xx/merge-in-c-into-next
* jc/merge-theirs (Fri Jul 18 02:43:00 2008 -0700) 6 commits
- Document that merge strategies can now take their own options
+ Make "subtree" part more orthogonal to the rest of merge-
recursive.
+ Teach git-pull to pass -X<option> to git-merge
+ Teach git-merge to pass -X<option> to the backend strategy module
+ git-merge-recursive-{ours,theirs}
+ git-merge-file --ours, --theirs
It appears nobody wants "theirs" nor "ours", so I'll soon apply a
wholesale revert for these series to 'next', and then these will be
dropped when we rewind 'next' after 1.6.0 final.
Please make sure next time somebody asks "ours/theirs" merge on the list
and #git s/he is quickly told that it was unanimously rejected so that
people do not have to waste time rehashing the topic ever again.
----------------------------------------------------------------
[On Hold]
* sg/merge-options (Sun Apr 6 03:23:47 2008 +0200) 1 commit
+ merge: remove deprecated summary and diffstat options and config
variables
This was previously in "will be in master soon" category, but it turns out
that the synonyms to the ones this one deletes are fairly new invention
that happend in 1.5.6 timeframe, and we cannot do this just yet. Perhaps
in 1.7.0.
* jc/dashless (Thu Jun 26 16:43:34 2008 -0700) 2 commits
+ Revert "Make clients ask for "git program" over ssh and local
transport"
+ Make clients ask for "git program" over ssh and local transport
This is the "botched" one. Will be resurrected during 1.7.0 or 1.8.0
timeframe.
* 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.
^ permalink raw reply
* 1.6.0-rc0 tagged
From: Junio C Hamano @ 2008-07-21 6:20 UTC (permalink / raw)
To: git
I've tagged and pushed out v1.6.0-rc0 tonight. Those who are not
following the git development regularly should take note and please have a
serious look at it, as the upcoming v1.6.0 release will bring in major
usability and modernization changes that we have been announcing/warning
in Release Notes for the past few releases.
* Most subprograms such as git-cat-file will be installed outside your
$PATH by default. Your "/bin/ls /usr/bin" will be much smaller as all
of you have been asking, but you may have to update your scripts as
outlined in the release notes for v1.5.4.
* The new release in the default configuration will produce packfile and
pack idx files that won't be accessible by git older than v1.4.4.5. By
now, those who use git for anything serious should be using v1.5.3 or
later anyway, though.
* The ".dotest" temporary area "git am" and "git rebase" use will be
moved to $GIT_DIR/rebase. We might change it to $GIT_DIR/rebase-apply
which would be more logical name before the final, though.
People who have regularly followed 'master' (and 'next') should not take
this tag too seriously; there is nothing surprising about it since the
last issue of "What's cooking/What's in".
^ permalink raw reply
* Re: [RFC] Stopping those fat "What's cooking in git.git" threads
From: Pierre Habouzit @ 2008-07-21 6:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Miklos Vajna, git
In-Reply-To: <7vsku44679.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 914 bytes --]
On Sun, Jul 20, 2008 at 09:05:30PM +0000, Junio C Hamano wrote:
> Miklos Vajna <vmiklos@frugalware.org> writes:
>
> > So here is what I thought about: What about if everyone (except Junio,
> > of course) would change the subject _and_ remove the In-Reply-To: header
> > when replying to those mails?
> >
> > If those large threads just annoys a few people and most people are
> > happy with the current situation then sorry for the noise.
>
> I could make "What's cooking" not a follow-up to the previous issue,
That'd be great, especially since it's trivial with decent MUAs to get
all issues with a filter (l in mutt, kmail/thunderbird has what it
needs, and I would be surprised if GNUS or pine cannot do that).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* What's _not_ cooking in git.git yet
From: Junio C Hamano @ 2008-07-21 6:33 UTC (permalink / raw)
To: git
In-Reply-To: <7vtzejx0q1.fsf@gitster.siamese.dyndns.org>
There are a few topics that are still not ready but should be in the -rc1.
* I want Pasky's "saner git-mv" to be in if possible, although I am
moderately pessimistic about the submodule work that comes on top of
it.
* "optimize ssh connection for throughput not for latency" may be a
worthy goal, but I think the point Jeff raised about the shared
connection is a valid concern. It might be better not to do anything
funky at the software level, but just add an entry in tips&tricks
section of gitwiki.
Other than that, we should be focused more on fixes on regressions (if
any), fixes in new features added in v1.6.0 cycle, than adding not-yet-in
features nor code clean-ups.
I'll switch my production branch to 'master' tonight. I expect active
contributors to do the same and keep it that way until 1.6.0 final. Right
now, with 'merge -Xtheirs' removed, the difference between 'master' and
'next' is extremely thin.
Thanks.
^ permalink raw reply
* problem using jgit
From: Stephen Bannasch @ 2008-07-21 6:24 UTC (permalink / raw)
To: git
I've setup a simple test class that integrates jgit to clone a git
repository. However I'm getting a NullPointerError when
RevWalk.parseAny ends up producing a null object id.
The code and the stack trace for the error are here:
http://pastie.org/237711
This problem occurs using the jgit from the master branch from this repo:
git://repo.or.cz/egit.git
^ permalink raw reply
* Re: Suggestion: doc restructuring
From: Andreas Ericsson @ 2008-07-21 6:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Michael J Gruber, git
In-Reply-To: <7vk5fhc6qo.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
>> So what I really would like is this: leave the plumbing pages as they are,
>> but enhance those pages that users (especially new ones) are likely to see
>> most often.
>
> Regarding the original "do we want to ever teach plumbing to new users?"
> issue, I suspect that, with sufficient enhancement to Porcelain, we might
> be able to reach a point where end users can work without ever touching a
> single plumbing command at all.
>
> Side note, that was why I suggested us to first think about use
> cases in our every day work that we still need to resort to the
> plumbing, so that we can identify what that enhancement would
> consist of.
>
Half a year or so ago, there were some mailings to the list along the lines
of "what git commands do you use?", using the bash history and a shell
oneliner to dig out some crude intel. Here's mine:
cat ~/.bash_history | grep ^git | awk '{ print $2 }' | grep -v '^--' | sort | uniq --count | sort -nr
29 status
26 diff
19 show
17 log
11 branch
9 grep
8 pull
8 commit
7 fetch
7 describe
6 rev-list
5 help
4 push
4 merge
3 reset
3 config
3 clone
3 add
2 rev-parse
2 format-patch
1 stash
1 checkout
1 apply
To be fair, rev-parse and rev-list are on there due to some oneline scripting.
I needed to move commits from several different branches to a single place,
filtering on author.
> When we reach that point, we might want to restructure the documentation
> into two volumes. One volume for end-users who exclusively use the stock
> git Porcelain, and another that describes plumbing commands for Porcelain
> writers.
>
> Perhaps move the plumbing documentation to section 3; just like Perl has
> DBI.3pm and friends there, /usr/share/man/man3/git-cat-file.3git will
> describe what scripts can do with the command.
I like this idea, although newbie users may not know what section 3 is for.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Mike Hommey @ 2008-07-21 6:53 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Johannes Schindelin, Fredrik Tolf, Keith Packard,
git, Edward Z. Yang, Steffen Prohaska
In-Reply-To: <20080721001422.GB12454@sigill.intra.peff.net>
On Sun, Jul 20, 2008 at 08:14:22PM -0400, Jeff King wrote:
> On Sun, Jul 20, 2008 at 11:23:13AM -0700, Junio C Hamano wrote:
>
> > I think that is a very sensible approach, but just like we have a few
> > "built-in" function-header regexps with customization possibilities for
> > the user, we might want to:
> >
> > * Have that "-x", "-T" in the command line we generate for OpenSSH;
>
> I am slightly negative on this, because we are setting OpenSSH
> preferences behind the user's back that they would not normally expect
> git to be tampering with.
>
> I think the expectation for this is that it impacts only the ssh session
> used by git. But because OpenSSH supports the concept of "master" and
> "slave" sessions (i.e., it can multiplex many sessions over a single ssh
> session, avoiding authentication and thus reducing latency until the
> start of the session), what you do in one session can impact other
> sessions. In particular, if the 'master' does not have x11 forwarding
> (because it happens to be started by git), then slave connections do not
> get it. So a user with X11Forwarding and ControlMaster set in his config
> would usually have everything work, but bad timing with the
> git-initiated session as the master would unexpectedly break his
> X11Forwarding for other sessions.
>
> I don't know how commonly the ControlMaster option for openssh is used.
> I also don't know if this should simply be considered a bug in openssh,
> since it silently ignores the request for X forwarding. Personally, I
> will not be affected because I don't do X forwarding by default, anyway.
> But I thought I would raise the point.
I'm not sure the ControlMaster option is still followed when using -T.
Also, IIRC, ControlMaster doesn't exit until slave connections are
done, so git ssh sessions granted the master control would stall until
then if they happen to have slaves launched. i.e. It can *already* have
bad side effects.
Adding '-S none' would ensure ControlMaster would not take effect; on
the other hand, it would not allow git's ssh connection to be a slave
either. '-o ControlMaster no' could be a solution.
All these need to be tested, obviously.
Mike
^ permalink raw reply
* Re: [PATCH] Ensure that SSH runs in non-interactive mode
From: Jeff King @ 2008-07-21 7:05 UTC (permalink / raw)
To: Mike Hommey
Cc: Junio C Hamano, Johannes Schindelin, Fredrik Tolf, Keith Packard,
git, Edward Z. Yang, Steffen Prohaska
In-Reply-To: <20080721065348.GB24608@glandium.org>
On Mon, Jul 21, 2008 at 08:53:48AM +0200, Mike Hommey wrote:
> I'm not sure the ControlMaster option is still followed when using -T.
It is still followed.
> Also, IIRC, ControlMaster doesn't exit until slave connections are
> done, so git ssh sessions granted the master control would stall until
> then if they happen to have slaves launched. i.e. It can *already* have
> bad side effects.
Yes, that is a problem (and IMHO a weakness in the implementation, but
obviously not git's problem at all).
> Adding '-S none' would ensure ControlMaster would not take effect; on
I think that is definitely a mistake; git is one of the main reasons I
use ControlMaster in the first place.
> the other hand, it would not allow git's ssh connection to be a slave
> either. '-o ControlMaster no' could be a solution.
That is actually quite sensible, and would make this a non-issue, as
far as I can see.
> All these need to be tested, obviously.
I tested, and doing "ssh -Tx -o 'ControlMaster no'" does the right thing
(reuse existing session if possible, create a new one with -Tx
otherwise, and never create a control socket for slaves).
-Peff
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2008-07-21 7:09 UTC (permalink / raw)
To: git
As announced in a separate message, the tip of master was tagged as
1.6.0-rc0; for people who neglected futureproofing themselves so far, it
would really be a good time to seriously consider doing so.
* The 'maint' branch has these fixes since the last announcement.
Jonathan Nieder (1):
fix usage string for git grep
Junio C Hamano (1):
refresh-index: fix bitmask assignment
* The 'master' branch has these since the last announcement
in addition to the above.
Avery Pennarun (1):
Reword "your branch has diverged..." lines to reduce line length
Dmitry Potapov (1):
git-svn: fix git svn info to work without arguments
Junio C Hamano (8):
rerere.autoupdate: change the message when autoupdate is in effect
builtin-add.c: restructure the code for maintainability
git-add --all: add all files
git-add --all: tests
git-add --all: documentation
Link shell with compat layer functions
Move read_in_full() and write_in_full() to wrapper.c
"needs update" considered harmful
Lars Noschinski (1):
cvsserver: Add testsuite for packed refs
Michele Ballabio (2):
builtin-merge.c: Fix option parsing
builtin-push.c: Cleanup - use OPT_BIT() and remove some variables
Miklos Vajna (1):
Teach 'git merge' that some merge strategies no longer exist
Nanako Shiraishi (1):
git am --abort
^ permalink raw reply
* cygwin git and network drives
From: Peter Vun @ 2008-07-21 7:09 UTC (permalink / raw)
To: git
Hi Guys,
I'm currently testing Git on our office network and I noticed on
the following site
http://git.or.cz/gitwiki/CygwinBinaryInstall
that is says
Use git on local NTFS disks -- Network drives disks don't support the
filesystem semantics GIT needs; for interoperability purposes you
can store bare repositories on FAT32 disks.
Does anyone know if the above statement is still valid? Personally, I've
tested cygwin Git with network drives a couple of times and I haven't
encountered any problems, (yet!!).
Any details on Git's limits with regards to this issue would be much
appreciated.
Cheers
Peter
^ permalink raw reply
* Re: [PATCH] git-mv: Keep moved index entries inact
From: Petr Baudis @ 2008-07-21 7:18 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0807210319410.3305@eeepc-johanness>
Hi,
On Mon, Jul 21, 2008 at 03:20:46AM +0200, Johannes Schindelin wrote:
> On Mon, 21 Jul 2008, Petr Baudis wrote:
> > I want to make sure the whole index entry is intact, not just the sha1.
>
> "rev-parse :dirty" will have to read the index to get at the object name
> of "dirty". So there you have your index validation for you.
it will test if the entry stays _valid_, but not whether it stays the
_same_.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH] git-mv: Keep moved index entries inact
From: Junio C Hamano @ 2008-07-21 7:38 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, git
In-Reply-To: <20080721071818.GL10151@machine.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Mon, Jul 21, 2008 at 03:20:46AM +0200, Johannes Schindelin wrote:
>> On Mon, 21 Jul 2008, Petr Baudis wrote:
>> > I want to make sure the whole index entry is intact, not just the sha1.
>>
>> "rev-parse :dirty" will have to read the index to get at the object name
>> of "dirty". So there you have your index validation for you.
>
> it will test if the entry stays _valid_, but not whether it stays the
> _same_.
You are right. You would want to catch breakages like a file losing its
executable bits, which you cannot detect by grabbing "rev-parse :dirty"
and comparing it with the expected value.
^ permalink raw reply
* Re: [PATCH] Add a notice to the doc of git-ls-tree.
From: Petr Baudis @ 2008-07-21 7:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steve Frécinaux, git
In-Reply-To: <7vljzvyi5w.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 20, 2008 at 09:28:59PM -0700, Junio C Hamano wrote:
> Sorry, I may have been unclear. I meant "showing relative to tree-root,
> unlike showing relative to cwd like we have done forever".
>
> Changing the behaviour would affect usage like this:
>
> $ cd some/where
> $ git ls-files
> $ git ls-tree --name-only -r HEAD^
>
> cf. http://thread.gmane.org/gmane.comp.version-control.git/13028/focus=13080
Yes, as I said, by now I agree that this is not acceptable, and thus
opted for just documenting the behaviour. :-)
Petr "Pasky" Baudis
^ permalink raw reply
* Re: [PATCH v2 1/4] builtin-add.c: restructure the code for maintainability
From: Junio C Hamano @ 2008-07-21 7:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <7v3am3yfph.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> That changed late 2006 when Nico allowed git-add to stage already tracked
> files as well. We collect the paths in the work tree that match given
> pathspec, and for the directory traverser to do that job, you would need
> an empty index.
>
> Side note: 366bfcb (make 'git add' a first class user friendly
> interface to the index, 2006-12-04) is something to marvel at. It
> describes the change with its documentation update fully, changes
> the semantics in a drastic way, with so little change.
>
> Documentation/git-add.txt | 53 ++++++++++++-----------
> Documentation/tutorial.txt | 46 ++++++++++++++++++---
> builtin-add.c | 6 +-
> wt-status.c | 2 +-
> 4 files changed, 72 insertions(+), 35 deletions(-)
>
> Perhaps we can add a bit to the dir_struct we give to the traverser to
> tell it to ignore the index even if we have already read one. That would
> be a much cleaner API enhancement than reading the index and setting aside
> while calling read_directory() which feels like a you know what I would
> call it.
Thinking about this issue a bit more, I realize that the earlier "git add -A"
change was done in a quite inefficient way (i.e. it is as unefficient as
"git add -u && git add ." modulo one fork/exec and read/write index). For
that matter, the original "git add ." could probably be more efficient
than it currently is.
The thing is, when the user asks "git add .", we do not have to examine
all paths we encounter and perform the excluded() and dir_add_name()
processing, both of which are slower code and use slower data structure by
git standard, especially when the index is already populated.
Instead, we should be able to implement "git add $pathspec..." as:
- read the index;
- read_directory() to process untracked, unignored files the current way,
that is, recursively doing readdir(), filtering them by pathspec and
excluded(), queueing them via dir_add_name() and finally do
add_files(); and
- iterate over the index, filtering them by pathspec, and update only the
modified/type changed paths but not deleted ones.
And "git add -A" will become exactly the same as above, modulo:
- missing $pathspec means "." instead of being an error; and
- "interate over the index" part handles deleted ones as well,
i.e. exactly what the current update_callback() in builtin-add.c does.
It is likely that I am too tired to do this right tonight, so I'll go to
bed and expect to find a nicely done patch in my mailbox by somebody else
;-).
^ permalink raw reply
* [PATCH] Documentation/git-ls-tree.txt: Add a caveat about prefixing pathspec
From: Petr Baudis @ 2008-07-21 7:56 UTC (permalink / raw)
To: gitster; +Cc: git
In-Reply-To: <20080720233956.GH10151@machine.or.cz>
When run in a working copy subdirectory, git-ls-tree will automagically
add the prefix to the pathspec, which can result in an unexpected behavior
when the tree object accessed is not the root tree object.
This was originally pointed out and described in a patch by
Steve Frénaux <code@istique.net>, this is a shot at clearer and more
accurate description.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-ls-tree.txt | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-ls-tree.txt b/Documentation/git-ls-tree.txt
index 1cdec22..8bb1864 100644
--- a/Documentation/git-ls-tree.txt
+++ b/Documentation/git-ls-tree.txt
@@ -21,6 +21,15 @@ though - 'paths' denote just a list of patterns to match, e.g. so specifying
directory name (without '-r') will behave differently, and order of the
arguments does not matter.
+Note that within a subdirectory of the working copy, 'git ls-tree'
+will automatically prepend the subdirectory prefix to the specified
+paths and assume just the prefix was specified in case no paths were
+given --- no matter what the tree object is!
+Thus, within a subdirectory, 'git ls-tree' behaves as expected
+only when run on a root tree object (e.g. with a 'HEAD' tree-ish,
+but not anymore when passed 'HEAD:Documentation' instead).
+
+
OPTIONS
-------
<tree-ish>::
^ permalink raw reply related
* Re: [PATCH] Documentation/git-ls-tree.txt: Add a caveat about prefixing pathspec
From: Junio C Hamano @ 2008-07-21 8:00 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <20080721075618.14163.45309.stgit@localhost>
Petr Baudis <pasky@suse.cz> writes:
> +Note that within a subdirectory of the working copy, 'git ls-tree'
> +will automatically prepend the subdirectory prefix to the specified
> +paths and assume just the prefix was specified in case no paths were
> +given --- no matter what the tree object is!
Don't be negative upfront. Explain why this is a good thing first.
... were given. This is useful when you are deep in a
subdirectory and want to inspect the list of files in an arbitrary
commit. E.g.
$ cd some/deep/path
$ git ls-tree --name-only -r HEAD~20
will list the files in some/deep/path (i.e. where you are) 20
commits ago, just like running "/bin/ls" there will give you the
list of files you have right now.
> +Thus, within a subdirectory, 'git ls-tree' behaves as expected
> +only when run on a root tree object (e.g. with a 'HEAD' tree-ish,
> +but not anymore when passed 'HEAD:Documentation' instead).
> +
> +
> OPTIONS
> -------
> <tree-ish>::
^ permalink raw reply
* [RFC PATCH] Support copy and rename detection in fast-export.
From: Alexander Gavrilov @ 2008-07-21 8:16 UTC (permalink / raw)
To: git; +Cc: Johannes Schindelin
Although it does not matter for Git itself, tools that
export to systems that explicitly track copies and
renames can benefit from such information.
This patch makes fast-export output correct action
logs when -M or -C are enabled.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
---
I'm thinking about Git->SVN conversion, like http://repo.or.cz/w/git2svn.git
The trouble with this patch is that old versions of fast-export
accept -M and -C, but produce garbage if they are specified.
So the only way for the users to ensure that it is supported is
to check the git version (or directly test it).
As a somewhat related question, in which order does fast-export
output the commits, beside topological? In particular, does it order
commits on parrallel branches (i.e. not topologically dependent) by date?
-- Alexander
builtin-fast-export.c | 28 ++++++++++++++++++++++++++--
t/t9301-fast-export.sh | 46 ++++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 72 insertions(+), 2 deletions(-)
diff --git a/builtin-fast-export.c b/builtin-fast-export.c
index 8bea269..3225e8f 100644
--- a/builtin-fast-export.c
+++ b/builtin-fast-export.c
@@ -118,10 +118,27 @@ static void show_filemodify(struct diff_queue_struct *q,
{
int i;
for (i = 0; i < q->nr; i++) {
+ struct diff_filespec *ospec = q->queue[i]->one;
struct diff_filespec *spec = q->queue[i]->two;
- if (is_null_sha1(spec->sha1))
+
+ switch (q->queue[i]->status) {
+ case DIFF_STATUS_DELETED:
printf("D %s\n", spec->path);
- else {
+ break;
+
+ case DIFF_STATUS_COPIED:
+ case DIFF_STATUS_RENAMED:
+ printf("%c \"%s\" \"%s\"\n", q->queue[i]->status,
+ ospec->path, spec->path);
+
+ if (!hashcmp(ospec->sha1, spec->sha1) &&
+ ospec->mode == spec->mode)
+ break;
+ /* fallthrough */
+
+ case DIFF_STATUS_TYPE_CHANGED:
+ case DIFF_STATUS_MODIFIED:
+ case DIFF_STATUS_ADDED:
/*
* Links refer to objects in another repositories;
* output the SHA-1 verbatim.
@@ -134,6 +151,13 @@ static void show_filemodify(struct diff_queue_struct *q,
printf("M %06o :%d %s\n", spec->mode,
get_object_mark(object), spec->path);
}
+ break;
+
+ default:
+ die("Unexpected comparison status '%c' for %s, %s",
+ q->queue[i]->status,
+ ospec->path ? ospec->path : "none",
+ spec->path ? spec->path : "none");
}
}
}
diff --git a/t/t9301-fast-export.sh b/t/t9301-fast-export.sh
index f18eec9..bb595b7 100755
--- a/t/t9301-fast-export.sh
+++ b/t/t9301-fast-export.sh
@@ -162,4 +162,50 @@ test_expect_success 'submodule fast-export | fast-import' '
'
+export GIT_AUTHOR_NAME='A U Thor'
+export GIT_COMMITTER_NAME='C O Mitter'
+
+test_expect_success 'setup copies' '
+
+ git config --unset i18n.commitencoding &&
+ git checkout -b copy rein &&
+ git mv file file3 &&
+ git commit -m move1 &&
+ test_tick &&
+ cp file2 file4 &&
+ git add file4 &&
+ git mv file2 file5 &&
+ git commit -m copy1 &&
+ test_tick &&
+ cp file3 file6 &&
+ git add file6 &&
+ git commit -m copy2 &&
+ test_tick &&
+ echo more text >> file6 &&
+ echo even more text >> file6 &&
+ git add file6 &&
+ git commit -m modify &&
+ test_tick &&
+ cp file6 file7 &&
+ echo test >> file7 &&
+ git add file7 &&
+ git commit -m copy_modify
+
+'
+
+test_expect_success 'fast-export -C -C | fast-import' '
+
+ ENTRY=$(git rev-parse --verify copy) &&
+ rm -rf new &&
+ mkdir new &&
+ git --git-dir=new/.git init &&
+ git fast-export -C -C --signed-tags=strip --all > output &&
+ grep "^C \"file6\" \"file7\"\$" output &&
+ cat output |
+ (cd new &&
+ git fast-import &&
+ test $ENTRY = $(git rev-parse --verify refs/heads/copy))
+
+'
+
test_done
--
1.5.6.3.18.gfe82
^ permalink raw reply related
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