* Re: builtin conversion between tabs and spaces
From: A Large Angry SCM @ 2008-10-15 23:34 UTC (permalink / raw)
To: Stefan Karpinski
Cc: Jonathan del Strother, Alex Riesen, Git Mailing List,
Johannes Sixt
In-Reply-To: <d4bc1a2a0810151602j56550c3di2f59f92039fa8243@mail.gmail.com>
Stefan Karpinski wrote:
> Any further comments? I'm more than willing to implement this, but I
> won't bother if there's no chance of getting it accepted as a patch.
> Does no one else feel like at least having the option to enforce
> whitespace consistency in git is a good thing? If not, I guess I'll
> just muddle along without this feature instead of implementing it.
I'm against including this in except as a sample smudge/clean script.
Git is a content tracker; not the enforcement mechanism for individual
project policies.
^ permalink raw reply
* Re: [PATCH] gitk: bind Key-Return to create on new branch dialog
From: Paul Mackerras @ 2008-10-15 23:11 UTC (permalink / raw)
To: Richard Quirk; +Cc: git
In-Reply-To: <1224017605-13893-1-git-send-email-richard.quirk@gmail.com>
Richard Quirk writes:
> The Return key can now be used as well as pressing the Create button
> from the dialog box that is shown when selecting "Create new branch".
Thanks, applied.
Paul.
^ permalink raw reply
* Re: [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths
From: Linus Torvalds @ 2008-10-15 23:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Andrew Morton, david, Git Mailing List
In-Reply-To: <7vy70ppiq1.fsf_-_@gitster.siamese.dyndns.org>
On Wed, 15 Oct 2008, Junio C Hamano wrote:
>
> When aborting a failed merge that has brought in a new path using "git
> reset --hard" or "git read-tree --reset -u", we used to first forget about
> the new path (via read_cache_unmerged) and then matched the working tree
> to what is recorded in the index, thus ending up leaving the new path in
> the work tree.
Looks good to me. And from my tests, I think "git checkout -f" didn't have
this problem at all, because it ends up using not got read-tree, but doing
its own "reset_tree()" that uses unpack_trees().
I do wonder if "git reset" should perhaps be written in those terms,
instead of just being a wrapper around git read-tree. But the patch looks
fine.
Linus
^ permalink raw reply
* Re: builtin conversion between tabs and spaces
From: Stefan Karpinski @ 2008-10-15 23:02 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Alex Riesen, Git Mailing List, Johannes Sixt
In-Reply-To: <d4bc1a2a0810151418r3bf21ddaj498017e8e178f579@mail.gmail.com>
Any further comments? I'm more than willing to implement this, but I
won't bother if there's no chance of getting it accepted as a patch.
Does no one else feel like at least having the option to enforce
whitespace consistency in git is a good thing? If not, I guess I'll
just muddle along without this feature instead of implementing it.
On Wed, Oct 15, 2008 at 2:18 PM, Stefan Karpinski
<stefan.karpinski@gmail.com> wrote:
> That's not what I would call a "crazy" mix of tabs and spaces, but
> rather a *sane* mix of tabs and spaces. That can consistently be
> reproduced, and is in fact what the spaces_to_tabs function included
> above produces. The sane consistent formats as I see it are:
>
> 1) use spaces for everything
> 2) use tabs for indentation, spaces for everything else
> 3) use tabs for indentation and alignment
>
> If you know the tab size, you can reproduce any of these from the
> others, except that #3 is a little tricky since there's places where
> the tab/space issue can be ambiguous. I actually think that keeping
> the repo version with tab-based indentation is a very sane thing to
> do. However, I'd still like to be able to edit the files using soft
> tabs, largely because any program that doesn't know what my tab size
> should be applies its own interpretation and makes the code look
> terrible (think terminal output for diff, cat, less, etc.)
>
> On the other hand, a *crazy* mix of tabs and spaces is where some
> indentation is done with spaces while other indentation is done with
> tabs. Even crazier is a single line where the indentation is a mixture
> of tabs and spaces. I think that just about everyone can agree that
> this is not only crazy, but evil and is the kind of thing one really
> wants to avoid in a code base. Unfortunately, when developers disagree
> on their standard settings, it's very, very hard to avoid precisely
> this kind of mess. My idea is to enable git to prevent this sort of
> insanity if configured to do so.
^ permalink raw reply
* [PATCH] reset --hard/read-tree --reset -u: remove unmerged new paths
From: Junio C Hamano @ 2008-10-15 23:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, david, Git Mailing List
In-Reply-To: <7v3aixqzrn.fsf@gitster.siamese.dyndns.org>
When aborting a failed merge that has brought in a new path using "git
reset --hard" or "git read-tree --reset -u", we used to first forget about
the new path (via read_cache_unmerged) and then matched the working tree
to what is recorded in the index, thus ending up leaving the new path in
the work tree.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>> On Wed, 15 Oct 2008, Linus Torvalds wrote:
>>>
>> It's quite possible that we should remove unmerged entries. Except that's
>> not how our internal 'read_cache_unmerged()' function works. It really
>> just ignores them, and throws them on the floor. We _could_ try to just
>> turn them into a (since) stage-0 entry.
>>
>> Junio?
>
> I am not sure what should happen when we can't drop the unmerged entry
> down to stage-0 due to D/F conflicts, though. IIRC, read-tree proper
> would not touch the work tree in such a case, but merge-recursive creates
> our and their versions with funny suffixes, which will not be known to the
> index and will be left in the working tree.
I am still unsure what we should do when we hit D/F conflicts; this one
simply replaces but it may be safer to drop ADD_CACHE_OK_TO_REPLACE from
the options to trigger an error in such a case. I dunno.
read-cache.c | 32 +++++++++++++++++++-------------
t/t1005-read-tree-reset.sh | 30 ++++++++++++++++++++++++++++++
2 files changed, 49 insertions(+), 13 deletions(-)
diff --git a/read-cache.c b/read-cache.c
index c229fd4..efbab6a 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -1489,25 +1489,31 @@ int write_index(const struct index_state *istate, int newfd)
int read_index_unmerged(struct index_state *istate)
{
int i;
- struct cache_entry **dst;
- struct cache_entry *last = NULL;
+ int unmerged = 0;
read_index(istate);
- dst = istate->cache;
for (i = 0; i < istate->cache_nr; i++) {
struct cache_entry *ce = istate->cache[i];
- if (ce_stage(ce)) {
- remove_name_hash(ce);
- if (last && !strcmp(ce->name, last->name))
- continue;
- cache_tree_invalidate_path(istate->cache_tree, ce->name);
- last = ce;
+ struct cache_entry *new_ce;
+ int size, len, option;
+
+ if (!ce_stage(ce))
continue;
- }
- *dst++ = ce;
+ unmerged = 1;
+ len = strlen(ce->name);
+ size = cache_entry_size(len);
+ new_ce = xcalloc(1, size);
+ hashcpy(new_ce->sha1, ce->sha1);
+ memcpy(new_ce->name, ce->name, len);
+ new_ce->ce_flags = create_ce_flags(len, 0);
+ new_ce->ce_mode = ce->ce_mode;
+ option = ADD_CACHE_OK_TO_ADD|ADD_CACHE_OK_TO_REPLACE;
+ if (add_index_entry(istate, new_ce, option))
+ return error("%s: cannot drop to stage #0",
+ ce->name);
+ i = index_name_pos(istate, new_ce->name, len);
}
- istate->cache_nr = dst - istate->cache;
- return !!last;
+ return unmerged;
}
struct update_callback_data
diff --git a/t/t1005-read-tree-reset.sh b/t/t1005-read-tree-reset.sh
index b0d31f5..0cd519c 100755
--- a/t/t1005-read-tree-reset.sh
+++ b/t/t1005-read-tree-reset.sh
@@ -27,4 +27,34 @@ test_expect_success 'reset should work' '
test_cmp expect actual
'
+test_expect_success 'reset should remove remnants from a failed merge' '
+ git read-tree --reset -u HEAD &&
+ git ls-files -s >expect &&
+ sha1=$(git rev-parse :new) &&
+ (
+ echo "100644 $sha1 1 old"
+ echo "100644 $sha1 3 old"
+ ) | git update-index --index-info &&
+ >old &&
+ git ls-files -s &&
+ git read-tree --reset -u HEAD &&
+ git ls-files -s >actual &&
+ ! test -f old
+'
+
+test_expect_success 'Porcelain reset should remove remnants too' '
+ git read-tree --reset -u HEAD &&
+ git ls-files -s >expect &&
+ sha1=$(git rev-parse :new) &&
+ (
+ echo "100644 $sha1 1 old"
+ echo "100644 $sha1 3 old"
+ ) | git update-index --index-info &&
+ >old &&
+ git ls-files -s &&
+ git reset --hard &&
+ git ls-files -s >actual &&
+ ! test -f old
+'
+
test_done
--
1.6.0.2.717.gc6f0a
^ permalink raw reply related
* [PATCH] parse-opt: migrate builtin-checkout-index.
From: Miklos Vajna @ 2008-10-15 22:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
NOTE: I introduced the force/quiet/not_new helper variables because they
are originally bitfields, so passing their address is not possible. One
could say that introducing helper functions for those as well would be
nicer, but I think that would just make the code even longer with no
good reason.
builtin-checkout-index.c | 151 +++++++++++++++++++++++++---------------------
1 files changed, 82 insertions(+), 69 deletions(-)
diff --git a/builtin-checkout-index.c b/builtin-checkout-index.c
index 4ba2702..e241cd1 100644
--- a/builtin-checkout-index.c
+++ b/builtin-checkout-index.c
@@ -40,6 +40,7 @@
#include "cache.h"
#include "quote.h"
#include "cache-tree.h"
+#include "parse-options.h"
#define CHECKOUT_ALL 4
static int line_termination = '\n';
@@ -153,11 +154,55 @@ static void checkout_all(const char *prefix, int prefix_length)
exit(128);
}
-static const char checkout_cache_usage[] =
-"git checkout-index [-u] [-q] [-a] [-f] [-n] [--stage=[123]|all] [--prefix=<string>] [--temp] [--] <file>...";
+static const char * const builtin_checkout_index_usage[] = {
+ "git checkout-index [-u] [-q] [-a] [-f] [-n] [--stage=[123]|all] [--prefix=<string>] [--temp] [--] <file>...",
+ NULL
+};
static struct lock_file lock_file;
+static int option_parse_u(const struct option *opt,
+ const char *arg, int unset)
+{
+ int *newfd = opt->value;
+
+ state.refresh_cache = 1;
+ if (*newfd < 0)
+ *newfd = hold_locked_index(&lock_file, 1);
+ return 0;
+}
+
+static int option_parse_z(const struct option *opt,
+ const char *arg, int unset)
+{
+ line_termination = unset;
+ return 0;
+}
+
+static int option_parse_prefix(const struct option *opt,
+ const char *arg, int unset)
+{
+ state.base_dir = arg;
+ state.base_dir_len = strlen(arg);
+ return 0;
+}
+
+static int option_parse_stage(const struct option *opt,
+ const char *arg, int unset)
+{
+ if (!strcmp(arg, "all")) {
+ to_tempfile = 1;
+ checkout_stage = CHECKOUT_ALL;
+ } else {
+ int ch = arg[0];
+ if ('1' <= ch && ch <= '3')
+ checkout_stage = arg[0] - '0';
+ else
+ die("stage should be between 1 and 3 or all");
+ }
+ return 0;
+}
+
int cmd_checkout_index(int argc, const char **argv, const char *prefix)
{
int i;
@@ -165,6 +210,33 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
int all = 0;
int read_from_stdin = 0;
int prefix_length;
+ int force = 0, quiet = 0, not_new = 0;
+ struct option builtin_checkout_index_options[] = {
+ OPT_BOOLEAN('a', "all", &all,
+ "checks out all files in the index"),
+ OPT_BOOLEAN('f', "force", &force,
+ "forces overwrite of existing files"),
+ OPT__QUIET(&quiet),
+ OPT_BOOLEAN('n', "no-create", ¬_new,
+ "don't checkout new files"),
+ { OPTION_CALLBACK, 'u', "index", &newfd, NULL,
+ "update stat information in the index file",
+ PARSE_OPT_NOARG, option_parse_u },
+ { OPTION_CALLBACK, 'z', NULL, NULL, NULL,
+ "paths are separated with NUL character",
+ PARSE_OPT_NOARG, option_parse_z },
+ OPT_BOOLEAN(0, "stdin", &read_from_stdin,
+ "read list of paths from the standard input"),
+ OPT_BOOLEAN(0, "temp", &to_tempfile,
+ "write the content to temporary files"),
+ OPT_CALLBACK(0, "prefix", NULL, "string",
+ "when creating files, prepend <string>",
+ option_parse_prefix),
+ OPT_CALLBACK(0, "stage", NULL, NULL,
+ "copy out the files from named stage",
+ option_parse_stage),
+ OPT_END()
+ };
git_config(git_default_config, NULL);
state.base_dir = "";
@@ -174,72 +246,13 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
die("invalid cache");
}
- for (i = 1; i < argc; i++) {
- const char *arg = argv[i];
-
- if (!strcmp(arg, "--")) {
- i++;
- break;
- }
- if (!strcmp(arg, "-a") || !strcmp(arg, "--all")) {
- all = 1;
- continue;
- }
- if (!strcmp(arg, "-f") || !strcmp(arg, "--force")) {
- state.force = 1;
- continue;
- }
- if (!strcmp(arg, "-q") || !strcmp(arg, "--quiet")) {
- state.quiet = 1;
- continue;
- }
- if (!strcmp(arg, "-n") || !strcmp(arg, "--no-create")) {
- state.not_new = 1;
- continue;
- }
- if (!strcmp(arg, "-u") || !strcmp(arg, "--index")) {
- state.refresh_cache = 1;
- if (newfd < 0)
- newfd = hold_locked_index(&lock_file, 1);
- continue;
- }
- if (!strcmp(arg, "-z")) {
- line_termination = 0;
- continue;
- }
- if (!strcmp(arg, "--stdin")) {
- if (i != argc - 1)
- die("--stdin must be at the end");
- read_from_stdin = 1;
- i++; /* do not consider arg as a file name */
- break;
- }
- if (!strcmp(arg, "--temp")) {
- to_tempfile = 1;
- continue;
- }
- if (!prefixcmp(arg, "--prefix=")) {
- state.base_dir = arg+9;
- state.base_dir_len = strlen(state.base_dir);
- continue;
- }
- if (!prefixcmp(arg, "--stage=")) {
- if (!strcmp(arg + 8, "all")) {
- to_tempfile = 1;
- checkout_stage = CHECKOUT_ALL;
- } else {
- int ch = arg[8];
- if ('1' <= ch && ch <= '3')
- checkout_stage = arg[8] - '0';
- else
- die("stage should be between 1 and 3 or all");
- }
- continue;
- }
- if (arg[0] == '-')
- usage(checkout_cache_usage);
- break;
- }
+ argc = parse_options(argc, argv, builtin_checkout_index_options,
+ builtin_checkout_index_usage, 0);
+ state.force = force;
+ state.quiet = quiet;
+ state.not_new = not_new;
+ if (argc && read_from_stdin)
+ die("--stdin must be at the end");
if (state.base_dir_len || to_tempfile) {
/* when --prefix is specified we do not
@@ -253,7 +266,7 @@ int cmd_checkout_index(int argc, const char **argv, const char *prefix)
}
/* Check out named files first */
- for ( ; i < argc; i++) {
+ for (i = 0; i < argc; i++) {
const char *arg = argv[i];
const char *p;
--
1.6.0.2
^ permalink raw reply related
* Re: Untracked working tree files
From: Junio C Hamano @ 2008-10-15 22:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, david, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0810151311210.3288@nehalem.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> writes:
> On Wed, 15 Oct 2008, Linus Torvalds wrote:
>>
> It's quite possible that we should remove unmerged entries. Except that's
> not how our internal 'read_cache_unmerged()' function works. It really
> just ignores them, and throws them on the floor. We _could_ try to just
> turn them into a (since) stage-0 entry.
>
> Junio?
I'd agree that dropping unmerged entries to stage-0 when we can would make
sense. An conflicted existing path would get an stage-0 entry in the
index, which is compared with the switched-to HEAD (which could be the
same as the current one when "git reset --hard" is run without a rev), we
notice that they are different and the index entry and the work tree path
is overwritten by the version from the switched-to HEAD. For a new path
that a failed merge tried to bring in, we notice that the switched-to HEAD
does not have that path and happily remove it from the index and from the
work tree. All will go a lot smoother than the current code.
I am not sure what should happen when we can't drop the unmerged entry
down to stage-0 due to D/F conflicts, though. IIRC, read-tree proper
would not touch the work tree in such a case, but merge-recursive creates
our and their versions with funny suffixes, which will not be known to the
index and will be left in the working tree.
^ permalink raw reply
* Re: Super module pointing to submodule branch instead of a specific commit?
From: Avery Pennarun @ 2008-10-15 21:57 UTC (permalink / raw)
To: skillzero; +Cc: git
In-Reply-To: <2729632a0810151416l3a16f6d6x4e32e457d26496bc@mail.gmail.com>
On Wed, Oct 15, 2008 at 5:16 PM, <skillzero@gmail.com> wrote:
> Is there a way to have a super module point to a branch of a submodule
> instead of a specific commit ID?
In some sense, this is too simple to be supported by git-submodule.
You might want to try the "ext" tool instead:
http://nopugs.com/2008/09/06/ext-tutorial
Have fun,
Avery
^ permalink raw reply
* Re: BUG: git rev-list segfaults
From: Nanako Shiraishi @ 2008-10-15 21:22 UTC (permalink / raw)
To: Stephan Springl; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0810152034040.7572@rosenkohl.springl.homeip.net>
Stephan Springl <springl-git@bfw-online.de> writes:
> git rev-list segfaults when crossing a merge commit when given
> --bisect-vars and --first-parent.
This is an old news, isn't it?
http://thread.gmane.org/gmane.comp.version-control.git/93416/focus=93420
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH] Fix mkpath abuse in dwim_ref/sha1_name.c
From: Junio C Hamano @ 2008-10-15 21:22 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List, Shawn O. Pearce
In-Reply-To: <20081015062039.GA3775@blimp.localdomain>
Alex Riesen <raa.lkml@gmail.com> writes:
> Junio C Hamano, Wed, Oct 15, 2008 01:17:52 +0200:
>> "Alex Riesen" <raa.lkml@gmail.com> writes:
>> >
>> > Otherwise the function sometimes fail to resolve obviously correct refnames,
>> > because the string data pointed to by "ref" argument were reused.
>> >
>> But your patch instead rewrites the computation of str2 by bypassing the
>> call to "another_function_that_uses_get_pathname()" and duplicating its
>> logic, which I do not think is a viable approach in the longer term.
>
> There is not enough logic to bypass there. It's just a dumb sprintf!
But didn't you lose call to cleanup_path()?
^ permalink raw reply
* Re: builtin conversion between tabs and spaces
From: Stefan Karpinski @ 2008-10-15 21:18 UTC (permalink / raw)
To: Jonathan del Strother; +Cc: Alex Riesen, Git Mailing List, Johannes Sixt
In-Reply-To: <57518fd10810151402p4ea3283anf4b3d175c4e82425@mail.gmail.com>
>> if you consistently use spaces, then tabs_to_spaces will
>> always give you back your original version; if you consistently use
>> tabs, then spaces_to_tabs will give you back your original version. If
>> you use some crazy mix of the two, you cannot reconstruct your
>> original without remembering where there were tabs versus spaces,
>
> Just IMO, a crazy mix of tabs and spaces is the only _sane_ thing to
> do. Using tabs for the initial indentation, plus spaces for alignment
> of function arguments / comments / whatever, is the only way of
> getting a layout that will both look right regardless of the tab size,
> and allow a viewer to alter the indentation size.
That's not what I would call a "crazy" mix of tabs and spaces, but
rather a *sane* mix of tabs and spaces. That can consistently be
reproduced, and is in fact what the spaces_to_tabs function included
above produces. The sane consistent formats as I see it are:
1) use spaces for everything
2) use tabs for indentation, spaces for everything else
3) use tabs for indentation and alignment
If you know the tab size, you can reproduce any of these from the
others, except that #3 is a little tricky since there's places where
the tab/space issue can be ambiguous. I actually think that keeping
the repo version with tab-based indentation is a very sane thing to
do. However, I'd still like to be able to edit the files using soft
tabs, largely because any program that doesn't know what my tab size
should be applies its own interpretation and makes the code look
terrible (think terminal output for diff, cat, less, etc.)
On the other hand, a *crazy* mix of tabs and spaces is where some
indentation is done with spaces while other indentation is done with
tabs. Even crazier is a single line where the indentation is a mixture
of tabs and spaces. I think that just about everyone can agree that
this is not only crazy, but evil and is the kind of thing one really
wants to avoid in a code base. Unfortunately, when developers disagree
on their standard settings, it's very, very hard to avoid precisely
this kind of mess. My idea is to enable git to prevent this sort of
insanity if configured to do so.
^ permalink raw reply
* Super module pointing to submodule branch instead of a specific commit?
From: skillzero @ 2008-10-15 21:16 UTC (permalink / raw)
To: git
Is there a way to have a super module point to a branch of a submodule
instead of a specific commit ID? I have a repository of common code
I'd like to use with a several different projects (each project has a
repository of its own). I want those super repositories to reference
the "stable" branch of this shared repository so that whenever they
pull one of these super modules, they get any changes made to stable
branch of the shared repository. When creating a tag of the super
module, I still want it to tag based on the commit ID of the submodule
(like I think it does today).
>From what I can tell, I seem to have to commit to the submodule then
commit the new commit ID of the submodule to every super module it is
a member of. That's somewhat tedious, but the larger problem is that
not all everyone with commit access to the submodule will has access
to all the super modules (they may not even know they exist).
^ permalink raw reply
* Re: git-scm.com (was Re: Git graph on GitHub)
From: Aaron Cohen @ 2008-10-15 21:04 UTC (permalink / raw)
To: Garry Dolley; +Cc: PJ Hyett, Wincent Colaiuta, git
In-Reply-To: <20081015201230.GA9534@garry-x300.arpnetworks.com>
On Wed, Oct 15, 2008 at 4:12 PM, Garry Dolley <gdolley@arpnetworks.com> wrote:
> On Wed, Oct 15, 2008 at 11:36:10AM -0700, PJ Hyett wrote:
>> > Coming up in news at 6...
>> >
>> > GitHub announces new maintainer for Git
>> >
>> > GitHub is proud to announce the replacement of the old Git maintainer with
>> > the "Git Core Team", comprising PJ Hyett, Scott Chacon, Tom Preston and some
>> > select personalities from the Ruby on Rails world. You'll be able to track
>> > all the latest updates to "Git Edge" over at GitHub. The former maintainer,
>> > Junio C Hamano, is being retired from service because the Git community (see
>> > git-scm.com) decided he wasn't as good-looking as David Heinemeier Hanson.
>> > For more information, see the official Git book (book.git-scm.com).
>>
>> In case there was any confusion, this is why we almost never bother
>> posting to the list, because no matter what the topic, it always turns
>> into why the git community hates GitHub.
>
> For the record, I'm a part of the git community and I like GitHub
> quite a bit. :)
>
For the record, I'm not part of either community and find things to
dislike about both of them.
git.or.cz: I personally prefer its plain style, but it has way too
much information on the front page (why is so much download
information on that page rather than hidden behind the "download" link
that currently just goes to an ftp directory?)
git-scm.com: Much better organized, but suffers from web 2.0
shininess. Also, every time I look at it my eyes have to read
EVERYTHING to figure out what ANYTHING is. For instance, why is there
that random column of "projects using git" that seems to only exist to
distract me from the important stuff?
^ permalink raw reply
* Re: builtin conversion between tabs and spaces
From: Jonathan del Strother @ 2008-10-15 21:02 UTC (permalink / raw)
To: Stefan Karpinski; +Cc: Alex Riesen, Git Mailing List
In-Reply-To: <d4bc1a2a0810151352s6c963e32jc4f492a7c84841dc@mail.gmail.com>
On Wed, Oct 15, 2008 at 9:52 PM, Stefan Karpinski
<stefan.karpinski@gmail.com> wrote:
> if you consistently use spaces, then tabs_to_spaces will
> always give you back your original version; if you consistently use
> tabs, then spaces_to_tabs will give you back your original version. If
> you use some crazy mix of the two, you cannot reconstruct your
> original without remembering where there were tabs versus spaces,
Just IMO, a crazy mix of tabs and spaces is the only _sane_ thing to
do. Using tabs for the initial indentation, plus spaces for alignment
of function arguments / comments / whatever, is the only way of
getting a layout that will both look right regardless of the tab size,
and allow a viewer to alter the indentation size.
^ permalink raw reply
* Re: builtin conversion between tabs and spaces
From: Stefan Karpinski @ 2008-10-15 20:55 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Git Mailing List
In-Reply-To: <48F58D1C.2040208@viscovery.net>
>> This led me to wonder if it wouldn't make sense to have this
>> conversion ability built into git.
>
> This wouldn't help your case a lot. It is still at the discretion of each
> individual repository owner to enable the conversion. (You didn't mean to
> make this conversion mandatory, did you?)
This would all be completely discretionary, of course. I just thought
that the issue was complicated enough and the problem of mixed spaces
and tabs in source code ubiquitous enough that it might be worth
"solving" correctly in git itself.
> BTW, you don't need to change git code to achieve this. It's sufficient to
> install a suitable "clean" filter:
>
> echo "*.c filter=c-code" > .git/info/attributes
> git config filter.c-code.clean tabs2spaces
>
> where tabs2spaces is your utility that does the conversion.
That was the first thing I did—in ruby first, then in C. The ruby
version is *way* too slow to use on any number of files—and the
typical use case is that most of your files are source code and so
will have this applied to them. On the other hand, the ruby script (or
perl or whatever) is portable, so I can send it to my Windows-based
developers and have them use it too.
But the speed issue is pretty crucial, so I rewrote the thing as an
external C program, which is obviously much faster. But it's still
noticably slower than native git checkout though. Worse still, now the
filter script isn't portable, so I have to cross-compile it and give
every developer the version that works on their platform and make sure
that they have their path setup correctly, etc.
Having the conversion built into git would
1) have native git checkout speed (I've tried it and it's not
noticable slower than normal git checkouts);
2) be naturally portable to anywhere git works.
Now, if I thought this was a thing that would only benefit me, I would
never bring it up. However, it seems like something that a lot of
projects might want to use to ensure standard spacing in their source
files. Moreover, since developers feel strongly about using tabs or
spaces, it would be beneficial for individuals too. I think there's
enough complex issues that solving it once-and-for-all might be worth
a shot.
^ permalink raw reply
* Re: builtin conversion between tabs and spaces
From: Stefan Karpinski @ 2008-10-15 20:52 UTC (permalink / raw)
To: Alex Riesen; +Cc: Git Mailing List
In-Reply-To: <20081015062539.GB3775@blimp.localdomain>
> Is your conversion two-way? IOW, is it possible to convert the
> converted file and get the original? (Because all the existing
> conversions are reversible)
Yes and no. The CRLF conversion isn't always invertable—it is so long
as your use of CRLF/LF is consistent. The tab/space conversion is
similar: if you consistently use spaces, then tabs_to_spaces will
always give you back your original version; if you consistently use
tabs, then spaces_to_tabs will give you back your original version. If
you use some crazy mix of the two, you cannot reconstruct your
original without remembering where there were tabs versus spaces,
which information either filter destroys. But that's the same as the
CRLF conversion. You could enable a warning when worktree file has an
inconsistent mixture of tabs and spaces, like there is for
inconsistent CRLF files.
On Tue, Oct 14, 2008 at 11:25 PM, Alex Riesen <raa.lkml@gmail.com> wrote:
> Stefan Karpinski, Wed, Oct 15, 2008 03:44:10 +0200:
>> I find myself really wanting to enforce standards in the use of spaces
>> versus tabs. I deal with some unruly programmers who refuse to set
>> their editors to use soft tabs, but I *hate* tabs in the repo. And of
>> course others feel equally strongly about keeping only tabs in the
>> repo (e.g. the git repo).
>>
>> This led me to wonder if it wouldn't make sense to have this
>> conversion ability built into git. The following patch implements this
>> functionality. It still needs work—it's not meant to be final, just to
>> give an idea—but I just wanted to see if people on the git list
>> thought this sort of thing would be worthwhile at all.
>
> Is your conversion two-way? IOW, is it possible to convert the
> converted file and get the original? (Because all the existing
> conversions are reversible)
>
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Shawn O. Pearce @ 2008-10-15 20:36 UTC (permalink / raw)
To: Junio C Hamano
Cc: Brandon Casey, git, Arjen Laarhoven, Jeff King, Mike Ralphson
In-Reply-To: <7vhc7dr4f8.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> >> If we can add a test case to demonstrate the existing breakage, I think we
> >> can (and should) cherry-pick it to 'maint'.
> >
> > Yes, it probably should have gone to maint. No, it didn't go there.
> > Temporary lapse in maintainer judgement.
>
> That is Ok. I do the same all the time (and I try to rewind and rebuild
> when I spot it before pushing the results out, but I am not always
> successful).
Oh, trust me, I had many times where I had to rebuild everything
for that day's push because I forgot about a patch that should
be in maint. At least your Meta/RB and Meta/PU scripts make it
somewhat painless, that and Git's ability to just hard reset a
branch back to what I last published. ;-)
I just utterly failed to do it that morning. Or at least failed
to do it for this change.
> I just wanted to see if there was any particular reason not to have this
> on 'maint'.
Nope.
--
Shawn.
^ permalink raw reply
* Re: BUG: git rev-list segfaults
From: Avery Pennarun @ 2008-10-15 20:32 UTC (permalink / raw)
To: Stephan Springl; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0810152034040.7572@rosenkohl.springl.homeip.net>
On Wed, Oct 15, 2008 at 3:00 PM, Stephan Springl
<springl-git@bfw-online.de> wrote:
> git rev-list segfaults when crossing a merge commit when given --bisect-vars
> and --first-parent. This is on branches master, next, and pu from
> git://git.kernel.org/pub/scm/git/git.git right now.
See this thread:
http://kerneltrap.org/mailarchive/git/2008/8/23/3050004
Unfortunately I worked around the crash in the scripts I was working
on, and I have since been sidetracked, so I haven't been able to test
Junio's fix. It's still on my ever-growing to-do list. If you try it
and it works for you, please let him know.
Thanks,
Avery
^ permalink raw reply
* Re: Untracked working tree files
From: Andrew Morton @ 2008-10-15 20:30 UTC (permalink / raw)
To: Linus Torvalds; +Cc: david, git, gitster
In-Reply-To: <alpine.LFD.2.00.0810151311210.3288@nehalem.linux-foundation.org>
On Wed, 15 Oct 2008 13:23:50 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 15 Oct 2008, Linus Torvalds wrote:
> >
> > - a merge goes south with a data conflict, and since it's all automated,
> > you just want to throw it away.
>
> Actually, with your filename, I suspect the conflict would be not a real
> file content, but more of a "delete" conflicting with a modification to
> that file. IOW, I'm guessing that the thing you hit with
> arch/x86/kernel/apic.c was that some branch you pulled:
>
> - created that file
>
> - deleted arch/x86/kernel/apic_[32|64].c
>
> - the old file got marked as a rename source for the new apic.c and
> there was a data conflict when trying to apply the changes.
>
> as a result, your working tree would have that "apic.c" file in it, but
> with conflict markers, and marked as unmerged.
That sounds likely. I suspect things were especially bad today because
I accidentally pulled four-week-old linux-next, which had over 500
rejects in it.
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Junio C Hamano @ 2008-10-15 20:26 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Brandon Casey, git, Arjen Laarhoven, Jeff King, Mike Ralphson
In-Reply-To: <20081015202032.GD28802@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
>> If we can add a test case to demonstrate the existing breakage, I think we
>> can (and should) cherry-pick it to 'maint'.
>
> Yes, it probably should have gone to maint. No, it didn't go there.
> Temporary lapse in maintainer judgement.
That is Ok. I do the same all the time (and I try to rewind and rebuild
when I spot it before pushing the results out, but I am not always
successful).
I just wanted to see if there was any particular reason not to have this
on 'maint'.
Thanks.
^ permalink raw reply
* Re: Untracked working tree files
From: Linus Torvalds @ 2008-10-15 20:23 UTC (permalink / raw)
To: Andrew Morton; +Cc: david, Git Mailing List, Junio C Hamano
In-Reply-To: <alpine.LFD.2.00.0810151256410.3288@nehalem.linux-foundation.org>
On Wed, 15 Oct 2008, Linus Torvalds wrote:
>
> - a merge goes south with a data conflict, and since it's all automated,
> you just want to throw it away.
Actually, with your filename, I suspect the conflict would be not a real
file content, but more of a "delete" conflicting with a modification to
that file. IOW, I'm guessing that the thing you hit with
arch/x86/kernel/apic.c was that some branch you pulled:
- created that file
- deleted arch/x86/kernel/apic_[32|64].c
- the old file got marked as a rename source for the new apic.c and
there was a data conflict when trying to apply the changes.
as a result, your working tree would have that "apic.c" file in it, but
with conflict markers, and marked as unmerged.
When you then do "git reset --hard", it will just ignore unmerged entries,
and since the original tree (and the destination tree) match, and neither
of them contain apic.c either, git will totally ignore that file and not
even try to remove it (since it wasn't there originally).
> So you do "git reset --force" to do that.
It's "--hard", not "--force". Yeah, the git reset flags are insane. As is
the default action, for that matter. It's one of the earliest interfaces,
and it's stupid and reflects git internal implementations rather than what
we ended up learning about using git later. Oh, well.
But 'git checkout -f' (which is nicer from a user interface standpoint)
has the exact same logic and I think shares all the implementation. I
think they both end up just calling "git read-tree --reset -u".
It's quite possible that we should remove unmerged entries. Except that's
not how our internal 'read_cache_unmerged()' function works. It really
just ignores them, and throws them on the floor. We _could_ try to just
turn them into a (since) stage-0 entry.
Junio?
Linus
^ permalink raw reply
* Re: Untracked working tree files
From: Andrew Morton @ 2008-10-15 20:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: david, git
In-Reply-To: <alpine.LFD.2.00.0810151256410.3288@nehalem.linux-foundation.org>
On Wed, 15 Oct 2008 13:08:36 -0700 (PDT)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Wed, 15 Oct 2008, Andrew Morton wrote:
> >
> > I treat my git directory as a read-only thing. I only ever modify it
> > with git commands.
>
> Ok.
>
> > > (By the filename, I realize it's a file that doesn't exist in one tree or
> > > the other, and which doesn't get removed at some point. But have you had
> > > merge failures, for example? Is it perhaps a file that was created during
> > > a non-clean merge, and then got left behind due to the merge being
> > > aborted? It would be interesting to know what led up to this..)
> >
> > That's certainly a possibility - I get a lot of merge failures. A real
> > lot. And then quite a bit of rebasing goes on, especially in
> > linux-next. And then there's all the other stuff which Stephen does on
> > top of the underlying trees to get something releasable happening.
>
> Is "git checkout -f" part of the scripting? Or "git reset --hard"?
well, this script has been hacked on so many times I'm not sure what
it does any more.
Presently the main generate-a-diff function is
doit()
{
tree=$1
upstream=$2
cd $GIT_TREE
git checkout "$upstream"
git reset --hard "$upstream"
git fetch "$tree" || exit 1
git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null
{
git_header "$tree"
git log --no-merges ORIG_HEAD..FETCH_HEAD
git diff --patch-with-stat ORIG_HEAD
} >$PULL/$tree.patch
{
echo DESC
echo $tree.patch
echo EDESC
git_header "$tree"
git log --no-merges ORIG_HEAD..FETCH_HEAD
} >$PULL/$tree.txt
git reset --hard "$upstream"
}
usually invoked as
doit origin v2.6.27
doit origin linux-next
etc.
the above seemed fairly busted, so I'm now using
git checkout -f "$upstream"
git reset --hard "$upstream"
git fetch "$tree" || exit 1
which seems a bit more sensible. Perhaps I should do the reset before
the checkout, dunno.
That function has been through sooooooo many revisions and each time
some scenario get fixed (more like "improved"), some other scenario
gets busted (more like "worsened"). The above sorta mostly works,
although it presently generates thirty-odd rejects against
git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-tip.git#auto-latest,
which is way above my fix-it-manually threshold. linux-next is still
dead because it's taking Stephen over two days to fix the mess he's
been fed so I'm madly rebasing everything on mainline over here.
> So what I could imagine is happening is:
>
> - you have a lot of automated merging
>
> - a merge goes south with a data conflict, and since it's all automated,
> you just want to throw it away. So you do "git reset --force" to do
> that.
didn't know about --force.
> - but what "git reset --hard" means is to basically ignore all error
> cases, including any unmerged entries that it just basically ignores.
>
> - so it did set the tree back, but the whole point of "--hard" is that it
> ignores error cases, and doesn't really touch them.
>
> Now, I don't think we ever really deeply thought about what the error
> cases should do when they are ignored. Should the file that is in some
> state we don't like be removed? Or should we just ignore the error and
> return without removing the file? Generally git tries to avoid touching
> things it doesn't understand, but I do think this may explain some pain
> for you, and it may not be the right thing in this case.
Yeah, there's no easy solution here, and I suspect the real solution is
"read programmer's mind". Providing a reliable override (like -f) is a
sensible solution.
> (And when I say "this case", I don't really know whether you use "git
> checkout -f" or "git reset --hard" or something else, so I'm not even
> going to say I'm sure exactly _which_ case "this case" actually us :)
>
> Of course, the cheesy way for you to fix this may be to just add a
>
> git clean -dqfx
>
> to directly after whatever point where you decide to reset and revert to
> an earlier stage. That just says "force remove all files I don't know
> about, including any I might ignore". IOW, "git reset --hard" will
> guarantee that all _tracked_ files are reset, but if you worry about some
> other crud that could have happened due to a failed merge, that additional
> "git clean" may be called for.
OK, I'll try git clean -dqfx if it blows up again.
> Of course, it's going to read the whole directory tree and that's not
> really cheap, but especially if you only do this for error cases, it's
> probably not going to be any worse. And I'm assuming you're not compiling
> in that tree, so you probably don't want to save object files (you can
> remove the "x" part, but then you could still at least in theory get a
> filename clash with something that is ignored and thus didn't get cleaned
> up).
^ permalink raw reply
* BUG: git rev-list segfaults
From: Stephan Springl @ 2008-10-15 19:00 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1321 bytes --]
Hi,
git rev-list segfaults when crossing a merge commit when given
--bisect-vars and --first-parent. This is on branches master, next, and
pu from git://git.kernel.org/pub/scm/git/git.git right now.
Reproduce it using git's git repository like this:
git rev-list --bisect-vars --first-parent \
80bfd76af7ac817d4a4b9b7d54485..67faaaba8338cf59c212ce5239eeb
Without either --first-parent or --bisect-vars it works.
Thank you for your work on git. When we introduced CVS in our development
some ten years ago, after a few weeks we could not imagine how we could
have got any work done without it. When we started using git, we found
this former step was tiny compared to the increase in productivity we
experienced switching from CVS to git.
Regards
Stephan
--
Stephan Springl BFW Werner Völk GmbH
Energiemesstechnik & Service
Drosselgasse 5
D-82166 Gräfelfing
Germany
Geschäftsführer: Georg F. Völk
HRB 44779 Amtsgericht München
USt.-ID: DE129301566
^ permalink raw reply
* Re: What's in git.git (Oct 2008, #03; Tue, 14)
From: Shawn O. Pearce @ 2008-10-15 20:20 UTC (permalink / raw)
To: Junio C Hamano
Cc: Brandon Casey, git, Arjen Laarhoven, Jeff King, Mike Ralphson
In-Reply-To: <7vljwpr6lr.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Brandon Casey <casey@nrlssc.navy.mil> writes:
>
> > Two questions:
> >
> > 1) Should a5a5a048 be in maint?
> > "xdiff-interface.c: strip newline (and cr) from line before pattern matching"
>
> I would have forked a maint-fix topic to prepare a merge of this fix to
> both 'maint' and 'master' but apparently this was applied directly on
> 'master'. I may be missing a valid reason why Shawn did it this way.
My fault. I didn't have a reason for putting it on master.
My reason really boiled down to "I can't decide where this goes,
oops, got distracted by something, git checkout master, git am,
move on...".
Yes, it probably should have gone to maint. No, it didn't go there.
Temporary lapse in maintainer judgement.
> If we can add a test case to demonstrate the existing breakage, I think we
> can (and should) cherry-pick it to 'maint'.
Probably. Sorry for the cherry-pick being required here.
--
Shawn.
^ permalink raw reply
* Re: Untracked working tree files
From: david @ 2008-10-15 20:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andrew Morton, git
In-Reply-To: <alpine.LFD.2.00.0810151247560.3288@nehalem.linux-foundation.org>
On Wed, 15 Oct 2008, Linus Torvalds wrote:
> On Wed, 15 Oct 2008, david@lang.hm wrote:
>>
>> I see it fairly frequently when switching between different branches of a
>> project.
>
> So, at least for any normal switch, assuming file 'a' doesn't exist in the
> other branch, you really should have a few different cases:
>
> - you have a dirty file, and git should say something like
>
> error: You have local changes to 'file'; cannot switch branches.
>
> because it refuses to modify the file to match the other branch (which
> includes removing it) if it doesn't match the index.
>
> So this case shouldn't leave anything behind.
>
> - You have that extra file, but it's not in the index.
>
> If it's in your current HEAD, we should still notice it with something
> like:
>
> error: Untracked working tree file 'tree' would be removed by merge.
>
> because now it's untracked (not in the index), but the switching
> between branches tries to essentially "apply" the difference between
> your current HEAD and the new branch, and finds that the difference
> involves removing a file that git isn't tracking.
one place that I know I've run into it frequently is in an internal
project that I did not properly setup .gitignore and did "git add ." and
"git commit -a" to. that projects repository contains the compiled
binaries and I frequently get these errors when switching trees.
that sounds like the first case.
I've seen discussion of a new sequencer functionality, would it allow me
to define a .gitignore file and re-create the repository as if that file
had existed all along?
David Lang
> See?
>
> HOWEVER.
>
> If you're used to doing "git checkout -f" or "git reset --hard", both of
> those checks are just ignored. After all, you asked for a forced switch.
>
> And at least in the second case, what I think happens is that git won't
> remove the file it doesn't know about, so you'll have a "turd" left
> around.
>
> So yes, you can certainly get these kinds of left-overs, but they really
> should be only happening if you "force" something. Do you do that often?
>
> Linus
>
^ 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