* 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
* Re: [PATCH v2 1/4] builtin-add.c: restructure the code for maintainability
From: Junio C Hamano @ 2008-07-21 8:24 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <7v7ibfvfmh.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> 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.
> ...
> 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
> ;-).
Well, I lied. I couldn't sleep, so here is a preview that seems to pass
all the test at least. It needs to be split into two, but I am too tired
to do that properly tonight.
The main part of the change is third hunk (preimage ll.258-) to the bottom
of builtin-add.c and follows the idea outlined in the message this is a
response to.
A private function add_files_to_cache() in builtin-add.c was borrowed by
checkout and commit re-implementors without getting properly refactored to
more library-ish place. This does the refactoring, and most of the
changes you see in the diffstat are this; it should come before the main
part of the change.
---
builtin-add.c | 78 ++++++--------------------------------------------------
cache.h | 1 +
read-cache.c | 61 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 71 insertions(+), 69 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index fc3f96e..f9b25f2 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -8,10 +8,6 @@
#include "dir.h"
#include "exec_cmd.h"
#include "cache-tree.h"
-#include "diff.h"
-#include "diffcore.h"
-#include "commit.h"
-#include "revision.h"
#include "run-command.h"
#include "parse-options.h"
@@ -79,59 +75,6 @@ static void fill_directory(struct dir_struct *dir, const char **pathspec,
prune_directory(dir, pathspec, baselen);
}
-struct update_callback_data
-{
- int flags;
- int add_errors;
-};
-
-static void update_callback(struct diff_queue_struct *q,
- struct diff_options *opt, void *cbdata)
-{
- int i;
- struct update_callback_data *data = cbdata;
-
- for (i = 0; i < q->nr; i++) {
- struct diff_filepair *p = q->queue[i];
- const char *path = p->one->path;
- switch (p->status) {
- default:
- die("unexpected diff status %c", p->status);
- case DIFF_STATUS_UNMERGED:
- case DIFF_STATUS_MODIFIED:
- case DIFF_STATUS_TYPE_CHANGED:
- if (add_file_to_cache(path, data->flags)) {
- if (!(data->flags & ADD_CACHE_IGNORE_ERRORS))
- die("updating files failed");
- data->add_errors++;
- }
- break;
- case DIFF_STATUS_DELETED:
- if (!(data->flags & ADD_CACHE_PRETEND))
- remove_file_from_cache(path);
- if (data->flags & (ADD_CACHE_PRETEND|ADD_CACHE_VERBOSE))
- printf("remove '%s'\n", path);
- break;
- }
- }
-}
-
-int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
-{
- struct update_callback_data data;
- struct rev_info rev;
- init_revisions(&rev, prefix);
- setup_revisions(0, NULL, &rev, NULL);
- rev.prune_data = pathspec;
- rev.diffopt.output_format = DIFF_FORMAT_CALLBACK;
- rev.diffopt.format_callback = update_callback;
- data.flags = flags;
- data.add_errors = 0;
- rev.diffopt.format_callback_data = &data;
- run_diff_files(&rev, DIFF_RACY_IS_MODIFIED);
- return !!data.add_errors;
-}
-
static void refresh(int verbose, const char **pathspec)
{
char *seen;
@@ -258,7 +201,7 @@ int cmd_add(int argc, const char **argv, const char *prefix)
if (addremove && take_worktree_changes)
die("-A and -u are mutually incompatible");
- if (addremove && !argc) {
+ if ((addremove || take_worktree_changes) && !argc) {
static const char *here[2] = { ".", NULL };
argc = 1;
argv = here;
@@ -271,7 +214,9 @@ int cmd_add(int argc, const char **argv, const char *prefix)
flags = ((verbose ? ADD_CACHE_VERBOSE : 0) |
(show_only ? ADD_CACHE_PRETEND : 0) |
- (ignore_add_errors ? ADD_CACHE_IGNORE_ERRORS : 0));
+ (ignore_add_errors ? ADD_CACHE_IGNORE_ERRORS : 0) |
+ (!(addremove || take_worktree_changes)
+ ? ADD_CACHE_IGNORE_REMOVAL : 0));
if (require_pathspec && argc == 0) {
fprintf(stderr, "Nothing specified, nothing added.\n");
@@ -280,24 +225,19 @@ 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)
+ /* This picks up the paths that are not tracked */
+ fill_directory(&dir, pathspec, ignored_too);
+
if (refresh_only) {
refresh(verbose, pathspec);
goto finish;
}
- if (take_worktree_changes || addremove)
- exit_status |= add_files_to_cache(prefix, pathspec, flags);
+ exit_status |= add_files_to_cache(prefix, pathspec, flags);
if (add_new_files)
exit_status |= add_files(&dir, flags);
diff --git a/cache.h b/cache.h
index 38985aa..6f374ad 100644
--- a/cache.h
+++ b/cache.h
@@ -375,6 +375,7 @@ extern int remove_file_from_index(struct index_state *, const char *path);
#define ADD_CACHE_VERBOSE 1
#define ADD_CACHE_PRETEND 2
#define ADD_CACHE_IGNORE_ERRORS 4
+#define ADD_CACHE_IGNORE_REMOVAL 8
extern int add_to_index(struct index_state *, const char *path, struct stat *, int flags);
extern int add_file_to_index(struct index_state *, const char *path, int flags);
extern struct cache_entry *make_cache_entry(unsigned int mode, const unsigned char *sha1, const char *path, int stage, int refresh);
diff --git a/read-cache.c b/read-cache.c
index a50a851..6833af6 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -8,6 +8,11 @@
#include "cache-tree.h"
#include "refs.h"
#include "dir.h"
+#include "tree.h"
+#include "commit.h"
+#include "diff.h"
+#include "diffcore.h"
+#include "revision.h"
/* Index extensions.
*
@@ -1444,3 +1449,59 @@ int read_index_unmerged(struct index_state *istate)
istate->cache_nr = dst - istate->cache;
return !!last;
}
+
+struct update_callback_data
+{
+ int flags;
+ int add_errors;
+};
+
+static void update_callback(struct diff_queue_struct *q,
+ struct diff_options *opt, void *cbdata)
+{
+ int i;
+ struct update_callback_data *data = cbdata;
+
+ for (i = 0; i < q->nr; i++) {
+ struct diff_filepair *p = q->queue[i];
+ const char *path = p->one->path;
+ switch (p->status) {
+ default:
+ die("unexpected diff status %c", p->status);
+ case DIFF_STATUS_UNMERGED:
+ case DIFF_STATUS_MODIFIED:
+ case DIFF_STATUS_TYPE_CHANGED:
+ if (add_file_to_index(&the_index, path, data->flags)) {
+ if (!(data->flags & ADD_CACHE_IGNORE_ERRORS))
+ die("updating files failed");
+ data->add_errors++;
+ }
+ break;
+ case DIFF_STATUS_DELETED:
+ if (data->flags & ADD_CACHE_IGNORE_REMOVAL)
+ break;
+ if (!(data->flags & ADD_CACHE_PRETEND))
+ remove_file_from_index(&the_index, path);
+ if (data->flags & (ADD_CACHE_PRETEND|ADD_CACHE_VERBOSE))
+ printf("remove '%s'\n", path);
+ break;
+ }
+ }
+}
+
+int add_files_to_cache(const char *prefix, const char **pathspec, int flags)
+{
+ struct update_callback_data data;
+ struct rev_info rev;
+ init_revisions(&rev, prefix);
+ setup_revisions(0, NULL, &rev, NULL);
+ rev.prune_data = pathspec;
+ rev.diffopt.output_format = DIFF_FORMAT_CALLBACK;
+ rev.diffopt.format_callback = update_callback;
+ data.flags = flags;
+ data.add_errors = 0;
+ rev.diffopt.format_callback_data = &data;
+ run_diff_files(&rev, DIFF_RACY_IS_MODIFIED);
+ return !!data.add_errors;
+}
+
^ permalink raw reply related
* Re: 1.6.0-rc0 tagged
From: Jakub Narebski @ 2008-07-21 8:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd4l7wyfl.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> * 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.
Very good idea. $GIT_DIR/rebase looks slightly strange with git-am.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH v2] Ensure that SSH runs in non-interactive mode
From: Jakub Narebski @ 2008-07-21 8:38 UTC (permalink / raw)
To: Fredrik Tolf; +Cc: Johannes Schindelin, git
In-Reply-To: <1216604693.3673.20.camel@pc7.dolda2000.com>
Fredrik Tolf <fredrik@dolda2000.com> writes:
> [...] 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.
There is a syntax which would look better, but perhaps it is a bit
overkill in this situation. Namely use either shell conditional
expansion:
${p:+-P $p}
or syntax used in RPM spec macros
%{?p:-P %p}
(and there is complementing %{!?<var>:<expansion>} in RPM spec macro
language).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] Documentation/git-ls-tree.txt: Add a caveat about prefixing pathspec
From: Steve Frécinaux @ 2008-07-21 8:45 UTC (permalink / raw)
To: Petr Baudis; +Cc: gitster, git
In-Reply-To: <20080721075618.14163.45309.stgit@localhost>
On Mon, Jul 21, 2008 at 9:56 AM, Petr Baudis <pasky@suse.cz> wrote:
> 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.
There is a typo in my name ;-)
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Jakub Narebski @ 2008-07-21 8:47 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Miklos Vajna, Junio C Hamano, Johannes Schindelin,
Nanako Shiraishi, git
In-Reply-To: <bd6139dc0807201558k6e3d85b8u30d214f16e1040bd@mail.gmail.com>
"Sverre Rabbelier" <alturin@gmail.com> writes:
> On Sun, Jul 20, 2008 at 10:33 PM, Miklos Vajna <vmiklos@frugalware.org> wrote:
>> On Sun, Jul 20, 2008 at 10:03:24PM +0200, Sverre Rabbelier <alturin@gmail.com> wrote:
>>> Whatever happened to quotes?
>>>
>>> $ git merge -s subtree -Xpath="git-gui git-gui/master"
>>
>> Read again what did you wrote. ;-)
>>
>> The current form is
>>
>> git merge -s subtree git-gui/master, so at most it could be
>>
>> $ git merge -s subtree -Xpath="git-gui" git-gui/master
>
> Meh, what I of course mean was:
> $ git merge -s subtree -X"path=git-gui" git-gui/master
>
> But that looks rather awkward, which is probably why I typed it the
> way I did? Maybe something like....
> $ git merge -s subtree -X(--path=git-gui --foo=bar) git-gui/master
Or perhaps (following -Wx family of GCC options)
$ git merge -s subtree -X--path=git-gui,--foo=bar git-gui/master
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* git pull versus fetch/merge
From: Rene Herman @ 2008-07-21 9:11 UTC (permalink / raw)
To: git; +Cc: Takashi Iwai
Good day.
A while ago I was here asking about "git pull" versus "git merge" for
local branches -- now I see a difference for remote ones that I'm not
sure should be there.
I gathered before that "git pull <remote> <branch>" should basically be
shorthand for "git fetch <remote>, git merge <remote>/<branch>". Is that
correct?
I'm seeing a problem I believe with a specific repository:
rene@7ixe4:~/src/linux/7ixe4$ git remote show tiwai
* remote tiwai
URL: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
Tracked remote branches
devel dma-fix for-linus master upstream
with "git pull tiwai devel" everything goes well:
rene@7ixe4:~/src/linux/7ixe4$ git status
# On branch master
nothing to commit (working directory clean)
rene@7ixe4:~/src/linux/7ixe4$ git branch tmp0 v2.6.26
rene@7ixe4:~/src/linux/7ixe4$ git branch tmp1 v2.6.26
rene@7ixe4:~/src/linux/7ixe4$ git checkout tmp0
Switched to branch "tmp0"
rene@7ixe4:~/src/linux/7ixe4$ git pull tiwai devel
Updating bce7f79..e0bf09b
Fast forward
Documentation/sound/alsa/ALSA-Configuration.txt | 17 +-
[ ... ]
and I get a clean merge. On the other hand, if I try to do this with a
fetch/merge, I get:
rene@7ixe4:~/src/linux/7ixe4$ git checkout tmp1
Switched to branch "tmp1"
rene@7ixe4:~/src/linux/7ixe4$ git fetch tiwai
From git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6
! [rejected] devel -> tiwai/devel (non fast forward)
! [rejected] dma-fix -> tiwai/dma-fix (non fast forward)
! [rejected] master -> tiwai/master (non fast forward)
rene@7ixe4:~/src/linux/7ixe4$ git merge tiwai/devel
Auto-merged sound/pci/ac97/ac97_patch.c
Auto-merged sound/pci/emu10k1/emu10k1_main.c
Auto-merged sound/pci/hda/patch_analog.c
Auto-merged sound/pci/hda/patch_realtek.c
CONFLICT (content): Merge conflict in sound/pci/hda/patch_realtek.c
Auto-merged sound/pci/hda/patch_sigmatel.c
Automatic merge failed; fix conflicts and then commit the result.
and me no happy...
It probably has something to do with that " ! [rejected]" but what is
that about? Is the repo bad? (and if so, I suspect owner will want to
know how to avoid it in the future).
And if it is bad, should I be seeing something with the pull method
also? Moreover... can I now trust my tmp0 branch?
Rene.
^ permalink raw reply
* [PATCH] Enable threaded delta search on *BSD and Linux.
From: Pierre Habouzit @ 2008-07-21 9:23 UTC (permalink / raw)
To: git; +Cc: gitster, Pierre Habouzit
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
Following the discussion we had 10 days ago, here is a proposal to enable
threaded delta search on systems that are likely to behave properly wrt
memory and CPU usage.
Makefile | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 551bde9..82f89b7 100644
--- a/Makefile
+++ b/Makefile
@@ -565,9 +565,11 @@ EXTLIBS =
ifeq ($(uname_S),Linux)
NO_STRLCPY = YesPlease
+ THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),GNU/kFreeBSD)
NO_STRLCPY = YesPlease
+ THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),UnixWare)
CC = cc
@@ -665,6 +667,7 @@ ifeq ($(uname_S),FreeBSD)
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
DIR_HAS_BSD_GROUP_SEMANTICS = YesPlease
+ THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),OpenBSD)
NO_STRCASESTR = YesPlease
@@ -672,6 +675,7 @@ ifeq ($(uname_S),OpenBSD)
NEEDS_LIBICONV = YesPlease
BASIC_CFLAGS += -I/usr/local/include
BASIC_LDFLAGS += -L/usr/local/lib
+ THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),NetBSD)
ifeq ($(shell expr "$(uname_R)" : '[01]\.'),2)
@@ -680,6 +684,7 @@ ifeq ($(uname_S),NetBSD)
BASIC_CFLAGS += -I/usr/pkg/include
BASIC_LDFLAGS += -L/usr/pkg/lib
ALL_LDFLAGS += -Wl,-rpath,/usr/pkg/lib
+ THREADED_DELTA_SEARCH = YesPlease
endif
ifeq ($(uname_S),AIX)
NO_STRCASESTR=YesPlease
--
1.6.0.rc0.137.g986dd
^ permalink raw reply related
* error: hook declined to update refs/heads/master
From: Jonathan Biolaz @ 2008-07-21 9:34 UTC (permalink / raw)
To: git
Hye,
I'm trying to make a remote repository on a Mac Osx Server leopard.
I tried many methods to create the remote. First one, I clone my local
repository with the --bare options, then copy this repo on the server
and add the remote to my local repository, Second one, I create an
empty bare repository on the server and then I try to push my local
repository on it.
Everything I'm doing is given my the same error when I try to push to
the server :
$ git push origin master
Counting objects: 1709, done.
Compressing objects: 100% (1523/1523), done.
Writing objects: 100% (1709/1709), 1.95 MiB | 3818 KiB/s, done.
Total 1709 (delta 535), reused 0 (delta 0)
*** Project description file hasn't been set
error: hooks/update exited with error code 1
error: hook declined to update refs/heads/master
To jbiolaz@macpro1.sikalab:/mp1_data/sikatizen/Dev/repo/calame.git
! [remote rejected] master -> master (hook declined)
error: failed to push some refs to 'jbiolaz@macpro1.sikalab:/mp1_data/
sikatizen/Dev/repo/calame.git'
I made the same on a linux server ad it's working well (but with
another repository)
I don't know what to do to make this working.
Also, my server Leopard server is driving me crazy, I have to had for
every user a .bashrc which one contain the path to git. I don't find a
way to add this for all user !
I hope someone can help me !!
Thanks !!
Jbiolaz
^ permalink raw reply
* Re: error: hook declined to update refs/heads/master
From: Johannes Schindelin @ 2008-07-21 9:54 UTC (permalink / raw)
To: Jonathan Biolaz; +Cc: git
In-Reply-To: <80F1AC38-8A10-4184-BBFB-870399DE9A3A@sikatizen.com>
Hi,
On Mon, 21 Jul 2008, Jonathan Biolaz wrote:
> $ git push origin master
>
> Counting objects: 1709, done.
> Compressing objects: 100% (1523/1523), done.
> Writing objects: 100% (1709/1709), 1.95 MiB | 3818 KiB/s, done.
> Total 1709 (delta 535), reused 0 (delta 0)
> *** Project description file hasn't been set
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> error: hooks/update exited with error code 1
> error: hook declined to update refs/heads/master
Apparently, you have a hook installed on the remote side which checks for
a valid description, and refuses even updating refs before you set the
description correctly.
Hth,
Dscho
^ permalink raw reply
* Re: Suggestion: doc restructuring
From: Johannes Schindelin @ 2008-07-21 10:04 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Michael J Gruber, git
In-Reply-To: <48842FA8.5070309@op5.se>
Hi,
On Mon, 21 Jul 2008, Andreas Ericsson wrote:
> Junio C Hamano wrote:
>
> > 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.
Actually, I did not even like that approach back then. Just because you
happen to be an old-timer and use rev-parse and rev-list frequently does
not mean that you _have_ to use it, or even _should_ use it, or that it
would be good to teach your command lines to a newbie.
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