* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Björn Steinbrink @ 2008-11-02 18:54 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Johannes Schindelin, David Symonds, git, Stephan Beyer
In-Reply-To: <7vljw2yo93.fsf@gitster.siamese.dyndns.org>
On 2008.11.02 10:30:16 -0800, Junio C Hamano wrote:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
> > Looking at --cached/--index we have basically three things:
> >
> > --cached to refer to the state of the index (diff, grep, [stash], ...)
> > --cached to _work on_ the index only (rm, apply, ...)
> > --index to _work on_ both the index and the working tree (apply, ...)
>
> I think the earlier two are the same thing. The only difference between
> them is that in the first one, the definition of your "work on" happens to
> be a read-only operation. Am I mistaken?
Yeah, I actually wanted to change that "work on" to a simple "change",
but forgot to do that before sending... :-(
The idea was that currently "--cached" can be "passive" (just look at
the index instead of the working tree) or "active" (change the index
instead of the working tree). Thus there could be three "flag words",
and their usage can be unified, including stash.
"git diff [my] --staged [changes]"
"git stash [but] --keep-staged [changes]"
"git apply [and] --stage my_patch"
"git rm [but] --stage-only some_file"
OK, the last one is still not even close to a proper sentence, and but I
guess you get the idea ;-)
> > A quick look through Documentation/ revealed only one problematic case,
> > which is ls-files that already has a --stage option. And that looks like
> > a dealbreaker :-(
>
> 'ls-files' is primarily about the index contents and all else is a fluff
> ;-)
>
> You could say --show-stage-too if you wanted to, but the command is a
> plumbing to begin with, so perhaps if we can identify the cases where
> people need to use the command and enhance some Porcelain (likely
> candidate is 'status' or perhaps 'status --short') to give the information
> people use ls-files for, we hopefully wouldn't have to change ls-files
> itself at all.
>
> The only case I use ls-files these days when I am _using_ git (as opposed
> to developing/debugging git) is "git ls-files -u" to get the list of still
> unmerged paths during a conflicted merge.
Heh, that's probably the one thing for which I use "git status" the
most.
Björn
^ permalink raw reply
* [PATCH] Document that git-log takes --all-match.
From: Mikael Magnusson @ 2008-11-02 18:32 UTC (permalink / raw)
To: Git Mailing List, Junio C Hamano
In-Reply-To: <237967ef0811021028w3aa22411t99b2203a9148bbf6@mail.gmail.com>
Signed-off-by: Mikael Magnusson <mikachu@gmail.com>
---
It's already listed in the bash completion. Feel free to reword.
Looking at this I can't help but feel that the text for
--grep/--author/--committer is misleading, since they say they will
limit to commits blabla, but they don't if another is given. Ie they
only do what they say if you give the --all-match option.
Documentation/rev-list-options.txt | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
index 0ce916a..966276b 100644
--- a/Documentation/rev-list-options.txt
+++ b/Documentation/rev-list-options.txt
@@ -174,6 +174,10 @@ endif::git-rev-list[]
Limit the commits output to ones with log message that
matches the specified pattern (regular expression).
+--all-match::
+ Limit the commits output to ones that match all given --grep,
+ --author and --committer instead of ones that match at least one.
+
-i::
--regexp-ignore-case::
--
1.6.0.2.GIT
--
Mikael Magnusson
^ permalink raw reply related
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Junio C Hamano @ 2008-11-02 18:30 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Jeff King, Johannes Schindelin, David Symonds, git, gitster,
Stephan Beyer
In-Reply-To: <20081102123519.GA21251@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Looking at --cached/--index we have basically three things:
>
> --cached to refer to the state of the index (diff, grep, [stash], ...)
> --cached to _work on_ the index only (rm, apply, ...)
> --index to _work on_ both the index and the working tree (apply, ...)
I think the earlier two are the same thing. The only difference between
them is that in the first one, the definition of your "work on" happens to
be a read-only operation. Am I mistaken?
> A quick look through Documentation/ revealed only one problematic case,
> which is ls-files that already has a --stage option. And that looks like
> a dealbreaker :-(
'ls-files' is primarily about the index contents and all else is a fluff
;-)
You could say --show-stage-too if you wanted to, but the command is a
plumbing to begin with, so perhaps if we can identify the cases where
people need to use the command and enhance some Porcelain (likely
candidate is 'status' or perhaps 'status --short') to give the information
people use ls-files for, we hopefully wouldn't have to change ls-files
itself at all.
The only case I use ls-files these days when I am _using_ git (as opposed
to developing/debugging git) is "git ls-files -u" to get the list of still
unmerged paths during a conflicted merge.
^ permalink raw reply
* Re: [PATCH] git send-email: allow any rev-list option as an argument.
From: Jeff King @ 2008-11-02 18:02 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20081102093907.GF4066@artemis>
On Sun, Nov 02, 2008 at 10:39:07AM +0100, Pierre Habouzit wrote:
> Well it still messes the file/reference name conflict with no way to
> prevent it because of the backward compatibility, and even if unlikely
> it's still possible.
Hmm. As Junio mentioned, this is really an easier way of doing:
git format-patch -o tmp "$@"
$EDITOR tmp/*
git send-email tmp
So I guess a wrapper program would suffice, that just called send-email.
But of course then you would have to think of a new name, and explain
the confusion between it and send-email.
-Peff
^ permalink raw reply
* [PATCH] Makefile: add install-man rules (quick and normal)
From: Markus Heidelberg @ 2008-11-02 17:53 UTC (permalink / raw)
To: gitster; +Cc: git
---
Documentation/Makefile | 8 ++++++--
INSTALL | 5 +++--
Makefile | 6 ++++++
3 files changed, 15 insertions(+), 4 deletions(-)
diff --git a/Documentation/Makefile b/Documentation/Makefile
index e33ddcb..c34c1ca 100644
--- a/Documentation/Makefile
+++ b/Documentation/Makefile
@@ -87,7 +87,9 @@ man7: $(DOC_MAN7)
info: git.info gitman.info
-install: man
+install: install-man
+
+install-man: man
$(INSTALL) -d -m 755 $(DESTDIR)$(man1dir)
$(INSTALL) -d -m 755 $(DESTDIR)$(man5dir)
$(INSTALL) -d -m 755 $(DESTDIR)$(man7dir)
@@ -220,7 +222,9 @@ $(patsubst %.txt,%.html,$(wildcard howto/*.txt)): %.html : %.txt
install-webdoc : html
sh ./install-webdoc.sh $(WEBDOC_DEST)
-quick-install:
+quick-install: quick-install-man
+
+quick-install-man:
sh ./install-doc-quick.sh $(DOC_REF) $(DESTDIR)$(mandir)
quick-install-html:
diff --git a/INSTALL b/INSTALL
index a4fd862..d1deb0b 100644
--- a/INSTALL
+++ b/INSTALL
@@ -126,8 +126,9 @@ Issues of note:
http://www.kernel.org/pub/software/scm/git/docs/
- There are also "make quick-install-doc" and "make quick-install-html"
- which install preformatted man pages and html documentation.
+ There are also "make quick-install-doc", "make quick-install-man"
+ and "make quick-install-html" which install preformatted man pages
+ and html documentation.
This does not require asciidoc/xmlto, but it only works from within
a cloned checkout of git.git with these two extra branches, and will
not work for the maintainer for obvious chicken-and-egg reasons.
diff --git a/Makefile b/Makefile
index 4b54416..cc7959e 100644
--- a/Makefile
+++ b/Makefile
@@ -1411,6 +1411,9 @@ endif
install-doc:
$(MAKE) -C Documentation install
+install-man:
+ $(MAKE) -C Documentation install-man
+
install-html:
$(MAKE) -C Documentation install-html
@@ -1420,6 +1423,9 @@ install-info:
quick-install-doc:
$(MAKE) -C Documentation quick-install
+quick-install-man:
+ $(MAKE) -C Documentation quick-install-man
+
quick-install-html:
$(MAKE) -C Documentation quick-install-html
--
1.6.0.3.536.gb5136
^ permalink raw reply related
* [PATCH (MINGW) Resend] Windows: Make OpenSSH properly detect tty detachment.
From: Alexander Gavrilov @ 2008-11-02 17:11 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Johannes Sixt
Apparently, CREATE_NO_WINDOW makes the OS tell the process
that it has a console, but without actually creating the
window. As a result, when git is started from GUI, ssh
tries to ask its questions on the invisible console.
This patch uses DETACHED_PROCESS instead, which clearly
means that the process should be left without a console.
The downside is that if the process manually calls
AllocConsole, the window will appear. A similar thing
might occur if it calls another console executable.
Signed-off-by: Alexander Gavrilov <angavrilov@gmail.com>
Acked-by: Johannes Sixt <johannes.sixt@telecom.at>
---
This patch appears to have been overlooked, so I resend
it just in case. It fixes a long standing problem in msysgit.
-- Alexander
compat/mingw.c | 8 ++++++--
1 files changed, 6 insertions(+), 2 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 1e29b88..b6fcf69 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -586,12 +586,16 @@ static pid_t mingw_spawnve(const char *cmd, const char **argv, char **env,
* would normally create a console window. But
* since we'll be redirecting std streams, we do
* not need the console.
+ * It is necessary to use DETACHED_PROCESS
+ * instead of CREATE_NO_WINDOW to make ssh
+ * recognize that it has no console.
*/
- flags = CREATE_NO_WINDOW;
+ flags = DETACHED_PROCESS;
} else {
/* There is already a console. If we specified
- * CREATE_NO_WINDOW here, too, Windows would
+ * DETACHED_PROCESS here, too, Windows would
* disassociate the child from the console.
+ * The same is true for CREATE_NO_WINDOW.
* Go figure!
*/
flags = 0;
--
1.6.0.2.1256.ga12f0
^ permalink raw reply related
* Re: [PATCH 1/7] Documentation: do not use regexp in refspec descriptions
From: Anders Melchiorsen @ 2008-11-02 17:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7i7pba2x.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Anders Melchiorsen <mail@cup.kalibalik.dk> writes:
>
>> The syntax is now easier to read, though wrong: all parts of the
>> refspec are actually optional.
>
> It probably is easier to read, but strictly speaking it is not
> wrong. The two parts, <src> and <dst>, _always_ exist, even though
> either or both of them can be an empty string.
The colon is not required, though the format suggests that it is.
>> <refspec>...::
>> The canonical format of a <refspec> parameter is
>> - `+?<src>:<dst>`; that is, an optional plus `{plus}`, followed
>> + `[+]<src>:<dst>`; that is, an optional plus `{plus}`, followed
>> by the source ref, followed by a colon `:`, followed by
>> the destination ref.
>
> I am wondering if it would be clearer and easier to understand if we just
> said:
>
> The canonical format of a <refspec> parameter is
> an optional plus `{plus}`, followed by the source ref,
> followed by a colon `:`, followed by the destination ref.
> Find various forms of refspecs in examples section.
I think that is an improvement. Removing the word "canonical" would be
even better, IMHO.
Anders.
^ permalink raw reply
* Re: commit takes 8 secs; but instant when offline - can I fix this?
From: Brendan Macmillan @ 2008-11-02 16:34 UTC (permalink / raw)
To: Thomas Rast; +Cc: git
In-Reply-To: <200811021514.00057.trast@student.ethz.ch>
Many thanks for the explanation, and it's now instant.
To ~/.gitconfig, I added:
[user]
email = myemail@address.com
On 03/11/2008, Thomas Rast <trast@student.ethz.ch> wrote:
> 13ren wrote:
> > With the network plugged in, git-commit takes 8 seconds.
> >
> > When I unplug the network, commit is instant...
>
> Configure your user.email (and user.name), see man git-config. If the
> email is not set, Git tries to figure out your hostname, which
> depending on DNS misconfigurations can apparently cause such delays.
^ permalink raw reply
* .gitattributes glob matching broken
From: Hannu Koivisto @ 2008-11-02 16:33 UTC (permalink / raw)
To: git
Greetings,
It seems that, for example, glob pattern *.s matches files with .sh
extension at least with checkout and reset --hard but git status
thinks otherwise:
mkdir test
cd test
git init
echo -e "*.sh -crlf\n*.s crlf" > .gitattributes
echo -e "foobar\nfoobar\nfoobar" > kala.s
echo -e "foobar\nfoobar\nfoobar" > kala.sh
git add .gitattributes kala.s kala.sh
git commit -m "Foo."
cd ..
git clone -n test test2
cd test2
git config core.autocrlf true
git checkout
git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working
# directory)
#
# modified: kala.sh
#
no changes added to commit (use "git add" and/or "git commit -a")
file kala.s kala.sh
kala.s: ASCII text, with CRLF line terminators
kala.sh: ASCII text, with CRLF line terminators
Tested in Linux with git 1.6.0.3.535.g933bb (master as of this
writing) but also witnessed in Windows and with slightly older
git versions.
This makes git use in a Windows environment pretty much impossible
if you don't want to / can't rely on git guessing "text"
vs. "binary" files correctly so I hope a solution is found soon.
It would also be good to document what kind of glob patterns git
actually supports. I made the assumption that at least on Linux it
supports whatever glob(7) says but even if that assumption is
correct (which it may not be, of course) for example Windows users
may not realize to look for such a manual page.
--
Hannu
^ permalink raw reply
* [PATCH 3/3] pack-objects: honor '.keep' files
From: drafnel @ 2008-11-02 16:31 UTC (permalink / raw)
To: git; +Cc: gitster, nico, spearce, Brandon Casey
In-Reply-To: <1225643477-32319-2-git-send-email-foo@foo.com>
From: Brandon Casey <drafnel@gmail.com>
By default, pack-objects creates a pack file with every object specified by
the user. There are two options which can be used to exclude objects which
are accessible by the repository.
1) --incremental
This excludes any object which already exists in an accessible pack.
2) --local
This excludes any object which exists in a non-local pack.
With this patch, both arguments also cause objects which exist in packs
marked with a .keep file to be excluded. Only the --local option requires
an explicit check for the .keep file. If the user doesn't want the objects
in a pack marked with .keep to be exclude, then the .keep file should be
removed.
Additionally, this fixes the repack bug which allowed porcelain repack to
create packs which contained objects already contained in existing packs
marked with a .keep file.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
This seems to be the correct fix.
I thought about two alternatives:
1) New option to pack-objects which causes it to honor .keep files
I didn't think this was necessary since that is why we have .keep
files in the first place.
So, now there are three variants:
Neither --incremental or --local is used)
Ignore repo packs, pack is created using all objects specified by
user.
--incremental is used)
Look at repo packs, exclude already packed objects (including those
marked with .keep file)
--local is used)
Look at repo packs, exclude objects in non-local packs (including local
objects marked with .keep file)
2) Always honor .keep files, even when --incremental or --local is
not specified.
I think this may be counter-intuitive, since if you specify all of
the objects explicitly, without using any other options, you expect
all of those objects to be placed into the created pack file. If
.keep is always honored, then a new option would be required to
indicate ignoring .keep files, or we would adopt the platform that
"the user must just remove the .keep file".
So, honoring .keep files only with --incremental (which is a side effect) or
--local seems to be the most appropriate.
Comments welcome.
-brandon
builtin-pack-objects.c | 2 +-
t/t7700-repack.sh | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 6a8b9bf..5199e54 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -701,7 +701,7 @@ static int add_object_entry(const unsigned char *sha1, enum object_type type,
break;
if (incremental)
return 0;
- if (local && !ispacklocal(p))
+ if (local && (!ispacklocal(p) || haspackkeep(p)))
return 0;
}
}
diff --git a/t/t7700-repack.sh b/t/t7700-repack.sh
index 1489e68..b6b02da 100755
--- a/t/t7700-repack.sh
+++ b/t/t7700-repack.sh
@@ -4,7 +4,7 @@ test_description='git repack works correctly'
. ./test-lib.sh
-test_expect_failure 'objects in packs marked .keep are not repacked' '
+test_expect_success 'objects in packs marked .keep are not repacked' '
echo content1 > file1 &&
echo content2 > file2 &&
git add . &&
--
1.6.0.2.588.g3102
^ permalink raw reply related
* [PATCH 2/3] packed_git: add new PACK_KEEP flag and haspackkeep() access macro
From: drafnel @ 2008-11-02 16:31 UTC (permalink / raw)
To: git; +Cc: gitster, nico, spearce, Brandon Casey
In-Reply-To: <1225643477-32319-1-git-send-email-foo@foo.com>
From: Brandon Casey <drafnel@gmail.com>
If you want to tell whether a pack has an associated ".keep" file you
would do:
if (haspackkeep(p))
do_something
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
cache.h | 2 ++
sha1_file.c | 5 +++++
2 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/cache.h b/cache.h
index 0cb9350..48cd366 100644
--- a/cache.h
+++ b/cache.h
@@ -686,7 +686,9 @@ extern struct packed_git {
} *packed_git;
#define PACK_LOCAL 1
+#define PACK_KEEP 2
#define ispacklocal(p) ((p)->flags & PACK_LOCAL)
+#define haspackkeep(p) ((p)->flags & PACK_KEEP)
struct pack_entry {
off_t offset;
diff --git a/sha1_file.c b/sha1_file.c
index e4141c9..8a027e9 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -841,6 +841,11 @@ struct packed_git *add_packed_git(const char *path, int path_len, int local)
return NULL;
}
memcpy(p->pack_name, path, path_len);
+
+ strcpy(p->pack_name + path_len, ".keep");
+ if (!access(p->pack_name, F_OK))
+ p->flags |= PACK_KEEP;
+
strcpy(p->pack_name + path_len, ".pack");
if (stat(p->pack_name, &st) || !S_ISREG(st.st_mode)) {
free(p);
--
1.6.0.2.588.g3102
^ permalink raw reply related
* [PATCH 1/3] packed_git: convert pack_local flag into generic bit mask
From: drafnel @ 2008-11-02 16:31 UTC (permalink / raw)
To: git; +Cc: gitster, nico, spearce, Brandon Casey
In-Reply-To: <14536526.1225596838300.JavaMail.teamon@b301.teamon.com>
From: Brandon Casey <drafnel@gmail.com>
This converts the pack_local flag of the packed_git structure into a generic
bit mask and introduces a PACK_LOCAL mask and an ispacklocal() access macro.
So instead of this:
if (p->pack_local)
do_something
you would do this:
if (ispacklocal(p))
do_something
This is in preparation for adding a flag indicating whether a .keep file is
present.
Signed-off-by: Brandon Casey <drafnel@gmail.com>
---
builtin-count-objects.c | 2 +-
builtin-gc.c | 2 +-
builtin-pack-objects.c | 2 +-
cache.h | 5 ++++-
pack-redundant.c | 4 ++--
server-info.c | 4 ++--
sha1_file.c | 5 +++--
7 files changed, 14 insertions(+), 10 deletions(-)
diff --git a/builtin-count-objects.c b/builtin-count-objects.c
index ab35b65..3f981d6 100644
--- a/builtin-count-objects.c
+++ b/builtin-count-objects.c
@@ -108,7 +108,7 @@ int cmd_count_objects(int argc, const char **argv, const char *prefix)
if (!packed_git)
prepare_packed_git();
for (p = packed_git; p; p = p->next) {
- if (!p->pack_local)
+ if (!ispacklocal(p))
continue;
if (open_pack_index(p))
continue;
diff --git a/builtin-gc.c b/builtin-gc.c
index 7af65bb..0473158 100644
--- a/builtin-gc.c
+++ b/builtin-gc.c
@@ -135,7 +135,7 @@ static int too_many_packs(void)
size_t len;
int keep;
- if (!p->pack_local)
+ if (!ispacklocal(p))
continue;
len = strlen(p->pack_name);
if (PATH_MAX <= len + 1)
diff --git a/builtin-pack-objects.c b/builtin-pack-objects.c
index 59c30d1..6a8b9bf 100644
--- a/builtin-pack-objects.c
+++ b/builtin-pack-objects.c
@@ -701,7 +701,7 @@ static int add_object_entry(const unsigned char *sha1, enum object_type type,
break;
if (incremental)
return 0;
- if (local && !p->pack_local)
+ if (local && !ispacklocal(p))
return 0;
}
}
diff --git a/cache.h b/cache.h
index b0edbf9..0cb9350 100644
--- a/cache.h
+++ b/cache.h
@@ -679,12 +679,15 @@ extern struct packed_git {
int index_version;
time_t mtime;
int pack_fd;
- int pack_local;
+ unsigned int flags;
unsigned char sha1[20];
/* something like ".git/objects/pack/xxxxx.pack" */
char pack_name[FLEX_ARRAY]; /* more */
} *packed_git;
+#define PACK_LOCAL 1
+#define ispacklocal(p) ((p)->flags & PACK_LOCAL)
+
struct pack_entry {
off_t offset;
unsigned char sha1[20];
diff --git a/pack-redundant.c b/pack-redundant.c
index 25b81a4..964f18f 100644
--- a/pack-redundant.c
+++ b/pack-redundant.c
@@ -544,7 +544,7 @@ static struct pack_list * add_pack(struct packed_git *p)
unsigned long off = 0, step;
const unsigned char *base;
- if (!p->pack_local && !(alt_odb || verbose))
+ if (!ispacklocal(p) && !(alt_odb || verbose))
return NULL;
l.pack = p;
@@ -562,7 +562,7 @@ static struct pack_list * add_pack(struct packed_git *p)
}
/* this list will be pruned in cmp_two_packs later */
l.unique_objects = llist_copy(l.all_objects);
- if (p->pack_local)
+ if (ispacklocal(p))
return pack_list_insert(&local_packs, &l);
else
return pack_list_insert(&altodb_packs, &l);
diff --git a/server-info.c b/server-info.c
index c1c073b..2eb20f5 100644
--- a/server-info.c
+++ b/server-info.c
@@ -168,14 +168,14 @@ static void init_pack_info(const char *infofile, int force)
/* we ignore things on alternate path since they are
* not available to the pullers in general.
*/
- if (!p->pack_local)
+ if (!ispacklocal(p))
continue;
i++;
}
num_pack = i;
info = xcalloc(num_pack, sizeof(struct pack_info *));
for (i = 0, p = packed_git; p; p = p->next) {
- if (!p->pack_local)
+ if (!ispacklocal(p))
continue;
info[i] = xcalloc(1, sizeof(struct pack_info));
info[i]->p = p;
diff --git a/sha1_file.c b/sha1_file.c
index ab2b520..e4141c9 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -851,7 +851,8 @@ struct packed_git *add_packed_git(const char *path, int path_len, int local)
* actually mapping the pack file.
*/
p->pack_size = st.st_size;
- p->pack_local = local;
+ if (local)
+ p->flags |= PACK_LOCAL;
p->mtime = st.st_mtime;
if (path_len < 40 || get_sha1_hex(path + path_len - 40, p->sha1))
hashclr(p->sha1);
@@ -941,7 +942,7 @@ static int sort_pack(const void *a_, const void *b_)
* remote ones could be on a network mounted filesystem.
* Favor local ones for these reasons.
*/
- st = a->pack_local - b->pack_local;
+ st = ispacklocal(a) - ispacklocal(b);
if (st)
return -st;
--
1.6.0.2.588.g3102
^ permalink raw reply related
* Re: [PATCH] prepare deprecation of git-revert
From: Johannes Schindelin @ 2008-11-02 16:12 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: Alex Riesen, Pierre Habouzit, git
In-Reply-To: <20081102093225.GA32296@laptop>
Hi,
On Sun, 2 Nov 2008, Nguyen Thai Ngoc Duy wrote:
> Add git command expansion
>
> This allows git commands to be typed shorter (in shells that do not
> support autocompletion). There are three types of expansion:
>
> - "foo" matches "foo*" commands (bi -> bisect)
> - "foo" also matches "f*-oo*" (fim -> fast-import)
> - "foo-bar" (with dash) matches "foo*-bar*" (fo-p -> format-patch)
I'd rather have the soft-alias code back to perform this expansion, but
only for a limited and explicit set of abbreviations.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Use find instead of perl in t5000 to get file modification time
From: Johannes Schindelin @ 2008-11-02 16:05 UTC (permalink / raw)
To: Alex Riesen
Cc: Sam Vilain, Git Mailing List, Junio C Hamano, Jeff King,
René Scharfe
In-Reply-To: <20081102143751.GA18140@blimp.localdomain>
Hi,
On Sun, 2 Nov 2008, Alex Riesen wrote:
> Johannes Schindelin, Sat, Nov 01, 2008 21:37:14 +0100:
> > On Sat, 1 Nov 2008, Alex Riesen wrote:
> > > Johannes Schindelin, Sat, Nov 01, 2008 01:23:32 +0100:
> > > >
> > > > P.S.: some guys at the GSoC mentor summit convinced me in at least
> > > > trying to fix _their_ problems on msysGit, so chances are good
> > > > I'll fix issues you would encounter in the same run.
> > >
> > > Do you still plan to distribute MinGW with it? It's very nice to be
> > > able to track Junio's repo, have own branches and rebuild Git from
> > > time to time. For me, at least.
> >
> > You mean to distribute a minimal MSys environment where you have bash?
> > Yes, we have to do that, as there are still too many important parts
> > of Git written in Shell.
>
> No, the mingw compiler and libraries. I vaguely remember some talking
> about including the build environment into Git distribution.
We do that already for a long time. Basically, we have two distributions:
Git for Windows (for the end user) and msysGit (for the developer wanting
to work _on_ Git). Actually, msysGit was there first.
Hth,
Dscho
^ permalink raw reply
* Re: [PATCH] add instructions on how to send patches to the mailing list with Gmail
From: Fredrik Skolmli @ 2008-11-02 15:01 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: Tom Preston-Werner, Santi Béjar, git, Junio C Hamano
In-Reply-To: <20081102091006.GA4066@artemis>
On Sun, Nov 02, 2008 at 10:10:06AM +0100, Pierre Habouzit wrote:
> > > Warning: It is not secure.
> >
> > It is true that the certificate is not verified, but since the patches
> > are destined for a public mailing list, this does not represent a
> > large problem.
>
> What he means is that the password is cleartext ;)
> (I think)
The way I read and understand it, the issues arises if a MITM-attack takes
place. If the client doesn't verify the certificate, an attacker can easily
get the username and password.
So unless someone creates a separate gmail-account for submitting patches,
one should really trust the connection (ie not a public wlan), or verify the
certificate before transmitting the password.
--
Kind regards,
Fredrik Skolmli
^ permalink raw reply
* Re: [PATCH] Use find instead of perl in t5000 to get file modification time
From: Alex Riesen @ 2008-11-02 14:37 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Sam Vilain, Git Mailing List, Junio C Hamano, Jeff King,
René Scharfe
In-Reply-To: <alpine.DEB.1.00.0811012134290.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Johannes Schindelin, Sat, Nov 01, 2008 21:37:14 +0100:
> On Sat, 1 Nov 2008, Alex Riesen wrote:
> > Johannes Schindelin, Sat, Nov 01, 2008 01:23:32 +0100:
> > >
> > > Well, if you install Git for Windows (as opposed to cygwin), it is
> > > minimum hassle, and Perl is delivered right with it.
> >
> > I'd like to try it again, but weren't ther some fatal problems with
> > cygwin1.dll being in PATH? I always work either in Cygwin's bash or just
> > have to have it in PATH, because of the build environment even being
> > strictly Windows based (case-insensitive and alike) just have to use
> > sane tooling in its scripts.
>
> I was talking about Git for Windows, i.e. the result of msysGit (as
> opposed to Git in Cygwin).
>
> So no, there have not been any conflicts with cygwin1.dll in the PATH, as
> far as I can recall. There have been problems with shell utilities being
> found in the Cygwin PATH before being found in the MSys PATH, but I
> thought we just prepended the MSys PATH to avoid that. Haven't checked,
> though.
Ok, I'll give it a try.
> > > P.S.: some guys at the GSoC mentor summit convinced me in at least
> > > trying to fix _their_ problems on msysGit, so chances are good I'll
> > > fix issues you would encounter in the same run.
> >
> > Do you still plan to distribute MinGW with it? It's very nice to be able
> > to track Junio's repo, have own branches and rebuild Git from time to
> > time. For me, at least.
>
> You mean to distribute a minimal MSys environment where you have bash?
> Yes, we have to do that, as there are still too many important parts of
> Git written in Shell.
No, the mingw compiler and libraries. I vaguely remember some talking
about including the build environment into Git distribution.
^ permalink raw reply
* RE: why not TortoiseGit
From: Li Frank @ 2008-11-02 14:14 UTC (permalink / raw)
To: Scott Chacon, Andreas Ericsson; +Cc: Ian Hilt, git
In-Reply-To: <d411cc4a0810310857y5b4f8c46ue33e1f6a9e2c13d1@mail.gmail.com>
I read some code of TortoiseSVN and TortoiseHg Code.
At beginning, TortoiseGit can git command to get information like Qgit.
After linkable library ready, replace "git command".
I think TortoiseGit can start base on below way.
1. Base on TortoiseHg, It is python Script. Replace below hg operator
with Git.
2. Base on TortoiseSVN, It is developed with C++. Need VS2008.
ToritoiseSVN provide some built in diff and merge tools.
3. Base on Qgit, which provide some basic UI, such comment dialogbox,
history view and file annotate.
Best regards
Frank Li
-----Original Message-----
From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On
Behalf Of Scott Chacon
Sent: Friday, October 31, 2008 11:58 PM
To: Andreas Ericsson
Cc: Ian Hilt; Li Frank-B20596; git@vger.kernel.org
Subject: Re: why not TortoiseGit
I'm trying to get this restarted - dscho and I talked about this at the
GitTogether, and I met some people (from the OpenAFS project that also
happened to be there, oddly) who were interested in working on this with
me. I think the lack of a linkable library has greatly hindered the
development of projects like this, so that will likely be part of the
development process as well.
Scott
On Fri, Oct 31, 2008 at 5:35 AM, Andreas Ericsson <ae@op5.se> wrote:
> Ian Hilt wrote:
>>
>> On Fri, Oct 31, 2008 at 09:44:45AM +0800, Li Frank-B20596 wrote:
>>>
>>> There are TortoiseCVS, TortoiseSVN, TortoiseBzr, TortoiseHg Why not
>>> ToroiseGit
>>
>> This is what Johannes Schindelin had to say,
>>
>> <http://code.google.com/p/msysgit/wiki/GitCheetah>
>
> Noone's written TortoiseGit yet. I have no idea why, and I have no
> reason to write it myself. If GitCheetah isn't working well, I'm sure
> patches are welcome.
>
> --
> Andreas Ericsson andreas.ericsson@op5.se
> OP5 AB www.op5.se
> Tel: +46 8-230225 Fax: +46 8-230231
> --
> To unsubscribe from this list: send the line "unsubscribe git" in the
> body of a message to majordomo@vger.kernel.org More majordomo info at
> http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe git" in the
body of a message to majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: commit takes 8 secs; but instant when offline - can I fix this?
From: Thomas Rast @ 2008-11-02 14:13 UTC (permalink / raw)
To: 13ren; +Cc: git
In-Reply-To: <1225634894605-1445352.post@n2.nabble.com>
[-- Attachment #1: Type: text/plain, Size: 388 bytes --]
13ren wrote:
> With the network plugged in, git-commit takes 8 seconds.
>
> When I unplug the network, commit is instant...
Configure your user.email (and user.name), see man git-config. If the
email is not set, Git tries to figure out your hostname, which
depending on DNS misconfigurations can apparently cause such delays.
--
Thomas Rast
trast@{inf,student}.ethz.ch
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* commit takes 8 secs; but instant when offline - can I fix this?
From: 13ren @ 2008-11-02 14:08 UTC (permalink / raw)
To: git
Hi all,
With the network plugged in, git-commit takes 8 seconds.
When I unplug the network, commit is instant...
I confirmed this with a fresh test directory, just adding an extra line to
the file "test" for each commit:
> git init
Initialized empty Git repository in /home/user/gitexpt/.git/
> vi test
> git add *
> date; git commit -a -m "add minor change"; date
Mon Nov 3 00:31:02 EST 2008
Created commit 9b845a2: add minor change
1 files changed, 2 insertions(+), 0 deletions(-)
Mon Nov 3 00:31:10 EST 2008
> date; git commit -a -m "add test, without network"; date
Mon Nov 3 00:46:00 EST 2008
Created commit dd02a69: add test, without network
1 files changed, 3 insertions(+), 0 deletions(-)
Mon Nov 3 00:46:00 EST 2008
> git --version
git version 1.5.6.3
Anyone know why is git-commit so slow? Or if there I can anything to change
this?
I'd assumed the slowness was normal, since I'm new to version control. I've
googled and searched mailing lists, but haven't found this. Could be just my
installation (or others make the same assumption?)
Many thanks for any help... I'm going a little crazy here.
--
View this message in context: http://n2.nabble.com/commit-takes-8-secs--but-instant-when-offline---can-I-fix-this--tp1445352p1445352.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Encoding problems using git-svn
From: Robin Rosenberg @ 2008-11-02 13:45 UTC (permalink / raw)
To: Eric Wong; +Cc: James North, Junio C Hamano, git
In-Reply-To: <20081102094845.GB16003@untitled>
On söndag 02 november 2008 10:48 Eric Wong wrote:
> James North <tocapicha@gmail.com> wrote:
> > Hi Eric,
> >
> > Don't worry about not seeing the patch and thanks for the answer :)
> >
> > Your patch works great.
> >
> > Messages appear without problems on "svn log" and "git log", I haven't
> > found any gotcha that I know of.
>
> Thanks for the confirmation.
>
> > The weird thing is that this problem was not found by anyone before, I
> > guessed there should be some people with a setup similar to mine.
>
> Squeaky wheel gets the grease :)
>
> Honestly, I think most folks have just moved onto UTF-8 entirely and
> left legacy encodings behind. Especially people using modern tools like
> git (along with SVN enforcing UTF-8 at the repository/protocol level).
"Most" people don't have a legacy encoding problem, but some of us do and
tools that help with migration by enforcing UTF-8 internally help. SVN is such
an example, though not very helpful as an SCM. That way we can still use
legacy encodings for old stupid tools until we can move to an all UTF-8 world.
We're not there yet, but in a few years hopefully. That's when it's sad that
the git command line for example still enforce the legacy encoding. Some
GUI's, like git gui, jgit and probably a few others help by recoding when
necessary.
-- robiin
^ permalink raw reply
* [PATCH v2] Add reference for status letters in documentation.
From: Yann Dirson @ 2008-11-02 13:37 UTC (permalink / raw)
To: git
Also fix error in diff_filepair::status documentation, and point to
the in-code reference as well as the doc.
Signed-off-by: Yann Dirson <ydirson@altern.org>
---
Since diffcore.h is for devs anyway, it is IMHO a good idea to let it
also point to the in-code doc.
Documentation/diff-format.txt | 16 ++++++++++++++++
diffcore.h | 2 +-
2 files changed, 17 insertions(+), 1 deletions(-)
diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
index 400cbb3..aafd3a3 100644
--- a/Documentation/diff-format.txt
+++ b/Documentation/diff-format.txt
@@ -46,6 +46,22 @@ That is, from the left to the right:
. path for "dst"; only exists for C or R.
. an LF or a NUL when '-z' option is used, to terminate the record.
+Possible status letters are:
+
+- A: addition of a file
+- C: copy of a file into a new one
+- D: deletion of a file
+- M: modification of the contents or mode of a file
+- R: renaming of a file
+- T: change in the type of the file
+- U: file is unmerged (you must complete the merge before it can
+be committed)
+- X: "unknown" change type (most probably a bug, please report it)
+
+Status letters C and M are always followed by a score (denoting the
+percentage of similarity between the source and target of the move or
+copy), and are the only ones to be so.
+
<sha1> is shown as all 0's if a file is new on the filesystem
and it is out of sync with the index.
diff --git a/diffcore.h b/diffcore.h
index 713cca7..5b63458 100644
--- a/diffcore.h
+++ b/diffcore.h
@@ -62,7 +62,7 @@ struct diff_filepair {
struct diff_filespec *one;
struct diff_filespec *two;
unsigned short int score;
- char status; /* M C R N D U (see Documentation/diff-format.txt) */
+ char status; /* M C R A D U etc. (see Documentation/diff-format.txt or DIFF_STATUS_* in diff.h) */
unsigned broken_pair : 1;
unsigned renamed_pair : 1;
unsigned is_unmerged : 1;
^ permalink raw reply related
* Re: [PATCH] git-diff: Add --staged as a synonym for --cached.
From: Björn Steinbrink @ 2008-11-02 12:35 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, David Symonds, git, gitster, Stephan Beyer
In-Reply-To: <20081029171122.GA12167@sigill.intra.peff.net>
On 2008.10.29 13:11:22 -0400, Jeff King wrote:
> On Wed, Oct 29, 2008 at 06:06:09PM +0100, Johannes Schindelin wrote:
>
> > However, note that we have to hash out what to do about the convention
> > that --cached traditionally means that only the staging area (formerly
> > known as "the index") is affected, while --index means that the command
> > touches the working directory, too.
>
> If we assume that we have only the word "stage" and variations
> available, then there aren't too many options.
>
> only the staging area:
> --stage-only, --staged-only
>
> both:
> --staged (as opposed to --staged-only) --stage-and-worktree (too
> long), --both (not descriptive enough), --stage-too (yuck)
Hm, I don't think that would work out nicely with stash. --keep-index
would become --keep-staged-only, which is IMHO pretty confusing, as the
default is to keep nothing. And even if you add another option to keep
all changes, so that the current state is just put onto the stash, but
the working tree and index are unchanged, you would have --keep-staged
and --keep-staged-only. Not really any better.
Admittedly, --keep-index is quite different from --index, but if you're
going to change the CLI to hide the word "index", that option needs to
be changed as well and the usage of the new terms should be unified.
Looking at --cached/--index we have basically three things:
--cached to refer to the state of the index (diff, grep, [stash], ...)
--cached to _work on_ the index only (rm, apply, ...)
--index to _work on_ both the index and the working tree (apply, ...)
Maybe that could be translated to:
--staged: refer to the state of the index
--stage: in addition to changing the working tree, also stage the changes
--stage-only: only stage the changes, don't change the working tree
That would give us, for example:
git diff --staged
git grep --staged
git apply --stage
git apply --stage-only
git rm --stage-only
git stash --keep-staged
A quick look through Documentation/ revealed only one problematic case,
which is ls-files that already has a --stage option. And that looks like
a dealbreaker :-(
Björn
^ permalink raw reply
* Re: [RFC/PATCH 1/2] bisect: add "git bisect replace" subcommand
From: Christian Couder @ 2008-11-02 11:20 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0811020515370.22125@pacific.mpi-cbg.de.mpi-cbg.de>
Hi,
Le dimanche 2 novembre 2008, Johannes Schindelin a écrit :
> Hi,
>
> On Sun, 2 Nov 2008, Christian Couder wrote:
> > This new subcommand should be used when you have a branch or a part of
> > a branch that isn't easily bisectable because at some point, say A, a
> > bug as been introduced. The bug has been fixed latter at another point,
> > say B, but between these points the code is not easily testable because
> > of the bug, so it's not easy to bisect between these points.
>
> Would it not be more intuitive to have support for
>
> git bisect skip A..B
>
> ?
We can have both. "bisect skip" is about not being able or wanting to test
some commits and "bisect replace" is about testing using fixed up branches
(that you can share with others) instead of branches that you can't test.
When working on big projects where many people are often bisecting (like the
Linux kernel), then having shared "bisect-replace" branches (and tags)
might save a lot of time to all people bisecting, as they will not have to
often skip the same commits or maintain sets of patches to apply when
bisecting.
Thanks,
Christian.
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Theodore Tso @ 2008-11-02 10:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Pierre Habouzit, Sam Vilain, git, Sam Vilain
In-Reply-To: <7v1vxu4q49.fsf@gitster.siamese.dyndns.org>
On Sat, Nov 01, 2008 at 11:08:06PM -0700, Junio C Hamano wrote:
> > (And I get annoyed when I want to run git format-patch on a single
> > patch not at the tip of the tree; but if it's just me, I can write a
> > "git format-single-patch" wrapper script to get around it.)
>
> Huh? I am so used to "git format-patch -1 HEAD" (or "332d2e78") that I am
> very surprised.
Well, the explanation is that "-<n>" isn't in the SYNPOSIS section of
'git format-patch', and so I never knew you could do it that way. A
new user of git has to paw through approximately 50 options in the
OPTIONS section of the man page before finding "-<n>"; and somehow
I've always missed it. I'd suggest adding an explicit mention of -<n>
to the DESCRIPTION section, perhaps in the paragraph:
A single commit, when interpreted as a <revision range> expression,
means "everything that leads to that commit", but if you write git
format-patch <commit>, the previous rule applies to that command
line and you do not get "everything since the beginning of the
time". If you want to format everything since project inception to
one commit, say "git format-patch --root <commit>" to make it clear
that it is the latter case.
Adding the sentence:
If you want to format a single commit, you can do this via
"git format-patch -1 <commit>" or the more esoteric and perl-ish,
"git format-patch <commit>^!"
might be helpful.
- Ted
^ permalink raw reply
* Re: [PATCH] Documentation: add a planning document for the next CLI revamp
From: Theodore Tso @ 2008-11-02 9:56 UTC (permalink / raw)
To: Jeff King
Cc: Sam Vilain, Sam Vilain, git, Johannes Schindelin, Scott Chacon,
Tom Preston-Werner, J.H., Christian Couder, Kai Blin
In-Reply-To: <20081102041832.GB5261@coredump.intra.peff.net>
On Sun, Nov 02, 2008 at 12:18:33AM -0400, Jeff King wrote:
>
> Yeah, revert-files is pretty painful to type. And I'm not looking
> forward to fielding UI questions about "why isn't it just revert?" :)
>
At least for me, I don't use it *that* often, so it's not that painful
for me (I have it as an "git revert-file" as an alias already).
And the answer, "because 'git revert' used to do something else" is I
think a perfectly reasonable answer. I probably do "git revert-files"
about 3-5 times more often than I do "git revert", so it's a bit
strange from a character count perspective, but history is history.
> Somebody suggested "clobber", which I think is a bit _too_ intense.
>
> I guess something like "retrieve" is too ambiguous. You really need
> something that implies movement of content, and something that implies
> the working directory. "Checkout" is actually not a bad name; if only we
> had "git switch" instead of "git checkout" for switching branches, it
> would be perfect.
If people really want a shorter name, how about bk's "unedit"? I'd
still worry about people being able to find it, since the reality is
that most of the world knows this command as revert, though.
- Ted
^ 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