* 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
* 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
* 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
* 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
* 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: [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: [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] 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: [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
* 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: [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
* Re: [PATCH 2/2] git-add -a: add all files
From: Jay Soffian @ 2008-07-21 2:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Tarmigan, git, Michael J Gruber
In-Reply-To: <7v4p6k8l36.fsf@gitster.siamese.dyndns.org>
On Sun, Jul 20, 2008 at 2:30 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I do not understand either of you. If for whatever reason "add -A" makes
> sense in your workflow, it's a sign that you are extremely disciplined
> that changes in your working tree at one point of time where you would
> issue "add -A" are concentrated on a single topic, and at one of such
> points you may want to commit. For such a disciplined person, "commit -a"
> would make perfect sense there.
>
> So for such people who would find "add -A" useful, "commit -a" will not be
> "unrelated changes in the same commit". And for such people, I would even
> say "commit -A" would be even more useful, too.
Hah, it's Sunday and my brain wasn't awake. You're right, "commit -a"
complements when I'd use "add -a" -- namely, when I have a branch that
is tracking a non-git source: either files I'm rsyncing from another
VCS or drops I'm getting as tarballs. (I'm aware of import-tars.perl.)
j.
^ permalink raw reply
* Re: [PATCH/rfc] git-svn.perl: workaround assertions in svn library 1.5.0
From: Junio C Hamano @ 2008-07-21 1:54 UTC (permalink / raw)
To: Eric Wong; +Cc: Dmitry Potapov, Gerrit Pape, git
In-Reply-To: <20080721012955.GA14129@untitled>
Thanks, both.
^ permalink raw reply
* Re: [PATCH v2] Ensure that SSH runs in non-interactive mode
From: Fredrik Tolf @ 2008-07-21 1:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807210310330.3305@eeepc-johanness>
On Mon, 2008-07-21 at 03:15 +0200, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 21 Jul 2008, Fredrik Tolf wrote:
>
> > I'm following my previous SSH patch up with this one, which should at
> > least solve the problems discussed, and probably some more. If anything,
> > it might be considered a bit overkill for the problem at hand.
>
> I am not assuming it is overkill, but since you do not reuse functions
> such as strbuf_expand() and split_cmdline(), your patch ends up pretty
> large.
Thanks! I didn't know that there was a split_cmdline. I will use it and
resubmit.
> And since you use very short and undescriptive variable names, with ugly
> assignments inside arithmetic expressions, I will be less likely
> reviewing it in detail.
I actually use those assignments for clarity. IMO, it is more clear to
have one line which clearly initializes a buffer (and from which the
exact details of the buffer initialization can still be read), than to
litter an algorithm with lots of auxiliary lines that obfuscate what the
code really does.
Seeing how you disagree, though, I'll change that too when I'm at it.
> > I assume it might have to be documented as well, if people approve of it.
>
> Catch 22. Since you have not documented what %P should be useful for,
> people might not approve of the patch, because they do not understand what
> it is supposed to do.
Yes, that would be a problem. Here's some makeshift documentation:
The string specified in core.sshcommand is first checked if it matches
any of the built-in templates, in which case it is expanded (I've added
the templates "openssh" and "plink" by default). When used, the string
is split into words, each of which is processed as follows:
* If a word is %p, it is replaced by the port number, if specified.
If the port number is not specified, the word is deleted.
* If a word is %h, it is replaced by the remote host name.
* If a word begins with %P, it is deleted if no port number is
specified. This is to allow for specifying different port number
flags for different SSH implementations. The syntax is a bit ugly,
but I cannot really think of anything that would look better.
If a port number has been specified, the leading %P is simply deleted.
The result is used, along with the command to run on the remote side, as
the SSH command line.
Fredrik Tolf
^ permalink raw reply
* Re: [PATCH] Fix git-shell build error when NO_SETENV is defined
From: Johannes Schindelin @ 2008-07-21 1:33 UTC (permalink / raw)
To: Stephan Beyer; +Cc: SungHyun Nam, git, gitster
In-Reply-To: <20080721012928.GG5950@leksak.fem-net>
Hi,
On Mon, 21 Jul 2008, Stephan Beyer wrote:
> Johannes Schindelin wrote:
> > Funny. It was not 24 hours ago that Hannes reported a related issue. And
> > he was testing with different options.
>
> Oh, seems that I have missed that topic. Gna :)
>
> But fine if everything is working again then.
No, it is not.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH/rfc] git-svn.perl: workaround assertions in svn library 1.5.0
From: Eric Wong @ 2008-07-21 1:29 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: Junio C Hamano, Gerrit Pape, git
In-Reply-To: <20080720201407.GM2925@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> wrote:
> On Sat, Jul 19, 2008 at 06:27:36PM -0700, Junio C Hamano wrote:
> >
> > So what's the conclusion of this issue?
> >
> > I'll just revert 2fe403e (git-svn.perl: workaround assertions in svn
> > library 1.5.0, 2008-07-06) for 1.6.0-rc0 unless I hear better
> > suggestions.
>
> I have tested the change that I proposed, and it seems to solve the
> problem and, as far as I can tell, no other correction is necessary.
> Yet, I don't really understand git-svn well, so I could be wrong.
>
> Reverting 2fe403e will only help users of svn library 1.4, while all
> new linux distributives, which will include Git 1.6.0, are going to
> install svn library 1.5.0, and if you use svn library 1.5.0, reverting
> 2fe403e does not fix anything but only add one more bug. Thus, unless
> we are going to require to install git-svn only with svn library 1.4,
> reverting this change does not seem to be very helpful for most users.
>
> So, I hope my patch is better solution...
>
> Dmitry
Thanks Dmitry,
Your patch works for me on 1.4.3, so if it works with
1.5.0, consider it: Acked-by: Eric Wong <normalperson@yhbt.net>
--
Eric Wong
^ permalink raw reply
* Re: [PATCH] Fix git-shell build error when NO_SETENV is defined
From: Stephan Beyer @ 2008-07-21 1:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: SungHyun Nam, git, gitster
In-Reply-To: <alpine.DEB.1.00.0807210321190.3305@eeepc-johanness>
Johannes Schindelin wrote:
> Funny. It was not 24 hours ago that Hannes reported a related issue. And
> he was testing with different options.
Oh, seems that I have missed that topic. Gna :)
But fine if everything is working again then.
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [HACK] t/test-lib.sh HACK: Add -s/--show-hack to test suite.
From: Stephan Beyer @ 2008-07-21 1:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807131518370.4816@eeepc-johanness>
Hi,
Johannes Schindelin wrote:
> You will have to scroll back a few lines to see exactly what failed, but
> you will see the exact commands (also of functions that were called),
> together with their return values (i.e. what the function output, and what
> was assigned to variables).
I've tested again and found it now. Thanks!
It's a littler harder to see, but now I know that I should look for
the last "+ eval_ret=" line, ...that makes it easier ;)
Puh, now I can finally move this thread to the archives :)
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: [PATCH] Fix git-shell build error when NO_SETENV is defined
From: Johannes Schindelin @ 2008-07-21 1:23 UTC (permalink / raw)
To: Stephan Beyer; +Cc: SungHyun Nam, git, gitster
In-Reply-To: <1216601017-7871-1-git-send-email-s-beyer@gmx.net>
Hi,
On Mon, 21 Jul 2008, Stephan Beyer wrote:
> If NO_SETENV is defined, git-shell could not be built.
>
> Thanks to SungHyun Nam for the hint.
>
> Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
> ---
>
> This was my mistake. I haven't tested with several build options.
> Now I've tested with
> NO_SETENV=1 NO_EXPAT=1 NO_MEMMEM=1 NO_STRTOUMAX=1 NO_MKDTEMP=1
> NO_SYS_SELECT_H=1 NO_SYMLINK_HEAD=1
> and compat/setenv.o seems to be the only one that was missing.
Funny. It was not 24 hours ago that Hannes reported a related issue. And
he was testing with different options.
His fix to include COMPAT_OBJECTS made much more sense, too, than to pick
selectively a file here and a file there and then hoping that you catch
all.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-mv: Keep moved index entries inact
From: Johannes Schindelin @ 2008-07-21 1:20 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, git
In-Reply-To: <20080721002354.GK10151@machine.or.cz>
Hi,
On Mon, 21 Jul 2008, Petr Baudis wrote:
> On Sat, Jul 19, 2008 at 04:54:20PM -0700, Junio C Hamano wrote:
> > Petr Baudis <pasky@suse.cz> writes:
> >
> > > +test_expect_success 'git mv should not change sha1 of moved cache entry' '
> > > +
> > > + rm -fr .git &&
> > > + git init &&
> > > + echo 1 >dirty &&
> > > + git add dirty &&
> > > + entry="$(git ls-files --stage dirty | cut -f 1)"
> >
> > "rev-parse :dirty"?
>
> 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.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] Ensure that SSH runs in non-interactive mode
From: Johannes Schindelin @ 2008-07-21 1:15 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: git
In-Reply-To: <1216598432-18553-1-git-send-email-fredrik@dolda2000.com>
Hi,
On Mon, 21 Jul 2008, Fredrik Tolf wrote:
> I'm following my previous SSH patch up with this one, which should at
> least solve the problems discussed, and probably some more. If anything,
> it might be considered a bit overkill for the problem at hand.
I am not assuming it is overkill, but since you do not reuse functions
such as strbuf_expand() and split_cmdline(), your patch ends up pretty
large.
And since you use very short and undescriptive variable names, with ugly
assignments inside arithmetic expressions, I will be less likely
reviewing it in detail.
> I assume it might have to be documented as well, if people approve of it.
Catch 22. Since you have not documented what %P should be useful for,
people might not approve of the patch, because they do not understand what
it is supposed to do.
People like me,
Dscho
^ permalink raw reply
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Johannes Schindelin @ 2008-07-21 1:05 UTC (permalink / raw)
To: Sam Vilain; +Cc: Jakub Narebski, git, Joshua Roys
In-Reply-To: <1216601739.6523.48.camel@maia.lan>
Hi,
On Mon, 21 Jul 2008, Sam Vilain wrote:
> On Mon, 2008-07-21 at 00:29 +0200, Jakub Narebski wrote:
> > 1. GitTorrent
> >
> > [...]
> >
> > Besides canonical repository gitweb
> > http://utsl.gen.nz/gitweb/?p=VCS-Git-Torrent
> > there is also mirror at
> > http://repo.or.cz/w/VCS-Git-Torrent.git
> >
> > There is some activity there... but no summary of it anywhere I could
> > find.
>
> git-log | git-shortlog? ;)
Please note that one of the reasons why last year's libgit-thin project
has not been merged, or even been useful to anybody else, because it has
been developed in too private a manner. Sad.
I would appreciate it, therefore, to keep the progress way more public
than it is now. That is, either you or your student should be not
invisible.
Ciao,
Dscho
^ permalink raw reply
* [PATCH/RFC] git add: do not add files from a submodule
From: Johannes Schindelin @ 2008-07-21 0:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807201529150.3305@eeepc-johanness>
It comes quite as a surprise to an unsuspecting Git user that calling
"git add submodule/file" (which is a mistake, alright) _removes_
the submodule in the index, and adds the file. Instead, complain loudly.
While at it, be nice when the user said "git add submodule/" which is
most likely the consequence of tab-completion, and stage the submodule,
instead of trying to add the contents of that directory.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
This would need a companion patch for "git diff submodule/",
obviously. However, revision.c does not need a valid cache,
usually. So I am hesitant.
Oh, and I am sure somebody will come up with a more elegant
solution to this problem. I sure do not, having smashed my head
against the wall for a few hours.
builtin-add.c | 42 +++++++++++++++++++++++++++++++++++++++---
t/t7400-submodule-basic.sh | 18 ++++++++++++++++++
2 files changed, 57 insertions(+), 3 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 6f5672a..9453557 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -50,6 +50,33 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
free(seen);
}
+static void treat_gitlinks(const char **pathspec, struct index_state *index)
+{
+ int i;
+
+ if (!pathspec || !*pathspec)
+ return;
+
+ for (i = 0; i < index->cache_nr; i++) {
+ struct cache_entry *ce = index->cache[i];
+ if (S_ISGITLINK(ce->ce_mode)) {
+ int len = ce_namelen(ce), j;
+ for (j = 0; pathspec[j]; j++) {
+ int len2 = strlen(pathspec[j]);
+ if (len2 <= len || pathspec[j][len] != '/' ||
+ memcmp(ce->name, pathspec[j], len))
+ continue;
+ if (len2 == len + 1)
+ /* strip trailing slash */
+ pathspec[j] = xstrndup(ce->name, len);
+ else
+ die ("Path '%s' is in submodule '%.*s'",
+ pathspec[j], len, ce->name);
+ }
+ }
+ }
+}
+
static void fill_directory(struct dir_struct *dir, const char **pathspec,
int ignored_too)
{
@@ -245,6 +272,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
int flags;
int add_new_files;
int require_pathspec;
+ struct index_state index;
argc = parse_options(argc, argv, builtin_add_options,
builtin_add_usage, 0);
@@ -283,12 +311,20 @@ int cmd_add(int argc, const char **argv, const char *prefix)
* 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.
+ *
+ * However, to avoid adding files from submodules, we have to
+ * read the index first. So read the index into a local
+ * variable, and set the global index after fill_directory().
*/
- if (add_new_files)
- fill_directory(&dir, pathspec, ignored_too);
- if (read_cache() < 0)
+ memset(&index, 0, sizeof(index));
+ if (read_index(&index) < 0)
die("index file corrupt");
+ treat_gitlinks(pathspec, &index);
+
+ if (add_new_files)
+ fill_directory(&dir, pathspec, ignored_too);
+ the_index = index;
if (refresh_only) {
refresh(verbose, pathspec);
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index cbc0c34..6da2545 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -209,4 +209,22 @@ test_expect_success 'update --init' '
'
+test_expect_success 'do not add files from a submodule' '
+
+ git reset --hard &&
+ test_must_fail git add init/a
+
+'
+
+test_expect_success 'gracefully add submodule with a trailing slash' '
+
+ commit=$(cd init &&
+ echo b > a &&
+ git commit -m update a >/dev/null &&
+ git rev-parse HEAD) &&
+ git add init/ &&
+ test_must_fail git diff --exit-code --cached init
+
+'
+
test_done
--
1.5.6.2.516.g22071
^ permalink raw reply related
* Re: [GSoC] What is status of Git's Google Summer of Code 2008 projects?
From: Sam Vilain @ 2008-07-21 0:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Joshua Roys
In-Reply-To: <200807210029.31543.jnareb@gmail.com>
On Mon, 2008-07-21 at 00:29 +0200, Jakub Narebski wrote:
> 1. GitTorrent
>
> Student: Joshua Roys
> Mentor: Sam Vilain
>
> I never got more response than "it is going slower than I would like,
> [...] Other than that, it's going well, I think." from Joshua Roys.
> Mailing list archives for gittorrent mailing list doesn't show anything
> interesting, either (last post is from 2007).
> http://lists.utsl.gen.nz/pipermail/gittorrent/
That's a valid complaint. I've posted a summary of the project status
there, and will keep as much related discussion as appropriate on-list
from here.
> Besides canonical repository gitweb
> http://utsl.gen.nz/gitweb/?p=VCS-Git-Torrent
> there is also mirror at
> http://repo.or.cz/w/VCS-Git-Torrent.git
>
> There is some activity there... but no summary of it anywhere I could
> find.
git-log | git-shortlog? ;)
Sam.
^ permalink raw reply
* Re: [PATCH v2 1/4] builtin-add.c: restructure the code for maintainability
From: Johannes Schindelin @ 2008-07-21 0:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1216534144-23826-1-git-send-email-gitster@pobox.com>
Hi,
On Sat, 19 Jul 2008, Junio C Hamano wrote:
> diff --git a/builtin-add.c b/builtin-add.c
> index bf13aa3..9b2ee8c 100644
> --- a/builtin-add.c
> +++ b/builtin-add.c
> [...]
> + /*
> + * 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.
> + */
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.
I can only imagine that the other users of read_directory() depend on some
funny interaction between the index and treat_directory().
Ciao,
Dscho
^ 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