* Re: [PATCH] user-manual: Use "git config --global" instead of editing ~/.gitconfig
From: Junio C Hamano @ 2007-05-11 4:48 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Petr Baudis, Johan Herland, git
In-Reply-To: <20070511034653.GB26896@fieldses.org>
"J. Bruce Fields" <bfields@fieldses.org> writes:
> So while I'm not convinced of the value of consistency here, if we have
> to have consistency, I'd rather standardize on config-file-editing.
I obviously agree with everything you said.
I do not think "consistency" should weigh too much in the
teaching and learning process, which is what a manual is about.
It is beneficial to make the readers aware, early in the
process, that there typically are more than one ways to do
things, one suitable for scripting and the other for interactive
use. In the introductory part of the user-manual, I think it is
a very good idea to give a bit of glimpse of what is going on
under the hood, and config file is probably the easiest thing to
give that warm feeling of something they can understand is going
on to the readers.
^ permalink raw reply
* Integrate StGIT into Git? (Was: Re: Using StGIT for tweaking already-committed stuff)
From: Jan Hudec @ 2007-05-11 5:48 UTC (permalink / raw)
To: Carl Worth
Cc: Petr Baudis, J. Bruce Fields, Linus Torvalds, Johannes Sixt,
catalin.marinas, git
In-Reply-To: <87sla42xc4.wl%cworth@cworth.org>
[-- Attachment #1: Type: text/plain, Size: 1591 bytes --]
Hello Folks,
On Thu, May 10, 2007 at 14:16:43 -0700, Carl Worth wrote:
> I'll try again.
>
> I like the git user interface. I like it a lot. (It's got a couple of
> tiny things that I would do differently if I could start over, but
> more importantly it has a lot of big things that I wouldn't have even
> thought of if I had started from scratch.)
>
> But with respect to the current topic, there are a couple of features
> that the git interface is missing compared to something like stg:
>
> 1. Amend a commit that's somewhere besides the tip of a branch,
> (rebuilding every commit that follows)
>
> 2. Re-ordering commits that exist on a branch, (again, rebuilding
> every commit that follows).
I would actually propose to (gradually) add stg functionality into git. If it
was done in stgit-compatible fashion, it would allow using stgit for the bits
still not ported to git and switching back and forth according to user's
taste.
Many commands from stgit either already have git equivalent or do just
a little work beyond what the git command already does, so they could be
easily integrated.
> [...]
> I'd just love to see something more minimal, and incorporated into git
> itself, to address the missing functionality. Right now, "cherry-pick
> A..B" is all I have to suggest. But maybe later there could be some
> sort of push/pop addition as well, (except that obviously the name
> "push" isn't available as a sub-command).
I think that many of them would be actually pretty simple.
--
Jan 'Bulb' Hudec <bulb@ucw.cz>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git rebase chokes on directory -> symlink -> directory
From: Junio C Hamano @ 2007-05-11 6:04 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: H. Peter Anvin, Alex Riesen, Git Mailing List, Linus Torvalds
In-Reply-To: <20070510220418.GK3141@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <junkio@cox.net> wrote:
>> * git-rebase with -m is dog slow. There were people who
>> advocated to make it the default, but they probably are
>> either working in a very small project, or working on a
>> filesystem that even git-apply is slow that the speed
>> difference does not matter to them.
> ...
> But that's not the situation everyone else has, so its reasonable
> that -m ain't the default. ;-)
Well, that is not the conclusion you should be drawing from
this. If rebase -m is 10x slower than without -m in cases where
the rename handling does not matter, there is something wrong.
And what is wrong in this case is that the unpack-trees tree
merging code, which is used everywhere in git to do branch
switching and merges, is way too inefficient.
When merge-recursive is instructed to merge another tree with
the current tree using an ancestor, while taking the index into
account, it basically does the three-way tree-level merge one
path at a time, even when subdirectory at quite high level
matches identically across three trees.
The situation is the same for switching branches. If two
branches of the kernel project (22k files spread across 1300
directories) differ at a file at the toplevel (e.g. v2.6.21
which changes only Makefile), we still read the index, the
current tree, and the other branch, and match all 22k files one
by one to compute the resulting index entry, by first removing
the current index entry and then stuffing the result entry in
the index, all the while trashing the cache-tree. Then we
recompute all 1300 tree objects and write them out, even though
we should be able to notice that none of the toplevel 17
subdirectories have changed, and all we have to do is to rehash
one blob and recompute only one tree object at the toplevel. We
boast how lightweight git branches are and how fast switching
between two branches is, but that's a serious lie. If done
properly, we should be able to switch branches in a time roughly
proportional to the number of paths different between the
branches. Currently, the time is proportional to the size of
the tree, no matter how small the change between trees are.
git-apply, which is used by rebase without -m, is optimized to
make it proportional to the size of the change. It obviously
knows to only touch the affected paths (because the patch does
not talk about unaffected paths) and leave the others intact,
but also avoids expensive tree recomputation for unaffected
directories, by properly maintaining the cache-tree data in the
index.
IIRC, Linus said unpack-trees was beyond repair several months
ago, and I tend to agree with him. Currently the first thing
unpack-trees does is to discard cache-tree from the index,
because the code does not properly invalidate affected paths,
and it is probably way too cumbersome to add it to various
places the code modifies the index (I haven't looked at it
recently, so maybe somebody can try it and prove me wrong).
My gut feeling is that we may be better off redoing the tree
level merge infrastructure from scratch, and make a new one that
is optimized for trees with small differences. There is a
prototype code called test-para in 'pu' that implements such a
multi-tree walk, and also we've had its precursor (by Linus)
called git-merge-tree in 'master' for quite a long time, but
unfortunately neither has recently seen any activity.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.2-rc3
From: Alexander Litvinov @ 2007-05-11 6:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzukf0h6.fsf@assigned-by-dhcp.cox.net>
> Sorry, you are expecting too much.
No, that is done is great!
I have tried your test and found that cloning such repo does not clone
subprojects. Only empty dir 'sub' is being cloned.
> If you are interested, go back to the list archive and start
> reading around April 13th - 15th. We had quite an active
> weekend; two neat features (subproject and attributes)
> materialized almost at the same time.
Thanks for the point.
Alexander Litvinov.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.2-rc3
From: Junio C Hamano @ 2007-05-11 7:10 UTC (permalink / raw)
To: Alexander Litvinov; +Cc: git
In-Reply-To: <200705111330.54312.litvinov2004@gmail.com>
Alexander Litvinov <litvinov2004@gmail.com> writes:
> I have tried your test and found that cloning such repo does not clone
> subprojects. Only empty dir 'sub' is being cloned.
Yes, that is pretty much intentional. Having a link for higher
layer tools can use (i.e. tree objects can contain 160000 mode
"gitlinks" to subproject commit objects) while not considering
such linkage part of the reachability is the whole point of
plumbing level subproject support. It allows people not to
download repositories of uninteresting subprojects. Higher
layer tools such as clone/checkout/diff could be instructed
(currently they cannot be, though) to recurse into subproject
directories if the user wants to.
A few good pointers for this topic are:
$gmane/44162
$gmane/44308
^ permalink raw reply
* [PATCH] read-tree -m -u: avoid getting confused by intermediate symlinks.
From: Junio C Hamano @ 2007-05-11 7:13 UTC (permalink / raw)
To: git
When switching from a branch with both x86_64/boot/Makefile and
i386/boot/Makefile to another branch that has x86_64/boot as a
symlink pointing at ../i386/boot, the code incorrectly removed
i386/boot/Makefile.
This was because we first removed everything under x86_64/boot
to make room to create a symbolic link x86_64/boot, then removed
x86_64/boot/Makefile which no longer exists but now is pointing
at i386/boot/Makefile, thanks to the symlink we just created.
This fixes it by using the has_symlink_leading_path() function
introduced previously for git-apply in the checkout codepath.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This comes on top of the previous git-apply patch.
Makefile | 2 +-
builtin-apply.c | 36 +-----------------------------------
cache.h | 1 +
symlinks.c | 35 +++++++++++++++++++++++++++++++++++
t/t4122-apply-symlink-inside.sh | 1 -
unpack-trees.c | 2 ++
6 files changed, 40 insertions(+), 37 deletions(-)
create mode 100644 symlinks.c
diff --git a/Makefile b/Makefile
index 7cf146b..29243c6 100644
--- a/Makefile
+++ b/Makefile
@@ -318,7 +318,7 @@ LIB_OBJS = \
write_or_die.o trace.o list-objects.o grep.o match-trees.o \
alloc.o merge-file.o path-list.o help.o unpack-trees.o $(DIFF_OBJS) \
color.o wt-status.o archive-zip.o archive-tar.o shallow.o utf8.o \
- convert.o attr.o decorate.o progress.o mailmap.o
+ convert.o attr.o decorate.o progress.o mailmap.o symlinks.o
BUILTIN_OBJS = \
builtin-add.o \
diff --git a/builtin-apply.c b/builtin-apply.c
index 38d20ef..01acba8 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -2009,40 +2009,6 @@ static int apply_data(struct patch *patch, struct stat *st, struct cache_entry *
return 0;
}
-static int has_symlink_component(const char *new_name)
-{
- char path[PATH_MAX];
- const char *sp, *ep;
- char *dp;
-
- sp = new_name;
- dp = path;
-
- while (1) {
- size_t len;
- struct stat st;
-
- ep = strchr(sp, '/');
- if (!ep)
- break;
- len = ep - sp;
- if (PATH_MAX <= dp + len - path + 2)
- return 0; /* new name is longer than that??? */
- memcpy(dp, sp, len);
- dp[len] = 0;
-
- if (lstat(path, &st))
- return 0; /* why? we already lstat() new_name successfully. */
- if (S_ISLNK(st.st_mode))
- return 1;
-
- dp[len++] = '/';
- dp = dp + len;
- sp = ep + 1;
- }
- return 0;
-}
-
static int check_to_create_blob(const char *new_name, int ok_if_exists)
{
struct stat nst;
@@ -2056,7 +2022,7 @@ static int check_to_create_blob(const char *new_name, int ok_if_exists)
* In such a case, path "new_name" does not exist as
* far as git is concerned.
*/
- if (has_symlink_component(new_name))
+ if (has_symlink_leading_path(new_name))
return 0;
return error("%s: already exists in working directory", new_name);
diff --git a/cache.h b/cache.h
index 8e76152..ab66263 100644
--- a/cache.h
+++ b/cache.h
@@ -410,6 +410,7 @@ struct checkout {
};
extern int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *topath);
+extern int has_symlink_leading_path(const char *name);
extern struct alternate_object_database {
struct alternate_object_database *next;
diff --git a/symlinks.c b/symlinks.c
new file mode 100644
index 0000000..cfecfcf
--- /dev/null
+++ b/symlinks.c
@@ -0,0 +1,35 @@
+#include "cache.h"
+
+int has_symlink_leading_path(const char *name)
+{
+ char path[PATH_MAX];
+ const char *sp, *ep;
+ char *dp;
+
+ sp = name;
+ dp = path;
+
+ while (1) {
+ size_t len;
+ struct stat st;
+
+ ep = strchr(sp, '/');
+ if (!ep)
+ break;
+ len = ep - sp;
+ if (PATH_MAX <= dp + len - path + 2)
+ return 0; /* new name is longer than that??? */
+ memcpy(dp, sp, len);
+ dp[len] = 0;
+
+ if (lstat(path, &st))
+ return 0;
+ if (S_ISLNK(st.st_mode))
+ return 1;
+
+ dp[len++] = '/';
+ dp = dp + len;
+ sp = ep + 1;
+ }
+ return 0;
+}
diff --git a/t/t4122-apply-symlink-inside.sh b/t/t4122-apply-symlink-inside.sh
index 37c9a9f..3ddfe64 100755
--- a/t/t4122-apply-symlink-inside.sh
+++ b/t/t4122-apply-symlink-inside.sh
@@ -34,7 +34,6 @@ test_expect_success setup '
test_expect_success apply '
git checkout test &&
- git reset --hard && #### checkout seems to be buggy
git diff --exit-code test &&
git diff --exit-code --cached test &&
git apply --index test.patch
diff --git a/unpack-trees.c b/unpack-trees.c
index 675a999..a6fa32f 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -268,6 +268,8 @@ static void unlink_entry(char *name)
{
char *cp, *prev;
+ if (has_symlink_leading_path(name))
+ return;
if (unlink(name))
return;
prev = NULL;
--
1.5.2.rc3.706.g498a
^ permalink raw reply related
* Repo cleanup problem
From: Eugine Kosenko @ 2007-05-11 8:03 UTC (permalink / raw)
To: git
I'm sorry, if it is a FAQ.
I use git to track my own changes in a project, i.e, this is a private
(not public) repository. Some time ago I've accidentally committed a
big amount (about of 50M) of crap into the repository, and make a
mature set of commits after this.
For now I'm looking for a way to remove the garbage commit. I've found
a way to remove any commit using git-checkout, git-reset and
git-rebase. But, when I even git-reset the repository to the very
first (root) commit, I see the size is still large enough, i.e., the
crap is still there. I've tried many combinations of git-gc,
git-prune, git-repack, git-prune-packed etc, but the size of the
repository is still the same. The only way I see now is to git-clone
the repository -- the new one is essentially smaller, but needs to
reconstruct the local branches.
Is this (make a clone) the only proper way to clenup a repository, or
there is another magic tool to cleanup the repositories?
^ permalink raw reply
* Re: Repo cleanup problem
From: Matthieu Moy @ 2007-05-11 8:10 UTC (permalink / raw)
To: git
In-Reply-To: <9909dee80705110103h5b848490m296c001beecfa1f1@mail.gmail.com>
"Eugine Kosenko" <eugine.kosenko@gmail.com> writes:
> For now I'm looking for a way to remove the garbage commit.
Branch before the garbage commit. Then, you can use git-rebase to
replay the correct history on top of your new branch. Note that
git-rebase will break merging if you already used merge: it does not
"move" your old commits to your new branch, it instead creates new
commits with the same changes at the old ones, in the new branch.
That's probably what you've done already.
Then, to have git-gc remove the old, bad, history, you need to remove
any reference you have to it: branches and tags. git-branch -d and
perhaps git-tag -d will tell you.
See also git-fsck that can point you to dangling objects, which should
then be removed by git-gc.
gitk --all, on the other hand, will show you the commits to which you
have a reference (and their ancestry).
--
Matthieu
^ permalink raw reply
* Re: Repo cleanup problem
From: Karl Hasselström @ 2007-05-11 8:19 UTC (permalink / raw)
To: git
In-Reply-To: <vpqveezhjb0.fsf@bauges.imag.fr>
On 2007-05-11 10:10:43 +0200, Matthieu Moy wrote:
> Then, to have git-gc remove the old, bad, history, you need to remove
> any reference you have to it: branches and tags. git-branch -d and
> perhaps git-tag -d will tell you.
The reflog is on by default nowadays, which essentially means that
dangling commits won't be pruned for 30 days or something -- unless
you delete the references in the reflog as well. "git reflog expire"
can probably help here.
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* [RFC] gitk using diff-tree -M for merges
From: Uwe Kleine-König @ 2007-05-11 8:45 UTC (permalink / raw)
To: git
Hello,
looking at the diff that commit 070739fd351702ea9bb4f65595728ae25a488075
introduced with gitk from 1.5.2-rc3 [1], I'd prefer gitk using the
option -M for diff-tree to detect that in 3f28f63f git-gui.sh exists,
too. Currently the diff is a bit longer that the whole file, with -M it
would be empty.
Probably using -M hurts performance, so it should better be a config
option?
Below is a patch that hardcodes -M, I didn't check if there are more
places where it should be added.
What do you think?
Best regards
Uwe
[1] the following is a nice view:
gitk 070739fd351702ea9bb4f65595728ae25a488075 ^53a58245863eff3d70aaa3ac75d7d57e843fc91d^ ^e701ccc3883959b4ba5fada7a903e8e9eaddcba7
diff --git a/gitk b/gitk
index a57e84c..bcc4637 100755
--- a/gitk
+++ b/gitk
@@ -4240,7 +4240,7 @@ proc mergediff {id l} {
set diffids $id
# this doesn't seem to actually affect anything...
set env(GIT_DIFF_OPTS) $diffopts
- set cmd [concat | git diff-tree --no-commit-id --cc $id]
+ set cmd [concat | git diff-tree -M --no-commit-id --cc $id]
if {[catch {set mdf [open $cmd r]} err]} {
error_popup "Error getting merge diffs: $err"
return
--
Uwe Kleine-König
http://www.google.com/search?q=1+electron+mass%3D
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.5.2-rc3
From: Martin Waitz @ 2007-05-11 9:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, git
In-Reply-To: <7vtzukf0h6.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 632 bytes --]
hoi :)
On Thu, May 10, 2007 at 09:28:05PM -0700, Junio C Hamano wrote:
> Alexander Litvinov <litvinov2004@gmail.com> writes:
>
> >> * Plumbing level subproject support.
> > ...
> > Is there any help onhow to use subprojects ? I did not found anything at
> > Documentation/ directiory.
>
> Sorry, you are expecting too much.
Perhaps we should not advertise submodule support that prominently.
I think we should wait for nice porcelain support before can put it at
the top of the release announcements.
Otherwise we get much too many expectations and too many questions about
how to use it.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [BUG] git-svn dcommit fails (connection closed unexpectedly)
From: Matthieu Moy @ 2007-05-11 9:09 UTC (permalink / raw)
To: git; +Cc: Eric Wong
Hi,
I'm using git-svn, which usually works fine, but I occasionally get
this:
$ git-svn dcommit
A file1
A file2
Network connection closed unexpectedly: Connection closed unexpectedly at /path/to/git-svn line 401
$
The failure seems to depend on the commit's I'm pushing, since this is
reproducible when running several times "dcommit" for the same commit,
but the same command also usually works fine on the same repositories
(same git repo, same svn target).
The svn repository is accessed with svn+ssh://user@machine/path/.
exporting the patch, applying it to an svn checkout, and "svn commit"
works fine.
Let me know if I can provide any other usefull information for
debugging.
Thanks,
Debian etch (stable)
Reproducible with both git 1.5.1.1 and the latest from git:
$ git-svn --version
git-svn version 1.5.2.rc3.3.ge347 (svn 1.4.2)
--
Matthieu
^ permalink raw reply
* Re: Repo cleanup problem
From: Eugine Kosenko @ 2007-05-11 9:32 UTC (permalink / raw)
To: git
In-Reply-To: <vpqveezhjb0.fsf@bauges.imag.fr>
2007/5/11, Matthieu Moy <Matthieu.Moy@imag.fr>:
> Branch before the garbage commit. Then, you can use git-rebase to
> replay the correct history on top of your new branch. Note that
> git-rebase will break merging if you already used merge: it does not
> "move" your old commits to your new branch, it instead creates new
> commits with the same changes at the old ones, in the new branch.
>
> That's probably what you've done already.
Almost that. Unfortunately, this simple way causes unexpected
conflicts, so I need also to do sometimes 'git-checkout <tag> .' and
recommit the changes to force the process.
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.5.2-rc3
From: Lars Hjemli @ 2007-05-11 11:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alexander Litvinov, git
In-Reply-To: <7v1whnesyn.fsf@assigned-by-dhcp.cox.net>
On 5/11/07, Junio C Hamano <junkio@cox.net> wrote:
> Alexander Litvinov <litvinov2004@gmail.com> writes:
>
> > I have tried your test and found that cloning such repo does not clone
> > subprojects. Only empty dir 'sub' is being cloned.
>
> Yes, that is pretty much intentional. Having a link for higher
> layer tools can use (i.e. tree objects can contain 160000 mode
> "gitlinks" to subproject commit objects) while not considering
> such linkage part of the reachability is the whole point of
> plumbing level subproject support. It allows people not to
> download repositories of uninteresting subprojects. Higher
> layer tools such as clone/checkout/diff could be instructed
> (currently they cannot be, though) to recurse into subproject
> directories if the user wants to.
fwiw: I just released cgit 0.3, which includes a script
(submodules.sh) used to initialize, update and check status of
submodules. It uses the file .gitmodules to map between submodule path
and git repository url (cgit now uses git as a submodule).
You can clone the repo here:
git://hjemli.net/pub/git/cgit
just look at the files here:
http://hjemli.net/git/cgit/
--
larsh
^ permalink raw reply
* --stdin option for 'git log' [was FFmpeg considering GIT]
From: Marco Costalba @ 2007-05-11 11:13 UTC (permalink / raw)
To: Linus Torvalds
Cc: Johannes Schindelin, Shawn O. Pearce, Paul Mackerras,
Brett Schwarz, Karl Hasselstr?m, Junio C Hamano, Carl Worth,
Michael Niedermayer, Git Mailing List
On 5/8/07, Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> Well, we actually do have that. "git log" (or "git-rev-list") really does
> all the heavy lifting. The reason you can do things like "gitk --merge" is
> not because gitk itself has _any_ idea about anything, but because it just
> passes the arguments down to git-rev-list (and hopefully soon git log),
> which really does all the complex stuff.
>
To replace 'git rev-list' with 'git log' an important missing feature,
at least for me, is the support for '--stdin' option of 'git-rev-list'
that currently seems missing in 'git log'
I found this limit while trying to use 'git log' instead of 'git
rev-list'. The problem is that command line arguments could be very
long in some cases, typically when passing a list of sha's values (as
example all the branches sha). This happens of course when 'git log'
is run by script/applications not directly by the user.
Under Linux, command line arguments size limits are _normaly_ enough
(you could have problems for repository with hundreds of
tags/branches), but under *others* OS we are not so lucky.
So with '--stdin' you have an elegant solution to support any kind of
repository under any OS ignoring the platform limit on command line
length.
Marco
^ permalink raw reply
* Re: How to set git commit timestamp
From: Jakub Narebski @ 2007-05-11 10:58 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Shawn O. Pearce, git
In-Reply-To: <Pine.LNX.4.64.0705081328420.4167@racer.site>
On Tue, 8 May 2007, Johannes Schindelin wrote:
> On Mon, 7 May 2007, Shawn O. Pearce wrote:
>> Jakub Narebski <jnareb@gmail.com> wrote:
>>> By the way, is there fast-import version of git-quiltimport?
>>
>> No, and I don't think its easy. Isn't a quilt patchstack stored as a
>> series of patch files? So "importing" it into Git requires applying the
>> patch to the base tree, then writing that base tree to the ODB.
>> fast-import doesn't know how to run git-apply, though Junio and I did
>> kick it around (generally) a few months ago on #git.
>
> You'd have to pretend that all of these patches are branches. Well, in the
> end they are...
Or rather that patch _series_ are branches.
It would be also nice to have one of the patch management UI on top of git
like StGIT or Guilt (IIRC pg is no longer maintained) to import series
of patches as unapplied from Quilt (or from mbox/file).
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [FAQ?] Rationale for git's way to manage the index
From: Jakub Narebski @ 2007-05-11 11:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd518gkyo.fsf@assigned-by-dhcp.cox.net>
On Fri, 11 May 2007, Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> In the new version of git I *think* you can use "git add -u path/"
>
> I know you meant well, but next time could you please check the
> fact before speaking?
> if (i < argc)
> die("-u and explicit paths are incompatible");
> The list is getting more and more cluttered recently, perhaps
> which is a good sign that more new people are actually using
> git. Let's try to keep the signal quality of the messages on
> the list high.
I'm sorry I haven't checked this before writing, especially that
information in the synopsis contradict a bit the information in
the `-u' option description:
Documentation/git-add.txt:
SYNOPSIS
--------
'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] <file>...
-u::
Update all files that git already knows about. This is what
"git commit -a" does in preparation for making a commit.
I should have checked the facts before following the synopsis.
I think however that "git add -u dir/" could be quite useful; it is
not needed to have `-u' and explicit paths incompatibile. I wouldn't
change the fact that you can say "git add -u" and do not need
"git add -u ." (like in the case without `-u' switch: you need
"git add ." to 'add' all unignored files).
Below there is a patch which corrects synopsis for git add;
unless you want to go the route of allowing "git add -u dir/"...
-- >8 --
From: Jakub Narebski <jnareb@gmail.com>
Date: Fri, 11 May 2007 13:22:13 +0200
Subject: [PATCH] Documentation: Correct synopsis for git-add command
Change SYNOPISIS section of Documentation/git-add.txt to mark it
explicitely that "-u option and explicit paths are incompatible",
and that "add --interactive does not take any parameters".
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
Documentation/git-add.txt | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index ea27018..e5fc0da 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -7,7 +7,8 @@ git-add - Add file contents to the changeset to be committed next
SYNOPSIS
--------
-'git-add' [-n] [-v] [-f] [--interactive | -i] [-u] [--] <file>...
+'git-add' [-n] [-v] [-f] [-u | [--] <file>...]
+'git-add' (--interactive | -i)
DESCRIPTION
-----------
--
1.5.1.3
--
Jakub Narebski
Poland
^ permalink raw reply related
* Re: [BUG] git-svn dcommit fails (connection closed unexpectedly)
From: Lars Hjemli @ 2007-05-11 11:27 UTC (permalink / raw)
To: git, Eric Wong
In-Reply-To: <vpq7irfengj.fsf@bauges.imag.fr>
On 5/11/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
> Hi,
>
> I'm using git-svn, which usually works fine, but I occasionally get
> this:
>
> $ git-svn dcommit
> A file1
> A file2
> Network connection closed unexpectedly: Connection closed unexpectedly at /path/to/git-svn line 401
Is this happening if you dcommit a file in a new directory?
The reason I'm asking is that I see the same problem in that
situation, but my svn repo is on a windows box, accessed over
svn://url, so I just assumed it was a problem on the remote end (the
service dies). But the problem always goes away if I commit the new
directory using the svn client before doing git-svn dcommit again....
--
larsh
^ permalink raw reply
* Re: [BUG] git-svn dcommit fails (connection closed unexpectedly)
From: Lars Hjemli @ 2007-05-11 11:30 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git, Eric Wong
In-Reply-To: <8c5c35580705110427o4de686e8qdb37f6a2da0043e4@mail.gmail.com>
Hmm, your MUA fooled me to reply to the wrong people...
Can you please don't do this:
Mail-Followup-To: git <git@vger.kernel.org>, Eric Wong <normalperson@yhbt.net>
--
larsh
^ permalink raw reply
* Re: Merging commits together into a super-commit
From: Alex Riesen @ 2007-05-11 11:54 UTC (permalink / raw)
To: linux@horizon.com; +Cc: git, kernel-hacker
In-Reply-To: <20070510215515.3084.qmail@science.horizon.com>
On 10 May 2007 17:55:15 -0400, linux@horizon.com <linux@horizon.com> wrote:
> Er... why is everyone making this so complex?
>
> git checkout trunk # Switch to "trunk"
> git checkout branch . # Overwrite with "branch", but stay on "trunk"
> git commit
>
> Now branch is the same tree object as "branch", but without the history.
>
> Of course, you could be even nastier and di a direct
>
> git-commit-tree branch^{tree} -p HEAD < commit_message
>
And it is not enough. Authorship information is lost. And you
have to be damn sure the "branch" starts directly at HEAD,
otherwise everything HEAD..branch is lost. It is complex
if you want it right.
^ permalink raw reply
* Merging commits together into a super-commit
From: Eugine Kosenko @ 2007-05-11 12:41 UTC (permalink / raw)
To: git
In-Reply-To: <9909dee80705110537j7e6d1426p7723c110c0a2c667@mail.gmail.com>
2007/5/11, Alex Riesen <raa.lkml@gmail.com>:
> And it is not enough. Authorship information is lost.
If one dare to make such super-commit, he would be the author of the
whole couple of changes.
> And you have to be damn sure the "branch" starts directly at HEAD,
> otherwise everything HEAD..branch is lost. It is complex
> if you want it right.
I used to make git-rebase to add extra commits after this.
^ permalink raw reply
* Re: [BUG] git-svn dcommit fails (connection closed unexpectedly)
From: Matthieu Moy @ 2007-05-11 12:51 UTC (permalink / raw)
To: git
In-Reply-To: <8c5c35580705110427o4de686e8qdb37f6a2da0043e4@mail.gmail.com>
"Lars Hjemli" <lh@elementstorage.no> writes:
> On 5/11/07, Matthieu Moy <Matthieu.Moy@imag.fr> wrote:
>> Hi,
>>
>> I'm using git-svn, which usually works fine, but I occasionally get
>> this:
>>
>> $ git-svn dcommit
>> A file1
>> A file2
>> Network connection closed unexpectedly: Connection closed unexpectedly at /path/to/git-svn line 401
>
> Is this happening if you dcommit a file in a new directory?
There seem to be a correlation, yes. Usually, simple commits will work
fine, and when I do something complex with the filesystem, it breaks.
I don't remember all the cases where it broke, but at least, last
time, it was about a new file in a new directory, yes.
--
Matthieu
^ permalink raw reply
* Re: [PATCH] user-manual: Use "git config --global" instead of editing ~/.gitconfig
From: Nicolas Pitre @ 2007-05-11 13:22 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: Petr Baudis, Johan Herland, git
In-Reply-To: <20070511034653.GB26896@fieldses.org>
On Thu, 10 May 2007, J. Bruce Fields wrote:
> So while I'm not convinced of the value of consistency here, if we have
> to have consistency, I'd rather standardize on config-file-editing.
Why not simply providing both?
You can modify your config with the following commands:
...
Alternatively, you might edit your ~/.gitconfig directly as
well with the following content:
...
Wouldn't that be clearer? This way there is no confusion since it is
clear up front that both methods are equivalent, and the user can choose
between them.
For one, I prefer the git-config method even if I do edit source files
all day long. It just seems faster to me.
Nicolas
^ permalink raw reply
* Re: [PATCH] read-tree -m -u: avoid getting confused by intermediate symlinks.
From: Alex Riesen @ 2007-05-11 14:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vveezde8b.fsf@assigned-by-dhcp.cox.net>
On 5/11/07, Junio C Hamano <junkio@cox.net> wrote:
> @@ -268,6 +268,8 @@ static void unlink_entry(char *name)
> {
> char *cp, *prev;
>
> + if (has_symlink_leading_path(name))
> + return;
This can slow down the unlink case quiet considerably.
Maybe the symlink paths can be cached?
^ permalink raw reply
* Re: Build Failure: GIT-GUI-VARS
From: Brian Gernhardt @ 2007-05-11 14:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7v8xbwgkia.fsf@assigned-by-dhcp.cox.net>
On May 10, 2007, at 10:30 PM, Junio C Hamano wrote:
> I do not either, and obviously does not reproduce for me. Time
> for you to try "make -d" perhaps?
Sorry for the semi-coherent message. It started out as "we should
fix this" and I ended up going "why is it broken", all a little too
late at night. I'm also not used to debugging Makefiles.
And I figured it out (make -p actually was more useful than -d):
It's another issue with doing things before including config.mak. My
config.mak includes the "NO_TCLTK=y" line, which takes effect at
Makefile:485. But gitk-wish is getting included in OTHER_PROGRAMS at
Makefile:272. So gitk-wish gets included because NO_TCLTK isn't
defined at that point, but all the other rules involving gitk don't
get executed because they're after the NO_TCLTK definition.
I think we need to be including the config.mak much earlier in the
Makefile as this is not the first time issues like this have come up
for me. And they tend to be issues that only come up with specific
configurations and are therefore harder to track down. Things I can
see being an issue for people who put their options in config.mak:
149: ifeq ($(prefix),/usr)
224: ifdef WITH_P4IMPORT
271: ifndef NO_TCLTK # My issue today
279-285: ifndef {SHELL,PERL,PYTHON}_PATH
~~ Brian
^ 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