* [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-23 1:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Dmitry Potapov
In-Reply-To: <alpine.DEB.1.00.0807230203350.8986@racer>
When a file's crlf attribute is explicitely set, it does not make sense
to ignore it when adding the file, just because the config variable
core.autocrlf has not been set.
The alternative would be risking to get CR/LF files into the repository
just because one user forgot to set core.autocrlf.
This patch does not affect the case when the crlf attribute is unset,
or when checking files out.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
Okay, so I lied and did not go to sleep (but that part comes
now). Only the wording in the commit message has changed.
convert.c | 2 +-
t/t0020-crlf.sh | 10 ++++++++++
2 files changed, 11 insertions(+), 1 deletions(-)
diff --git a/convert.c b/convert.c
index 78efed8..d038d2f 100644
--- a/convert.c
+++ b/convert.c
@@ -126,7 +126,7 @@ static int crlf_to_git(const char *path, const char *src, size_t len,
struct text_stat stats;
char *dst;
- if ((action == CRLF_BINARY) || !auto_crlf || !len)
+ if ((action == CRLF_BINARY) || (!auto_crlf && action < 0) || !len)
return 0;
gather_stats(src, len, &stats);
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index 1be7446..0bb3e6f 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -436,4 +436,14 @@ test_expect_success 'invalid .gitattributes (must not crash)' '
'
+test_expect_success 'attribute crlf is heeded even without core.autocrlf' '
+
+ echo "allcrlf crlf=input" > .gitattributes &&
+ git config --unset core.autocrlf &&
+ git add allcrlf &&
+ git show :allcrlf | append_cr > expect &&
+ test_cmp allcrlf expect
+
+'
+
test_done
--
1.6.0.rc0.22.gf2096d.dirty
^ permalink raw reply related
* Re: [PATCH] git-checkout: fix argument parsing to detect ambiguous arguments.
From: Pierre Habouzit @ 2008-07-23 1:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0807230215480.8986@racer>
[-- Attachment #1: Type: text/plain, Size: 1540 bytes --]
On Wed, Jul 23, 2008 at 01:17:52AM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Wed, 23 Jul 2008, Pierre Habouzit wrote:
>
> > diff --git a/builtin-checkout.c b/builtin-checkout.c
> > index fbd5105..1490e8e 100644
> > --- a/builtin-checkout.c
> > +++ b/builtin-checkout.c
> > @@ -438,9 +438,14 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
> >
> > opts.track = git_branch_track;
> >
> > - argc = parse_options(argc, argv, options, checkout_usage, 0);
> > - if (argc) {
> > + argc = parse_options(argc, argv, options, checkout_usage,
> > + PARSE_OPT_KEEP_DASHDASH);
> > +
> > + if (argc && strcmp(argv[0], "--")) {
> > arg = argv[0];
> > +
> > + if (argc == 1 || strcmp(argv[1], "--"))
> > + verify_non_filename(NULL, arg);
>
> Why "argc == 1"? Should "git checkout <path>" really fail? That would be
> a change in behavior that _would_ hit me.
No I was mistaken about what verify_non_filename did, actually I
should not code when I'm so obviously tired, and I wanted
verify_non_filename to do what I meant instead of checking what it does
;P
I believe my resent patch is better.
> However, you may want to verify_non_filename() when argc == 1 _and_
> get_sha1() succeeded. Because then, <path> is ambiguous.
Yes and the reverse when we have sucessfully parsed something that
looks like a path as a path. Anyways, someone should carefully proofread
my resent patch, it's likely that errors slipped through given my sleep
deprivation atm.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RESEND PATCH] git-checkout: fix argument parsing to detect ambiguous arguments.
From: Pierre Habouzit @ 2008-07-23 1:39 UTC (permalink / raw)
To: git, gitster
In-Reply-To: <20080723012751.GI11831@artemis.madism.org>
[-- Attachment #1: Type: text/plain, Size: 3747 bytes --]
On Wed, Jul 23, 2008 at 01:27:51AM +0000, Pierre Habouzit wrote:
> Note that it also fix a bug, git checkout -- <path> would be badly
> understood as git checkout <branch> if <path> is ambiguous with a branch.
>
> Testcases included.
>
> Signed-off-by: Pierre Habouzit <madcoder@debian.org>
> ---
>
> This is a resend with proper patches that made me realize that my
> previous patch had silly mistakes and wasn't testing thigns properly.
>
> builtin-checkout.c | 23 +++++++++++++++++------
> t/t2010-checkout-ambiguous.sh | 35 +++++++++++++++++++++++++++++++++++
> 2 files changed, 52 insertions(+), 6 deletions(-)
> create mode 100755 t/t2010-checkout-ambiguous.sh
>
> diff --git a/builtin-checkout.c b/builtin-checkout.c
> index fbd5105..97321e6 100644
> --- a/builtin-checkout.c
> +++ b/builtin-checkout.c
> @@ -438,12 +438,17 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
>
> opts.track = git_branch_track;
>
> - argc = parse_options(argc, argv, options, checkout_usage, 0);
> - if (argc) {
> + argc = parse_options(argc, argv, options, checkout_usage,
> + PARSE_OPT_KEEP_DASHDASH);
> +
> + if (argc && strcmp(argv[0], "--")) {
> + int may_be_ambiguous = argc == 1 || strcmp(argv[1], "--");
> +
> arg = argv[0];
> - if (get_sha1(arg, rev))
> - ;
> - else if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
> + if (get_sha1(arg, rev)) {
> + if (may_be_ambiguous)
> + verify_filename(NULL, arg);
Dscho mentionned on irc that this bit is superfluous, we already know
that 'arg' cannot be a refspec here, so in the worse case, if it's not a
file at all, this will generate a curious error message about
"ambiguous" arguments, whereas it should fail with an "unknown file"
error or sth similar. This two lines should probably remain ';' like it
previously was.
The rest looks correct to me, but it's late...
> + } else if ((new.commit = lookup_commit_reference_gently(rev, 1))) {
> new.name = arg;
> setup_branch_path(&new);
> if (resolve_ref(new.path, rev, 1, NULL))
> @@ -454,10 +459,16 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
> source_tree = new.commit->tree;
> argv++;
> argc--;
> + if (may_be_ambiguous)
> + verify_non_filename(NULL, arg);
> } else if ((source_tree = parse_tree_indirect(rev))) {
> argv++;
> argc--;
> - }
> + if (may_be_ambiguous)
> + verify_non_filename(NULL, arg);
> + } else
> + if (may_be_ambiguous)
> + verify_filename(NULL, arg);
> }
>
> if (argc && !strcmp(argv[0], "--")) {
> diff --git a/t/t2010-checkout-ambiguous.sh b/t/t2010-checkout-ambiguous.sh
> new file mode 100755
> index 0000000..389ba8c
> --- /dev/null
> +++ b/t/t2010-checkout-ambiguous.sh
> @@ -0,0 +1,35 @@
> +#!/bin/sh
> +
> +test_description='checkout and pathspecs/refspecs ambiguities'
> +
> +. ./test-lib.sh
> +
> +test_expect_success 'setup' '
> + echo hello >world &&
> + echo hello >all &&
> + git add all world &&
> + git commit -m initial &&
> + git branch world
> +'
> +
> +test_expect_success 'branch switching' '
> + test "refs/heads/master" = "$(git symbolic-ref HEAD)" &&
> + git checkout world -- &&
> + test "refs/heads/world" = "$(git symbolic-ref HEAD)"
> +'
> +
> +test_expect_success 'checkout world from the index' '
> + echo bye > world &&
> + git checkout -- world &&
> + git diff --exit-code --quiet
> +'
> +
> +test_expect_success 'non ambiguous call' '
> + git checkout all
> +'
> +
> +test_expect_success 'ambiguous call' '
> + test_must_fail git checkout world
> +'
> +
> +test_done
> --
> 1.6.0.rc0.154.ge2a39.dirty
>
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* RFC: git rebase -i and root commits
From: Eric Raible @ 2008-07-23 1:58 UTC (permalink / raw)
To: git
My normal workflow is to create a .gitignore in my initial commit.
When I later realize that I've forgotten something from that file
I could of course just commit the changes, but I'd rather use "git rebase -i"
in the normal way to make myself appear smarter than I am.
Especially since this realization usually comes early on
(and certainly before publishing).
But rebase can't go all the way to a root ("fatal: Needed a single revision").
The best I've found is:
1) git checkout -b temp <root commit>
2) echo '*.tmp' >> .gitignore
3) git commit --amend .gitignore
4) git rebase --onto temp <root commit> master
If there really is an asymmetry here and I haven't missed anything
(a large assumption), then what's the best way to think about it?
Is there a role for a default commit (e.g. the sha1 of "") here so that
'rebase -i' can update all commits and not just the ones with parents?
Or should I just get used to it and move on?
Thanks - Eric
^ permalink raw reply
* Re: RFC: git rebase -i and root commits
From: Stephan Beyer @ 2008-07-23 2:02 UTC (permalink / raw)
To: Eric Raible; +Cc: git
In-Reply-To: <loom.20080723T013019-412@post.gmane.org>
Hi,
Eric Raible wrote:
> My normal workflow is to create a .gitignore in my initial commit.
>
> When I later realize that I've forgotten something from that file
> I could of course just commit the changes, but I'd rather use "git rebase -i"
> in the normal way to make myself appear smarter than I am.
> Especially since this realization usually comes early on
> (and certainly before publishing).
>
> But rebase can't go all the way to a root ("fatal: Needed a single revision").
I think this has been fixed recently.
Regards,
Stephan
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Git's config core.pager doesn't respect color.pager
From: Benjamin Kudria @ 2008-07-23 2:10 UTC (permalink / raw)
To: git
I'm seeing a problem with git. It's easier to demonstrate than
explain. The relevant parts of my .gitconfig:
[core]
pager = tig
[color]
diff = auto
pager = false
tig is a console-based git client that can also act as a pager,
colorizing git output.
So, with the above config, when I do:
git diff | tig
Everything works correctly - git sends no color codes, because of
color.pager = false.
However, if I do just:
git diff
git uses core.pager to display the output, but still sends color
codes, which is OK for, say, less, bit not so good for tig, which does
it's own colorizing, and displays the color codes git sends as-is.
Shouldn't core.pager respect color.pager, and not send the color codes?
Benjamin Kudria
--
http://ben.kudria.net | Jabber: ben@kudria.net
^ permalink raw reply
* Re: [PATCH] bring description of git diff --cc up to date
From: Jonathan Nieder @ 2008-07-23 3:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Greaves
In-Reply-To: <7vfxq1igh0.fsf@gitster.siamese.dyndns.org>
On Tue, 22 Jul 2008, Junio C Hamano wrote:
>> + This flag implies the '-c' option and makes the patch output
>> + even more compact by omitting uninteresting hunks. A hunk is
>> + considered uninteresting if the person merging had two versions
>> + to choose between among all of the parents and the result shows
>
> the above makes me confused into
> thinking that even if there are 47 parent versions, it is Ok if I looked
> at only two versions and picked from one of them
Here's another attempt. I grimace at the sound of it, but it might be
more clear.
--- snipsnip ---
Subject: document diff --cc's long-ago-changed semantics
In February 2006 [1], the definition of "interesting hunk" for
git's compact-combined diff format changed without a
corresponding change in documentation. This patch brings the
documentation up to date.
[1] commit bf1c32bdec8223785c779779d0a660a099f69a63
combine-diff: update --cc "uninteresting hunks" logic
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
---
Documentation/git-diff-tree.txt | 12 +++++++-----
Documentation/rev-list-options.txt | 9 +++++----
2 files changed, 12 insertions(+), 9 deletions(-)
diff --git a/Documentation/git-diff-tree.txt b/Documentation/git-diff-tree.txt
index 0e45b58..7f8dc5b 100644
--- a/Documentation/git-diff-tree.txt
+++ b/Documentation/git-diff-tree.txt
@@ -92,12 +92,14 @@ include::pretty-options.txt[]
--cc::
This flag changes the way a merge commit patch is displayed,
in a similar way to the '-c' option. It implies the '-c'
- and '-p' options and further compresses the patch output
- by omitting hunks that show differences from only one
- parent, or show the same change from all but one parent
- for an Octopus merge. When this optimization makes all
+ and '-p' options and makes the patch output
+ even more compact by omitting uninteresting hunks. A hunk is
+ considered uninteresting if it shows no changes from at least
+ one of the parents and shows the same changes from each of the
+ parents from which it shows changes.
+ When this optimization makes all
hunks disappear, the commit itself and the commit log
- message is not shown, just like in any other "empty diff" case.
+ message are not shown, just like in any other "empty diff" case.
--always::
Show the commit itself and the commit log message even
diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt
index b6f5d87..d75de78 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -111,10 +111,11 @@ options may be given. See linkgit:git-diff-files[1] for more options.
--cc::
- This flag implies the '-c' options and further compresses the
- patch output by omitting hunks that show differences from only
- one parent, or show the same change from all but one parent for
- an Octopus merge.
+ This flag implies the '-c' option and makes the patch output
+ even more compact by omitting uninteresting hunks. A hunk is
+ considered uninteresting if it shows no changes from at least
+ one of the parents and shows the same changes from each of the
+ parents from which it shows changes.
-r::
--
1.5.6.3.549.g8ca11
^ permalink raw reply related
* Re: [RFC] Git User's Survey 2008
From: Junio C Hamano @ 2008-07-23 4:39 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Stephan Beyer
In-Reply-To: <200807230325.04184.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> 15. What operating system do you use Git on?
> (one or more: multiple choice, as one can use more than one OS)
> - Linux, *BSD (FreeBSD, OpenBSD, etc.), MS Windows/Cygwin,
> MS Windows/msysGit, MacOS X, other UNIX, other
Shouldn't we at least name the ones we have specific support in our
Makefile instead of blanketting them into one "other Unices"? We may not
necessarily want to list all of them, but at least major ones like SunOS,
HP-UX and AIX deserve to be listed, methinks.
> + "What hardware platforms do you use GIT on?" question was
> removed; should it stay?
I think the removal of "hardware platform" question is a good idea.
> 24. If you want to see Git more widely used, what do you
> think we could do to make this happen?
> + Is this question necessary/useful? Do we need wider adoption?
My stance on this has always been that wider adoption, even though it
might eventually come as a consequence of being the best in the field, is
never a goal.
> 27. Which of the following features do you use?
> (zero or more: multiple choice)
> - git-gui or other commit tool, gitk or other history viewer, patch
> management interface (e.g. StGIT), bundle, eol conversion,
> gitattributes, submodules, separate worktree, reflog, stash,
> shallow clone, detaching HEAD, mergetool, interactive rebase,
> add --interactive or other partial commit helper, commit
> templates, bisect, other (not mentioned here)
> + should probably be sorted in some resemblance of order
> + are there any new features which should be listed here?
The above is a valid and interesting question, but "Which features do you
find unique and useful ones, compared to other systems?" would be another
interesting question to ask to people with experience with other systems.
> 28. If you use some important Git features not mentioned above,
> what are it?
> (free form)
"rerere"?
> 40. Do you read the mailing list?
> - yes/no
Which mailing list? Do we want to ask about alternative lists?
I am not sure how and where, but I think j/egit should also be
mentioned and/or asked about.
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Steffen Prohaska @ 2008-07-23 5:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git, Dmitry Potapov
In-Reply-To: <alpine.DEB.1.00.0807230229410.8986@racer>
On Jul 23, 2008, at 3:31 AM, Johannes Schindelin wrote:
> When a file's crlf attribute is explicitely set, it does not make
> sense
> to ignore it when adding the file, just because the config variable
> core.autocrlf has not been set.
Your patch is not about core.autocrlf unset, but about
core.autocrlf=false.
On Unix, the two cases seem to be identical, but on Windows they are
not.
(see below).
> The alternative would be risking to get CR/LF files into the
> repository
> just because one user forgot to set core.autocrlf.
Git could help the user *and* the maintainer of the repository if we
chose core.autocrlf=input as the default on Unix. We would never
let CR/LF enter the repository unless explicitly requested to do so
by core.autocrlf=false. This setting however would not be recommended
to the average user.
But with Unix' default core.autocrlf=false, it makes sense to let the
maintainer of a repository enforce stripping CR from all files if not
explicitly configured otherwise for specific paths. Setting
"crlf=input"
in .gitattribute seems to be the documented way to do so --- although
the documentation in gitattributes.txt is a bit complex to read.
> This patch does not affect the case when the crlf attribute is unset,
> or when checking files out.
>
> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
> ---
>
> Okay, so I lied and did not go to sleep (but that part comes
> now). Only the wording in the commit message has changed.
>
> convert.c | 2 +-
> t/t0020-crlf.sh | 10 ++++++++++
> 2 files changed, 11 insertions(+), 1 deletions(-)
>
> diff --git a/convert.c b/convert.c
> index 78efed8..d038d2f 100644
> --- a/convert.c
> +++ b/convert.c
> @@ -126,7 +126,7 @@ static int crlf_to_git(const char *path, const
> char *src, size_t len,
> struct text_stat stats;
> char *dst;
>
> - if ((action == CRLF_BINARY) || !auto_crlf || !len)
> + if ((action == CRLF_BINARY) || (!auto_crlf && action < 0) || !len)
I think we should strictly follow the documentation, so this should read
+ if ((action == CRLF_BINARY) || (!auto_crlf && action !=
CRLF_INPUT) || !len)
>
> return 0;
>
> gather_stats(src, len, &stats);
> diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
> index 1be7446..0bb3e6f 100755
> --- a/t/t0020-crlf.sh
> +++ b/t/t0020-crlf.sh
> @@ -436,4 +436,14 @@ test_expect_success 'invalid .gitattributes
> (must not crash)' '
>
> '
>
> +test_expect_success 'attribute crlf is heeded even without
> core.autocrlf' '
> +
> + echo "allcrlf crlf=input" > .gitattributes &&
> + git config --unset core.autocrlf &&
You should set core.autocrlf explicitly to false:
git config core.autocrlf false
Otherwise the test would pick up the user's global default.
>
> + git add allcrlf &&
> + git show :allcrlf | append_cr > expect &&
> + test_cmp allcrlf expect
> +
> +'
> +
> test_done
> --
> 1.6.0.rc0.22.gf2096d.dirty
... and we should verify that we only treat crlf=input specially, but
not "crlf".
The following changes could be applied on top of yours. (Apologies if
lines are
wrapped. I am composing this mail with the wrong email client.)
diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
index b37059b..e51e810 100755
--- a/t/t0020-crlf.sh
+++ b/t/t0020-crlf.sh
@@ -436,7 +436,7 @@ test_expect_success 'invalid .gitattributes (must
not crash)' '
'
-test_expect_success 'attribute crlf is heeded even without
core.autocrlf' '
+test_expect_success 'attribute crlf=input is heeded even with
core.autocrlf=false' '
echo "allcrlf crlf=input" > .gitattributes &&
git config core.autocrlf false &&
@@ -446,4 +446,15 @@ test_expect_success 'attribute crlf is heeded
even without core.autocrlf' '
'
+test_expect_success 'attribute crlf is ignored with
core.autocrlf=false' '
+
+ echo "allcrlf crlf" > .gitattributes &&
+ git config core.autocrlf false &&
+ git read-tree --reset HEAD &&
+ git add allcrlf &&
+ git show :allcrlf > expect &&
+ test_cmp allcrlf expect
+
+'
+
test_done
^ permalink raw reply related
* Re: [PATCH/RFC] git add: do not add files from a submodule
From: Junio C Hamano @ 2008-07-23 6:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807222230490.8986@racer>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Do you plan to apply the split-up builtin-add enhancments you did a few
> nights ago,...
I have a few updates to that one, I'll be sending them out shortly.
Switching branches between revs that have and do not have submodule at a
given path has always been broken. It is not even a "known breakage",
which is a word used for something that has a sensible design already is
worked out but the implementation does not do so.
If we started the process of diagnosing and fixing these issues earlier,
and had plausible code to address the issue already in 'next' before the
current -rc cycle started, the topic would have been an obvious candidate
for the coming release and I'd further say it would be even worth delaying
the release for a few weeks if it takes more time. But I have to say it
is too late for 1.6.0 now if we are just noticing and starting the
discussion. This comment goes to the issue Pierre raised last night as
well.
Nobody prevents us from starting the process to discuss and prepare to put
something in 'next' for 1.6.1 cycle now, though.
^ permalink raw reply
* Re: [PATCH v2] git daemon: avoid waking up too often
From: Johannes Sixt @ 2008-07-23 6:51 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807222302440.8986@racer>
Johannes Schindelin schrieb:
> To avoid waking up unnecessarily, a pipe is set up that is only ever
> written to by child_handler(), when a child disconnects, as suggested
> per Junio.
>
> This avoids waking up the main process every second to see if a child
> was disconnected.
This makes porting this beast to Windows practically impossible because we
cannot have a poll() implementation that waits both on a listening socket
and a pipe. :-(
-- Hannes
^ permalink raw reply
* [PATCH 1/2] builtin-add.c: restructure the code for maintainability
From: Junio C Hamano @ 2008-07-23 7:01 UTC (permalink / raw)
To: git
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.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is just code movement.
builtin-add.c | 57 -----------------------------------------------------
cache.h | 1 +
read-cache.c | 61 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 62 insertions(+), 57 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index fc3f96e..0de516a 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;
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;
+}
+
--
1.6.0.rc0.15.g0dda1
^ permalink raw reply related
* [PATCH 2/2] builtin-add.c: optimize -A option and "git add $paths..."
From: Junio C Hamano @ 2008-07-23 7:01 UTC (permalink / raw)
To: git
In-Reply-To: <1216796502-11227-1-git-send-email-gitster@pobox.com>
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 $paths..." could be improved.
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 standards, especially when the index is already reasonably well
populated.
Instead, we 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" becomes exactly the same as above, modulo:
- missing $pathspec means "." instead of being an error; and
- "iterate over the index" part handles deleted ones as well,
i.e. exactly what the current update_callback() in builtin-add.c does.
In either case, because fill_directory() does not use read_directory() to
read everything in, we need to add an extra logic to iterate over the
index to catch mistyped pathspec.
In a fully populated kernel tree (without any local change), best of ten
runs:
(with this patch)
$ /usr/bin/time ~/git-test/bin/git add .
0.16user 0.17system 0:00.34elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3231minor)pagefaults 0swaps
(without this patch)
$ /usr/bin/time ~/git-master/bin/git add .
0.21user 0.21system 0:00.42elapsed 99%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (0major+3647minor)pagefaults 0swaps
Under the same condition, but after "rm .git/index" to force re-indexing
everything (the patch should not make any difference):
(with this patch)
$ /usr/bin/time ~/git-test/bin/git add .
3.22user 2.10system 1:35.10elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (30037major+63003minor)pagefaults 0swaps
(without this patch)
$ /usr/bin/time ~/git-master/bin/git add .
3.31user 2.28system 1:44.77elapsed 5%CPU (0avgtext+0avgdata 0maxresident)k
0inputs+0outputs (30472major+62563minor)pagefaults 0swaps
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-add.c | 43 +++++++++++++++++++++++++++++++------------
1 files changed, 31 insertions(+), 12 deletions(-)
diff --git a/builtin-add.c b/builtin-add.c
index 0de516a..1834e2d 100644
--- a/builtin-add.c
+++ b/builtin-add.c
@@ -18,6 +18,27 @@ static const char * const builtin_add_usage[] = {
static int patch_interactive = 0, add_interactive = 0;
static int take_worktree_changes;
+static void fill_pathspec_matches(const char **pathspec, char *seen, int specs)
+{
+ int num_unmatched = 0, i;
+
+ /*
+ * Since we are walking the index as if we are warlking the directory,
+ * we have to mark the matched pathspec as seen; otherwise we will
+ * mistakenly think that the user gave a pathspec that did not match
+ * anything.
+ */
+ for (i = 0; i < specs; i++)
+ if (!seen[i])
+ num_unmatched++;
+ if (!num_unmatched)
+ return;
+ for (i = 0; i < active_nr; i++) {
+ struct cache_entry *ce = active_cache[i];
+ match_pathspec(pathspec, ce->name, ce_namelen(ce), 0, seen);
+ }
+}
+
static void prune_directory(struct dir_struct *dir, const char **pathspec, int prefix)
{
char *seen;
@@ -37,6 +58,7 @@ static void prune_directory(struct dir_struct *dir, const char **pathspec, int p
*dst++ = entry;
}
dir->nr = dst - dir->entries;
+ fill_pathspec_matches(pathspec, seen, specs);
for (i = 0; i < specs; i++) {
if (!seen[i] && !file_exists(pathspec[i]))
@@ -201,7 +223,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;
@@ -214,7 +236,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");
@@ -223,24 +247,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);
--
1.6.0.rc0.15.g0dda1
^ permalink raw reply related
* [PATCH] Fix git-svnimport against libsvn_ra.
From: P. Christeas @ 2008-07-23 7:10 UTC (permalink / raw)
To: git; +Cc: Gerrit Pape
In r27729, libsvn introduced an assert which explicitly
forbids searching the tree at "/". Luckily enough, it
still accepts an empty string "" as the starting point.
http://svn.collab.net/viewvc/svn/trunk/subversion/libsvn_ra/ra_loader.c?r1=27653&r2=27729
---
contrib/examples/git-svnimport.perl | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/contrib/examples/git-svnimport.perl
b/contrib/examples/git-svnimport.perl
index ea8c1b2..a13bb6a 100755
--- a/contrib/examples/git-svnimport.perl
+++ b/contrib/examples/git-svnimport.perl
@@ -933,7 +933,7 @@ while ($to_rev < $opt_l) {
$to_rev = $from_rev + $repack_after;
$to_rev = $opt_l if $opt_l < $to_rev;
print "Fetching from $from_rev to $to_rev ...\n" if $opt_v;
- $svn->{'svn'}->get_log("/",$from_rev,$to_rev,0,1,1,\&commit_all);
+ $svn->{'svn'}->get_log("",$from_rev,$to_rev,0,1,1,\&commit_all);
my $pid = fork();
die "Fork: $!\n" unless defined $pid;
unless($pid) {
--
1.5.6
^ permalink raw reply related
* [PATCH] rebase -i: When an 'edit' stops, mention the commit
From: Johannes Sixt @ 2008-07-23 7:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
From: Johannes Sixt <johannes.sixt@telecom.at>
In a rebase session where more than one commit is to be 'edit'ed, and the
user spends considerable time to 'edit' a commit, it is easy to forget what
one wanted to 'edit' at the individual commits. It would be helpful to see
at which commit the rebase stopped.
Incidentally, if the rebase stopped due to merge conflicts or other errors,
the commit was already reported ("Could not apply $sha1..."), but when
rebase stopped after successfully applying an "edit" commit, it would not
mention it. With this change the commit is reported.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
---
git-rebase--interactive.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index e63a864..4e334ba 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -277,7 +277,7 @@ do_next () {
die_with_patch $sha1 "Could not apply $sha1... $rest"
make_patch $sha1
: > "$DOTEST"/amend
- warn
+ warn "Stopped at $sha1... $rest"
warn "You can amend the commit now, with"
warn
warn " git commit --amend"
--
1.6.0.rc0.956.g7bc0
^ permalink raw reply related
* HP-UX issues (WAS: Re: [RFC] Git User's Survey 2008)
From: Miklos Vajna @ 2008-07-23 7:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, git, Stephan Beyer
In-Reply-To: <7vsku1gqny.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1481 bytes --]
On Tue, Jul 22, 2008 at 09:39:29PM -0700, Junio C Hamano <gitster@pobox.com> wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > 15. What operating system do you use Git on?
> > (one or more: multiple choice, as one can use more than one OS)
> > - Linux, *BSD (FreeBSD, OpenBSD, etc.), MS Windows/Cygwin,
> > MS Windows/msysGit, MacOS X, other UNIX, other
>
> Shouldn't we at least name the ones we have specific support in our
> Makefile instead of blanketting them into one "other Unices"? We may not
> necessarily want to list all of them, but at least major ones like SunOS,
> HP-UX and AIX deserve to be listed, methinks.
Last time I checked git did not build on HP-UX (11.11) out of the box
because its 'install' did not support -d nor -m. There are a few more
issues installed here:
http://hpux.connect.org.uk/hppd/cgi-bin/wwwtar?/hpux/Development/Tools/git-1.5.6.2/git-1.5.6.2-src-11.11.tar.gz+git-1.5.6.2/HPUX.Install+text
So I think the word "we support" is a bit too strong. ;-)
Being more constructive, what a user using HP-UX is supported to do?
1) Use the patched git from HP.
2) Have coreutils installed. (But then I think it would be good to list
this dependency in INSTALL.)
3) Patch git to use automake's install-sh. (Would such a patch be ever
accepted?)
Thanks.
PS: No, I rarely use git on HP-UX, but I would be happy to bring the
equivalent of HP's most changes to git.git if possible.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH/RFC] git add: do not add files from a submodule
From: Pierre Habouzit @ 2008-07-23 8:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <7vhcahgl2j.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]
On Wed, Jul 23, 2008 at 06:40:20AM +0000, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > Do you plan to apply the split-up builtin-add enhancments you did a few
> > nights ago,...
>
> I have a few updates to that one, I'll be sending them out shortly.
>
> Switching branches between revs that have and do not have submodule at a
> given path has always been broken. It is not even a "known breakage",
> which is a word used for something that has a sensible design already is
> worked out but the implementation does not do so.
>
> If we started the process of diagnosing and fixing these issues earlier,
> and had plausible code to address the issue already in 'next' before the
> current -rc cycle started, the topic would have been an obvious candidate
> for the coming release and I'd further say it would be even worth delaying
> the release for a few weeks if it takes more time. But I have to say it
> is too late for 1.6.0 now if we are just noticing and starting the
> discussion.
Well given that we now use submodules at work, and that git is
nowadays somewhere in the top 5 of my most consciously (as opposed to
the compiler that I rarely call by hand) used software suites (among my
editor, my MUA, my shell and my tiling WM), I'm very much interested in
tackling some things about what is (not) done with submodules yet.
I sent a mail some time ago about those issues, in short words, those
concern git-checkout, git-reset, git-fetch and git-push for starters.
I'm not sure I can help with the code a lot, but I can for sure provide
a comprehensive list of things I would like the porcelain to do with
submodules if that helps.
> This comment goes to the issue Pierre raised last night as well.
You mean the git checkout issue ? Because the issue is twofold, one
there is the missing warnings that users can shoot themselves in the
foot unnoticed, and there is the fact that "git checkout -- $foo" does
not what it should when "$foo" is a valid revision (and *that* is a
really really bad bug, that if I'm correct changing parse_options flags
to KEEP_DASHDASH fixes alright).
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* git-svn does not seems to work with crlf convertion enabled.
From: Alexander Litvinov @ 2008-07-23 8:44 UTC (permalink / raw)
To: git
Hello list.
In short: I can't clone svn repo into git when crlf convertion is activated.
Long story.
I use latest git:
$ git version
git version 1.5.6.4
For a long period of time I use git at work. Main repo is svn-powered and I
use git-svn for linking git and svn. The project itself is a windows cpp
project. I use git under Linux machine (Debian etch with manually backported
git from sid) and work with linux-hosted project thru samba. From the begin I
did not enable crlf convertion and broke crlf notation in files one by one
during my commits. My co-workers does not like this and finally I decide to
try to use autocrlf feature of git. So I take a copy of my git repo and
convert all text files to unix LF line endings:
git filter-branch --tree-filter "find -type f \( -iname '*.h' -or \
-iname '*.cpp' -or -iname '*.vcproj' -or -iname '*.sln' -or \
-iname '*.h.tmpl' -or -iname '*.bat' -or -iname '*.mp' -or \
-iname '*.txt' -or -iname '*.nsi' -or -iname '*.def' -or \
-iname '*.rc' -or -iname '*.ini' -or -iname '*.inf' -or \
-iname '*.skin' -or -iname '*.c' -or -iname '*.dsp' \
-or -iname '*.dsw' \) -print0 | xargs -r0 dos2unix" \
`git branch -a | sed 's/^..//'`
It finished succefully. After fish I have added .git/info/attributes like
this:
* -crlf
*.h crlf
*.c crlf
*.cpp crlf
and so on...
and add set core.autocrlf to true and safecrlf to false. Also I cleared all
git-svn's caches:
rm -rf .git/svn
As I understand I got pure repo that is capable to work with crlf convertion.
Lets update it (on branch forked from trunk): git svn rebase
<.. some long list of revs during migration to new git-svn layout..>
Done rebuilding .git/svn/trunk/.rev_map.f1f59411-8b2e-0410-9ee3-aa470c928bf2
M FindHistory.cpp
Incomplete data: Delta source ended unexpectedly at /tmp/g/bin/git-svn line
3856
Oops ! Whats this ? I am not able to update. I can update other branches but
not trunk.
So I have to try my old original repo without crlf convertion enabled. It was
updated succeffuly, I cant show log it was lost and I was not able to
reproduce it.
Is there any way to fix this problem ?
P.S. I can't even clone that svn repo from scratch with crlf convertion
enabled.
^ permalink raw reply
* Re: [PATCH] Respect crlf attribute in "git add" even if core.autocrlf has not been set
From: Johannes Schindelin @ 2008-07-23 9:02 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Junio C Hamano, git, Dmitry Potapov
In-Reply-To: <719E03C0-E8C3-4C35-AE9C-9BD5A7BCDF03@zib.de>
Hi,
On Wed, 23 Jul 2008, Steffen Prohaska wrote:
> On Jul 23, 2008, at 3:31 AM, Johannes Schindelin wrote:
>
> >When a file's crlf attribute is explicitely set, it does not make sense
> >to ignore it when adding the file, just because the config variable
> >core.autocrlf has not been set.
>
> Your patch is not about core.autocrlf unset, but about
> core.autocrlf=false.
No, no, no!
It is about autocrlf _unset_, i.e. when the user was _not_ explicit!
> >The alternative would be risking to get CR/LF files into the repository
> >just because one user forgot to set core.autocrlf.
>
> Git could help the user *and* the maintainer of the repository if we
> chose core.autocrlf=input as the default on Unix.
NO!
The machinery behind core.autocrlf _does_ slow down Git, even if only by a
few percent. But with patch queues as maintainers of busy projects
encounter frequently, this makes a difference.
So no, I am _totally_ opposed to punishing Unix users for Windows' faults.
Totally.
> >diff --git a/convert.c b/convert.c
> >index 78efed8..d038d2f 100644
> >--- a/convert.c
> >+++ b/convert.c
> >@@ -126,7 +126,7 @@ static int crlf_to_git(const char *path, const char *src,
> >size_t len,
> > struct text_stat stats;
> > char *dst;
> >
> >- if ((action == CRLF_BINARY) || !auto_crlf || !len)
> >+ if ((action == CRLF_BINARY) || (!auto_crlf && action < 0) || !len)
>
> I think we should strictly follow the documentation, so this should read
>
> + if ((action == CRLF_BINARY) || (!auto_crlf && action != CRLF_INPUT) ||
> !len)
NO!
Your version would break action == CRLF_TEXT.
> >diff --git a/t/t0020-crlf.sh b/t/t0020-crlf.sh
> >index 1be7446..0bb3e6f 100755
> >--- a/t/t0020-crlf.sh
> >+++ b/t/t0020-crlf.sh
> >@@ -436,4 +436,14 @@ test_expect_success 'invalid .gitattributes (must not
> >crash)' '
> >
> >'
> >
> >+test_expect_success 'attribute crlf is heeded even without core.autocrlf' '
> >+
> >+ echo "allcrlf crlf=input" > .gitattributes &&
> >+ git config --unset core.autocrlf &&
>
> You should set core.autocrlf explicitly to false:
>
> git config core.autocrlf false
But this is _not_ what I want! I want it to be _unset_. Yes, at the
moment, auto_crlf is initialized to 0. But I do not _care_ what it is
set. I want this test to succeed when the user did _not_ set autocrlf.
> Otherwise the test would pick up the user's global default.
It will not. We went to great pains not to pick up global defaults in the
test suite.
> ... and we should verify that we only treat crlf=input specially, but not
> "crlf".
Umm... Why? Why should a file marked "crlf=true" be allowed to be checked
in _with_ CRs?
Ciao,
Dscho
^ permalink raw reply
* Re: RFC: git rebase -i and root commits
From: Johannes Schindelin @ 2008-07-23 9:05 UTC (permalink / raw)
To: Stephan Beyer; +Cc: Eric Raible, git
In-Reply-To: <20080723020232.GF5904@leksak.fem-net>
Hi,
On Wed, 23 Jul 2008, Stephan Beyer wrote:
> Eric Raible wrote:
> > My normal workflow is to create a .gitignore in my initial commit.
> >
> > When I later realize that I've forgotten something from that file
> > I could of course just commit the changes, but I'd rather use "git rebase -i"
> > in the normal way to make myself appear smarter than I am.
> > Especially since this realization usually comes early on
> > (and certainly before publishing).
> >
> > But rebase can't go all the way to a root ("fatal: Needed a single revision").
>
> I think this has been fixed recently.
No, it has not.
What has been fixed is that you can cherry-pick a root commit now, not
rebase onto nothing.
While I am somewhat sympathetic with Eric's use case, I am not sure that
we should support it with rebase -i.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] rebase -i: When an 'edit' stops, mention the commit
From: Johannes Schindelin @ 2008-07-23 9:10 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <4886E1DB.7020308@viscovery.net>
Hi,
On Wed, 23 Jul 2008, Johannes Sixt wrote:
> In a rebase session where more than one commit is to be 'edit'ed, and
> the user spends considerable time to 'edit' a commit, it is easy to
> forget what one wanted to 'edit' at the individual commits. It would be
> helpful to see at which commit the rebase stopped.
"... So mention it."
ACK.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH v2] git daemon: avoid waking up too often
From: Johannes Schindelin @ 2008-07-23 9:17 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, Junio C Hamano
In-Reply-To: <4886D503.7030106@viscovery.net>
Hi,
On Wed, 23 Jul 2008, Johannes Sixt wrote:
> Johannes Schindelin schrieb:
> > To avoid waking up unnecessarily, a pipe is set up that is only ever
> > written to by child_handler(), when a child disconnects, as suggested
> > per Junio.
> >
> > This avoids waking up the main process every second to see if a child
> > was disconnected.
>
> This makes porting this beast to Windows practically impossible because we
> cannot have a poll() implementation that waits both on a listening socket
> and a pipe. :-(
Umm. We also do not have signal handlers, do we? AFAICT you wanted to
simulate _this_ program's fork() with a start_async(), right? All you
have to do is to refactor the code with the pipe to do the update
(properly guarded by a mutex, which is called "CriticalSection" in Windows
speak, since it is impossible for Microsoft to accept common conventions).
The biggest part to get this beast running on Windows is to move it to the
start_async() method, not above-mentioned refactoring.
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn does not seems to work with crlf convertion enabled.
From: Johannes Schindelin @ 2008-07-23 9:18 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <200807231544.23472.litvinov2004@gmail.com>
Hi,
On Wed, 23 Jul 2008, Alexander Litvinov wrote:
> In short: I can't clone svn repo into git when crlf convertion is
> activated.
This is a known issue, but since nobody with that itch seems to care
enough to fix it, I doubt it will ever be fixed.
Ciao,
Dscho
^ permalink raw reply
* Not so happy about build system
From: Jan Engelhardt @ 2008-07-23 9:33 UTC (permalink / raw)
To: git
Hi,
I just tried git 1.5.6.4 on a Solaris 10 box. Building mostly went
smooth, but a few unhappy edges turned up:
~/git-1.5.6.4>gmake MAKE=gmake
LINK git-daemon
ld: fatal: library -lcurl: not found
ld: fatal: library -lcrypto: not found
ld: fatal: File processing errors. No output written to git-daemon
collect2: ld returned 1 exit status
gmake: *** [git-daemon] Error 1
Of course curl is available, it's just somewhere else. And that is where
the fun begins that comes with plain Makefiles.
"What's the variable I ought to set?"
Yes, usually it is LDFLAGS, and this is also true for git. But not
everyone necessarily adheres to that, and looking through the Makefile
is not fun. That also reminds me of CFLAGS, which about every Makefile
write happily sets to
CFLAGS = -g -O2 -Wall -Wmy-fancy-flags
which would give no way to keep -Wmy-fancy-flags while also overriding
it. Autotools solved this whereby a developer puts -Wmy-fancy-flags that
shall always be present into AM_CFLAGS instead and only puts the really
freely choosable flags into CFLAGS. Of course I could list all the
developers flags that are needed/wanted (-Wmy-fancy-flags) like
make CFLAGS="-Wdevelopers-fancy-flags -O3 -g0"
but one would have to look them up first and and etc.
Ok, enough Makefile ramblings, as there seems to be a configure script
lurking. What's the Makefile good for then if configure will create it
anyway?
Trying my luck with configure, I call
./configure --prefix=$HOME/rt --with-openssl=/opt/csw
--with-curl=/opt/csw
but what I get is that it obviously did not find neither openssl nor
curl, though they do exist in /opt/csw/include and /opt/csw/lib:
checking for SHA1_Init in -lcrypto... no
checking for SHA1_Init in -lssl... no
checking for curl_global_init in -lcurl... no
checking for XML_ParserCreate in -lexpat... no
(someone please fix that)
./configure --prefix=$HOME/rt --with-openssl=/opt/csw
--with-curl=/opt/csw CFLAGS="-O2 -I/opt/csw/include -L/opt/csw/lib
-R/opt/csw/lib"
# using /usr/ccs/bin/ld, not GNU ld
That finally made it succeed in finding SHA1_Init. Then however,
~/git-1.5.6.4>make
make: Fatal error in reader: Makefile, line 158: Unexpected end
of line seen
So configure did not create a POSIX-compatible Makefile. Ok,
I had gmake, so the story is successfully done here :)
^ permalink raw reply
* Re: [RFC] Git User's Survey 2008
From: Johannes Schindelin @ 2008-07-23 9:53 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Stephan Beyer
In-Reply-To: <200807230325.04184.jnareb@gmail.com>
Hi,
On Wed, 23 Jul 2008, Jakub Narebski wrote:
> First there is a question about the form of survey. Should we use web
> based survey, as the survey before (http://www.survey.net.nz), sending
> emails with link to this survey, or perhaps do email based survey,
> with email Reply-To: address put for this survey alone?
Some people prefer to stay anonymous, so I think email is out.
> 04. Which programming languages you are proficient with?
> (The choices include programming languages used by git)
> (zero or more: multiple choice)
> - C, shell, Perl, Python, Tcl/Tk
> + (should we include other languages, like C++, Java, PHP,
> Ruby,...?)
Yes, I think this should be a long list.
> 07. What helped you most in learning to use it?
> (free form question)
Is it possible to have multiple choice, with "other" (free-form)? Then
I'd suggest:
Colleague/Instructor, User Manual, Manpages, Tutorials, Tutorials
(elsewhere; not in git.git), Mailing list, IRC, Git Wiki, Other.
> 08. What did you find hardest in learning Git?
> What did you find harderst in using Git?
s/harderst/hardest.
> (free form question)
Again, I'd suggest a multiple choice + Other:
The amount of commands, the amount of options, the index (AKA
staging), branching, user interface, bugs, Other.
> Other SCMs (shortened compared with 2007 survey)
>
> 10. What other SCM did or do you use?
> (zero or more: multiple choice)
> - CVS, Subversion, GNU Arch or arch clone (ArX, tla, ...),
> Bazaar-NG, Darcs, Mercurial, Monotone, SVK, AccuRev, Perforce,
> BitKeeper, ClearCase, MS Visual Source Safe, MS Visual Studio
> Team System, custom, other(*)
PVCS seems to be pretty popular, too.
> 11. Why did you choose Git? (if you use Git)
> What do you like about using Git?
> (free form, not to be tabulated)
Again, to avoid hassles with free-form:
Mandatory: work, mandatory: open source project I am participating
in, speed, scalability, It's What Linus Uses, Other.
> 12. Why did you choose other SCMs? (if you use other SCMs)
> What do you like about using other SCMs?
> Note: please write name of SCMs you are talking about.
> (free form, not to be tabulated).
Again:
ease-of use, simplicity, existing project uses it, I Do Not Like
Linus, Other
> 15. What operating system do you use Git on?
> (one or more: multiple choice, as one can use more than one OS)
> - Linux, *BSD (FreeBSD, OpenBSD, etc.), MS Windows/Cygwin,
> MS Windows/msysGit, MacOS X, other UNIX, other
You should include "Dunno", which gets automatically mapped to "MS
Windows/msysGit" ;-)
> 19. How do you publish/propagate your changes?
> (zero or more: multiple choice)
> - push, pull request, format-patch + email, bundle, other
git svn
You might laugh, but it is a sad fact that some guy promotes "Using Git
with Google Code" by using git-svn to drive their crappy Subversion.
> 22. How does Git compare to other SCM tools you have used?
> - worse/equal (or comparable)/better
> 23. What would you most like to see improved about Git?
> (features, bugs, plug-ins, documentation, ...)
Maybe here should be another question "What are the most useful features
of Git?" but maybe that is covered by earlier questions.
> 24. If you want to see Git more widely used, what do you
> think we could do to make this happen?
> + Is this question necessary/useful? Do we need wider adoption?
I agree with Junio: this is not so interesting for us; we are no company,
and we have no sales department who could wank of on these answers.
> 27. Which of the following features do you use?
> (zero or more: multiple choice)
> - git-gui or other commit tool, gitk or other history viewer, patch
> management interface (e.g. StGIT), bundle, eol conversion,
For our Windows friends, we should add " (crlf)" to the last item.
> 42. Do you find traffic levels on Git mailing list OK.
> - yes/no? (optional)
/too low? *ducksandrunsforcover*
> 44. If yes, do you find IRC channel useful?
> - yes/no (optional)
/somewhat. Even if I would be the only one choosing that option.
> 45. Did you have problems getting GIT help on mailing list or
> on IRC channel? What were it? What could be improved?
> (free form)
Yeah, I know who will answer to that, and what... "yaddayadda very
unfriendly yaddayadda especially that Johannes guy yaddayadda" (you know
who you are)... *lol*
Thanks Jakub, I think that your effort is very useful.
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