* Re: GIT - error: no such remote ref refs/heads/TestBranch
From: Junio C Hamano @ 2006-12-22 0:52 UTC (permalink / raw)
To: Peter Baumann; +Cc: git
In-Reply-To: <slrneokplo.nsf.Peter.B.Baumann@xp.machine.xx>
Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de>
writes:
> I'm also not so confident about mixing "add NEW files" with "updating
> the contents of already known files".
File boundaries do not matter ;-) You are adding contents.
Sometimes new contents are contained in a file that git already
knew about. Other times they are contained in a file that git
did not know about.
But that is a phylosophical answer, not a practical one, since
majority of the time (unless you are talking about the first few
weeks of a new project) you will be adding contents that happen
to be in the files git knows about.
I think the operation related but different from "git add ."
Carl talks about would be useful in practice. I do not know
what the option should be called.
"git add --modified"?
"git add --tracked"?
"git add --updated"?
It would work in the same way as the pre-commit step of "git
commit -a".
^ permalink raw reply
* Re: [PATCH 3/3] Don't crash during repack of a reflog with pruned commits.
From: Shawn Pearce @ 2006-12-22 0:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20061222004906.GC14789@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> If the user has been using reflog for a long time (e.g. since its
> introduction) then it is very likely that an existing branch's
> reflog may still mention commits which have long since been pruned
> out of the repository.
>
> Rather than aborting with a very useless error message during
> git-repack, pack as many valid commits as we can get from the
> reflog and let the user know that the branch's reflog contains
> already pruned commits. A future 'git reflog expire' (or whatever
> it finally winds up being called) can then be performed to expunge
> those reflog entries.
If its not obvious from the patch, this doesn't entirely fix the
problem.
Just because the commit has not been pruned does not mean that a blob
or tree referenced by that commit has not been pruned. Right now
I am missing 1 blob and cannot repack because of it.
At least with this series of 3 patches the error message resulting
from this one missing blob is clearer.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/3] Don't crash during repack of a reflog with pruned commits.
From: Shawn Pearce @ 2006-12-22 1:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vmz5g92h7.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > If the user has been using reflog for a long time (e.g. since its
> > introduction) then it is very likely that an existing branch's
> > reflog may still mention commits which have long since been pruned
> > out of the repository.
>
> I've thought about this issue when I did the repack/prune; my
> take on this was you should prune reflog first then repack.
OK, but we should suggest that to the user rather than just
cryptically saying 'fatal: bad object refs/heads/build'.
--
Shawn.
^ permalink raw reply
* Re: confusion over the new branch and merge config
From: Sean @ 2006-12-22 1:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, git
In-Reply-To: <7vvek492q1.fsf@assigned-by-dhcp.cox.net>
On Thu, 21 Dec 2006 16:46:46 -0800
Junio C Hamano <junkio@cox.net> wrote:
> You can always say "git log refs/heads/next" even though you are
> allowed to say "git log next". Maybe we should remove that
> shorthand to make it consistent? I think not.
Of course not. But why not add the shorthand to the other case
to make it consistent?
> The remote side can add things without your knowing, so
> insisting on the exact match makes sense in a weird sort of
> way.
I'm sure there are technical reasons why things are they way they
are, nothing weird about that. But looking in from the outside
and not knowing what those reasons are, leads to an honest
question if it's absolutely necessary for a user to have to learn
about the internal "refs/heads" directory structure of Git.
It would be nicer if they could just think in terms of branches
and tags.
> And this is a config file you would set once and then can forget
> about it. I do not see a big deal about having to spell it
> fully.
It's not a huge deal, it's just one more slightly unexpected thing
for a user to have to deal with in learning Git. It seems reasonable
for a user to be able to refer to a remote branch as "remote/branch",
and not "remote/refs/heads/branch". But if that simply can't be
accommodated, so be it.
Sean
^ permalink raw reply
* Re: [PATCH] Don't define _XOPEN_SOURCE on MacOSX and FreeBSD as it is too restricting
From: Shawn Pearce @ 2006-12-22 1:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Marco Roeland, Terje Sten Bjerkseth, Randal L. Schwartz,
Linus Torvalds, Rocco Rutte, git
In-Reply-To: <7v64c492fv.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> #0.5 Have you checked the tip of 'master' that has Terje's
> patch? It was reported to work yesterday and that is what
> was committed already.
OK, but that isn't applied in next for some reason. I'm still
carrying around my own version of Terje's patch. :-(
> #1 __APPLE__ vs __APPLE_CC__ is not something I can decide (I
> do not run a Mac). If MaxOS is derived from FreeBSD, does
> it by chance define __FreeBSD as well?
__FreeBSD doesn't work here on my Mac.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/3] Don't crash during repack of a reflog with pruned commits.
From: Jakub Narebski @ 2006-12-22 1:18 UTC (permalink / raw)
To: git
In-Reply-To: <20061222010018.GB14773@spearce.org>
Shawn Pearce wrote:
> Junio C Hamano <junkio@cox.net> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>>
>>> If the user has been using reflog for a long time (e.g. since its
>>> introduction) then it is very likely that an existing branch's
>>> reflog may still mention commits which have long since been pruned
>>> out of the repository.
>>
>> I've thought about this issue when I did the repack/prune; my
>> take on this was you should prune reflog first then repack.
>
> OK, but we should suggest that to the user rather than just
> cryptically saying 'fatal: bad object refs/heads/build'.
I still think it is a good idea to allow user (experienced user)
to set to not consider reflog for saving. Especially that there
exist repositories which have reflogs with long pruned commits,
and it would be nice to preserve the reflog info, even if some of
information is not available.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 3/3] Don't crash during repack of a reflog with pruned commits.
From: Shawn Pearce @ 2006-12-22 1:23 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <emfbk4$f45$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> wrote:
> I still think it is a good idea to allow user (experienced user)
> to set to not consider reflog for saving. Especially that there
> exist repositories which have reflogs with long pruned commits,
> and it would be nice to preserve the reflog info, even if some of
> information is not available.
In my humble opinion there is *no* value in a reflog whose commits
are "corrupt" (due to missing commit object or missing tree/blob
it references) as you cannot get that commit back. And its hard
to get any other data from it.
My local git.git repository got killed during a repack because
I was missing 1 blob (an old version of builtin-blame.c) from
Junio's pu branch. Apparently I had a reflog on that tracking
branch which went back pretty far and although the commits in that
log were still available, the blob wasn't.
--
Shawn.
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Carl Worth @ 2006-12-22 1:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Francis Moreau, Jay Cliburn, git, Jeff Garzik
In-Reply-To: <Pine.LNX.4.64.0612211013500.3394@woody.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 1685 bytes --]
On Thu, 21 Dec 2006 10:23:30 -0800 (PST), Linus Torvalds wrote:
> In short, for git diff (and ONLY) git diff, all of these are the same:
>
> git diff a..b
> git diff a b
I admit that I had had never passed a range of commits to git diff,
nor even given any thought to what it might do, but I definitely find
the above very surprising---and not necessarily very useful. Why is
anyone ever typing those two dots here if they have no effect on the
result?
> It basically all boils down to:
>
> "git diff" is special
>
> exactly because unlike almost ALL other git commands, "git diff" does not
> work on a _list_ of commits, it only works on two end-points. That means
> that the "list operations" actually end up meaning something else for git
> diff than they do for "git log" and friends.
Yes, "git diff" can only work on two end points. So a command like:
git diff a b
is really easy to understand. And if the user wants to compare those
two points, why would the user ever provide them with any other
syntax?
In other words, what's the advantage of "git diff" accepting a special
syntax for a range ("a..b") and yet not actually doing anything
special with it?
In particular, the operation that would be interesting here is what
one can get with:
git diff $(git merge-base a b) b
so why isn't _that_ the operation that is accessed with the syntax of:
git diff a..b
Said another way, if "git log a..b" displays a range of commits, why
doesn't "git diff a..b" display the diff from the beginning of that
range to the end?
Of course, all the warnings you gave about what "git diff" would do
in the case of various criss-cross merge scenarios would still apply.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: git-svn throwing assertion on old svn tracking branch
From: Nicolas Vilz @ 2006-12-22 1:35 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061221010520.GB3901@localdomain>
On Wed, Dec 20, 2006 at 05:05:20PM -0800, Eric Wong wrote:
> Nicolas Vilz <niv@iaglans.de> wrote:
> > hello guys,
> >
> > it has been a while, i tried git in conjunction with svn... i got a nice
> > history, when working with it. This Work is now a year old.
> >
> > Now I wanted to get on working and got following error message while
> > fetching from one specific svn tracking branch:
> >
> > $ git-svn fetch -i svn_master
> > perl: subversion/libsvn_subr/path.c:343: svn_path_remove_component:
> > Assertion `is_canonical(path->data, path->len)' failed.
> > Aborted
>
> I don't recall seeing that error before.
>
> Are you using the command-line client or the perl SVN libraries? If
> you're using the command-line client, you may want to try:
> rm -rf .git/svn/svn_master/tree && git-svn rebuild -i svn_master
>
> > I checked the svn working copy, it is uptodate now (although i had to
> > search for it, i havent been using this repository for one year...)
>
> Does the directory you're tracking the the repository still
> exist? If it disappeared, git-svn could have some issues with it
> (regardless of command-line or SVN libraries).
The repository i am tracking does still exist. both, the tree and the
repository are on the same revision-number, so i am a bit clueless.
I tried a fresh fetch of this repository, it worked. so it shouldn't be
a client-server version mismatch..
I also tried
rm -rf .git/svn/svn_master/tree && git-svn rebuild -i svn_master
this had no effect to git-svn fetch -i svn_master... i get the very same
error message...
I didn't alter there anything, so i think, fetching works, but if
nothing is there to fetch, there is the initial error message...
beneath there is svn, version 1.4.2 (r22196) ... on that repository is
Subversion version 1.1.4 (r13838).
Nicolas Vilz
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Kyle Moffett @ 2006-12-22 1:44 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Randal L. Schwartz, Linus Torvalds, Nicolas Pitre, git
In-Reply-To: <46a038f90612181502y3e2a41cds7f16113ad0270f31@mail.gmail.com>
On Dec 18, 2006, at 18:02:07, Martin Langhoff wrote:
> On 18 Dec 2006 14:26:36 -0800, Randal L. Schwartz
> <merlyn@stonehenge.com> wrote:
>> Linus Torvalds wrote:
>>> You're running this under OS X, aren't you? It's a pig of an OS,
>>> but "almost one hour" vs "25 seconds" is still unreasonable.
>>
>> I agree!
>
> Me too -- but entirely possible. Disk IO is specially painful on
> OSX. Stat calls are horrid. Using Arch (which abused stat calls to
> no end) many ops would take 50x-100x longer on OSX than on Linux. A
> large unpacked repo with git is a real pain -- and packing it can
> take hours.
I've actually also seen filesystem operation latency double or triple
if you start trying to do operations from multiple threads at once.
Suddenly the already dog-slow single-CPU operations start bouncing
caches and the Mac OS X mostly-whole-of-BSD-BKL across CPUs and it
just crawls. I can definitely see the local disk IO taking 100x
longer than the network I/O, especially with an 8-megabit internet link.
> Once you are packed it's sweet, but large repos are a pain to deal
> with. You won't impress anyone with performance over a linux kernel
> repo -- starting up gitk can take a long time. Stat-heavy stuff
> like git-diff is noticeably slower under OSX.
Just as an example, it takes my OS-X-running Quad-2.5GHz G5 ten times
as long to do a "grep -rl foo linux/" as my Linux-running dual-1GHz
G4 with 400MHz system bus. This is disk-cache-hot too. And that's
not even a stat-heavy workload. There's more than one reason I'm
trying to make a Mac OS X ABI emulation layer on top of Linux :-D.
Cheers,
Kyle Moffett
^ permalink raw reply
* Re: cloning the kernel - why long time in "Resolving 313037 deltas"
From: Shawn Pearce @ 2006-12-22 1:56 UTC (permalink / raw)
To: Kyle Moffett
Cc: Martin Langhoff, Randal L. Schwartz, Linus Torvalds,
Nicolas Pitre, git
In-Reply-To: <991F50E2-2C98-4710-84C5-3D7348E00B64@mac.com>
Kyle Moffett <mrmacman_g4@mac.com> wrote:
> Just as an example, it takes my OS-X-running Quad-2.5GHz G5 ten times
> as long to do a "grep -rl foo linux/" as my Linux-running dual-1GHz
> G4 with 400MHz system bus. This is disk-cache-hot too. And that's
> not even a stat-heavy workload. There's more than one reason I'm
> trying to make a Mac OS X ABI emulation layer on top of Linux :-D.
Try 'git grep foo' instead; its very fast if you are working with
a fully packed Git repository.
Doesn't help any other application on Mac OS X however. :-(
--
Shawn.
^ permalink raw reply
* Re: git-svn throwing assertion on old svn tracking branch
From: Nicolas Vilz @ 2006-12-22 2:16 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20061222013510.GA9595@hermes>
On Fri, Dec 22, 2006 at 02:35:10AM +0100, Nicolas Vilz wrote:
> On Wed, Dec 20, 2006 at 05:05:20PM -0800, Eric Wong wrote:
> > Nicolas Vilz <niv@iaglans.de> wrote:
[...]
>
> The repository i am tracking does still exist. both, the tree and the
> repository are on the same revision-number, so i am a bit clueless.
>
> I tried a fresh fetch of this repository, it worked. so it shouldn't be
> a client-server version mismatch..
>
> I also tried
>
> rm -rf .git/svn/svn_master/tree && git-svn rebuild -i svn_master
>
> this had no effect to git-svn fetch -i svn_master... i get the very same
> error message...
>
> I didn't alter there anything, so i think, fetching works, but if
> nothing is there to fetch, there is the initial error message...
>
> beneath there is svn, version 1.4.2 (r22196) ... on that repository is
> Subversion version 1.1.4 (r13838).
i should ammend, that the same error message comes, when i want to
dcommit something in this repository...
^ permalink raw reply
* [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree
From: Johannes Schindelin @ 2006-12-22 2:19 UTC (permalink / raw)
To: git, junkio
If the cache tree is not up-to-date, it will be updated first. So, now
$ git show :Documentation/
will in effect show what files/directories are in the index' version
of the directory Documentation. The three commands
$ git show :./
$ git show :.
$ git show :
are all equivalent and show the index' idea of the root directory.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
sha1_name.c | 24 +++++++++++++++++++++++-
1 files changed, 23 insertions(+), 1 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 6d7cd78..e3758cc 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -5,6 +5,7 @@
#include "blob.h"
#include "tree-walk.h"
#include "refs.h"
+#include "cache-tree.h"
static int find_short_object_filename(int len, const char *name, unsigned char *sha1)
{
@@ -532,7 +533,7 @@ int get_sha1(const char *name, unsigned char *sha1)
*/
if (name[0] == ':') {
int stage = 0;
- struct cache_entry *ce;
+ struct cache_entry *ce = NULL;
int pos;
if (namelen < 3 ||
name[2] != ':' ||
@@ -561,6 +562,27 @@ int get_sha1(const char *name, unsigned char *sha1)
}
pos++;
}
+ if (namelen > 0 && cp[namelen - 1] == '/')
+ namelen--;
+ if (namelen == 1 && cp[0] == '.') {
+ namelen = 0;
+ cp = "";
+ }
+ if (namelen == 0 || (ce && ce_namelen(ce) > namelen &&
+ ce->name[namelen] == '/' &&
+ !memcmp(ce->name, cp, namelen))) {
+ struct cache_tree *tree =
+ cache_tree_find(active_cache_tree, cp);
+ if (!cache_tree_fully_valid(tree)) {
+ ret = cache_tree_update(active_cache_tree,
+ active_cache, active_nr, 0, 0);
+ if (ret < 0)
+ return ret;
+ tree = cache_tree_find(active_cache_tree, cp);
+ }
+ hashcpy(sha1, tree->sha1);
+ return 0;
+ }
return -1;
}
for (cp = name, bracket_depth = 0; *cp; cp++) {
--
1.4.4.2.ga854-dirty
^ permalink raw reply related
* [PATCH] diff --check: fix off by one error
From: Johannes Schindelin @ 2006-12-22 2:20 UTC (permalink / raw)
To: git, junkio
When parsing the diff line starting with '@@', the line number of the
'+' file is parsed. For the subsequent line parses, the line number
should therefore be incremented after the parse, not before it.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
diff.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/diff.c b/diff.c
index 26916c3..ba6bd59 100644
--- a/diff.c
+++ b/diff.c
@@ -874,8 +874,6 @@ static void checkdiff_consume(void *priv, char *line, unsigned long len)
if (line[0] == '+') {
int i, spaces = 0;
- data->lineno++;
-
/* check space before tab */
for (i = 1; i < len && (line[i] == ' ' || line[i] == '\t'); i++)
if (line[i] == ' ')
@@ -890,6 +888,8 @@ static void checkdiff_consume(void *priv, char *line, unsigned long len)
if (isspace(line[len - 1]))
printf("%s:%d: white space at end: %.*s\n",
data->filename, data->lineno, (int)len, line);
+
+ data->lineno++;
} else if (line[0] == ' ')
data->lineno++;
else if (line[0] == '@') {
--
1.4.4.2.ga854-dirty
^ permalink raw reply related
* [PATCH] Use git-merge-file in git-merge-one-file, too
From: Johannes Schindelin @ 2006-12-22 2:20 UTC (permalink / raw)
To: git, junkio
Would you believe? I edited git-merge-one-file (note the missing ".sh"!)
when I submitted the patch which became commit e2b7008752...
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
git-merge-one-file.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/git-merge-one-file.sh b/git-merge-one-file.sh
index c49e4c6..7d62d79 100755
--- a/git-merge-one-file.sh
+++ b/git-merge-one-file.sh
@@ -104,7 +104,7 @@ case "${1:-.}${2:-.}${3:-.}" in
# Be careful for funny filename such as "-L" in "$4", which
# would confuse "merge" greatly.
src1=`git-unpack-file $2`
- merge "$src1" "$orig" "$src2"
+ git-merge-file "$src1" "$orig" "$src2"
ret=$?
# Create the working tree file, using "our tree" version from the
--
1.4.4.2.gd74c-dirty
^ permalink raw reply related
* [PATCH] Suggest 'add' in am/revert/cherry-pick.
From: Shawn O. Pearce @ 2006-12-22 2:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Now that we have decided to make 'add' behave like 'update-index'
(and therefore fully classify update-index as strictly plumbing)
the am/revert/cherry-pick family of commands should not steer the
user towards update-index. Instead send them to the command they
probably already know, 'add'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-am.sh | 4 ++--
git-revert.sh | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 5df6787..0126a77 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -401,14 +401,14 @@ do
changed="$(git-diff-index --cached --name-only HEAD)"
if test '' = "$changed"
then
- echo "No changes - did you forget update-index?"
+ echo "No changes - did you forget to use 'git add'?"
stop_here_user_resolve $this
fi
unmerged=$(git-ls-files -u)
if test -n "$unmerged"
then
echo "You still have unmerged paths in your index"
- echo "did you forget update-index?"
+ echo "did you forget to use 'git add'?"
stop_here_user_resolve $this
fi
apply_status=0
diff --git a/git-revert.sh b/git-revert.sh
index 6eab3c7..50cc47b 100755
--- a/git-revert.sh
+++ b/git-revert.sh
@@ -155,7 +155,7 @@ Conflicts:
uniq
} >>"$GIT_DIR/MERGE_MSG"
echo >&2 "Automatic $me failed. After resolving the conflicts,"
- echo >&2 "mark the corrected paths with 'git-update-index <paths>'"
+ echo >&2 "mark the corrected paths with 'git-add <paths>'"
echo >&2 "and commit the result."
case "$me" in
cherry-pick)
--
1.4.4.3.g87d8
^ permalink raw reply related
* Separating "add path to index" from "update content in index"
From: Carl Worth @ 2006-12-22 2:32 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Peter Baumann, git
In-Reply-To: <7vbqlw92fw.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 5661 bytes --]
On Thu, 21 Dec 2006 16:52:51 -0800, Junio C Hamano wrote:
> Peter Baumann <Peter.B.Baumann@stud.informatik.uni-erlangen.de> writes:
> > I'm also not so confident about mixing "add NEW files" with "updating
> > the contents of already known files".
>
> File boundaries do not matter ;-) You are adding contents.
I don't follow.
There's more than just content here. The index contains a list of
paths as well, and a command like "commit -a" iterates over that
list. The addition or removal of a path from that list is a conceptual
notion that's very important to the user and the kinds of thing a user
does on a regular basis.
> But that is a phylosophical answer, not a practical one, since
> majority of the time (unless you are talking about the first few
> weeks of a new project) you will be adding contents that happen
> to be in the files git knows about.
I don't think it's practical to write off addition of new paths as
unimportant or uncommon except in the beginning of projects. Projects
grow new functionality and files get added. Code gets refactored and
files get renamed. The addition or removal of paths from the index is
just as important an operation as changing content of existing paths.
And I still think there are remaining interface problems that git has
in this area. For example, my most common sequence of operations when
hacking code is as follows:
# edit files
git diff # to review what I've done
git commit -a # to record it
Recently, I did some edits and also added some new files. I did:
# edit files and make new ones
git diff # only edits appear here
Hmm... did I forget to add those new files?
git add new-file.c
git diff # still only shows the edits
At this point I can exercise my git mental muscles and know that "add"
shoves stuff into the index so what I really want is:
git diff HEAD # shows edits and new file contents
Regardless of how hard those git muscles may be to come by---I still
don't like having to exercise them here.
I complained about this when I first encountered git, and back then I
said what I thought I wanted was "git diff HEAD" by default. I was
totally wrong, since diff from the index is so obviously correct for
resolving a conflict. Junio even responded to my complaints by
providing a new "git status -v -a" but frankly I've never used
it. That's awful awkward to use when "git diff" is so easy to type and
_most_ of the time is exactly what I want.
I'd really like "git diff" to be what I want more often. So what I'd
like is to be able to get the index in such a state that typing "git
diff" like I always do would show me everything I just typed,
(regardless of whether it was in files that git had seen before or
not).
So, I think what I really want here is a complete separation in the
interface between adding a path to the index and updating content into
the index.
We've long had a command that updates content to the index, and it
takes a command-line option (--add) to allow it to first do the
necessary path addition as well. The symmetry I would like is if we
had a command, ("git add", say), that just did the path addition and
could accept a command-line option (--update, say) to get it to the
the updating of the content as well.
And I think that any talk about "git cannot accept a file name without
content" is misplaced. The proposal here does not change any internal
models of git. I'm talking about an interface issue, and if the
interface isn't helping the user then it's wrong. That "git diff"
usually shows me what I've just typed but I can't (easily[*]) get it
to do that when I'm adding a new file is really annoying.
[*] Well, I could get it to do that by carefully creating the file,
running "git add" immediately, and only _then_ going on to type
content into the file. But that's not how I work. I do a bunch of file
manipulations without thinking about git at all, and then when I'm
happy with that, only then do I want to turn to git and use "git add",
"git diff", and "git commit" to get the results I want.
So I suppose I could implement the "add path without updating content"
I want by doing something like:
mv file file.tmp
touch file
git update-index --add file
mv file.tmp file
There. That gives me the result I want without breaking any git
internals, (since I'm just building a new operation on top of existing
git primitives).
> Carl talks about would be useful in practice. I do not know
> what the option should be called.
>
> "git add --modified"?
> "git add --tracked"?
> "git add --updated"?
>
> It would work in the same way as the pre-commit step of "git
> commit -a".
I think the best would be:
git update-index --all
which would still allow room for:
git add --all
as a consistent way to get at the current behavior of "git add .".
So here I'm arguing against "git add" being a more convenient synonym
for "git update-index". I still think it would be nice to have a more
convenient synonym. I've proposed "stage" before but that wasn't well
accepted. Just shortening "update-index" to "update" would be
problematic as many other RCSs use "update" as a way of picking up new
content that has become available on the remote end. So, the best
suggestion I have at this point is "refresh". So I'd be happy if
either:
git refresh --add
or:
git add --refresh
would provide the behavior that currently is provided by "git add",
(that is, add a new path to the index and update the content of that
path in the index from the content of the named file in the working
tree). But it would be great if "git add" without the --refresh would
add the path without updating the content.
-Carl
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: t5000-tar-tree.sh failing
From: Johannes Schindelin @ 2006-12-22 2:48 UTC (permalink / raw)
To: Uwe Kleine-Koenig; +Cc: Brian Gernhardt, git
In-Reply-To: <20061221185948.GA27072@informatik.uni-freiburg.de>
Hi,
On Thu, 21 Dec 2006, Uwe Kleine-Koenig wrote:
> I'm not sure if (in this case) a missing unzip should be as silent as
> you suggest. The danger is, that s.o. makes a change, runs `make test`
> and is then conviced that nothing broke.
Well, the tests are not distributed with the binary packages. For a
reason. The maintainer of the binary packages has to check if the tests
succeed. An she better know what she's doing!
So, if Joe Average compiles git, does not have unzip installed, and runs
the tests, chances are that he does not want to be bothered about the zip
tests failing because of the absence of unzip.
> So I think that the test should fail, but with a more descriptive error
> than it is now.
Sorry. Does not work here. I _only_ look at the messages if the test suite
fails somewhere, with a loud error message at the end.
Ciao,
Dscho
^ permalink raw reply
* Re: Separating "add path to index" from "update content in index"
From: Sean @ 2006-12-22 3:06 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Peter Baumann, git
In-Reply-To: <87d56cirs8.wl%cworth@cworth.org>
On Thu, 21 Dec 2006 18:32:55 -0800
Carl Worth <cworth@cworth.org> wrote:
> So here I'm arguing against "git add" being a more convenient synonym
> for "git update-index". I still think it would be nice to have a more
> convenient synonym. I've proposed "stage" before but that wasn't well
> accepted. Just shortening "update-index" to "update" would be
> problematic as many other RCSs use "update" as a way of picking up new
> content that has become available on the remote end. So, the best
> suggestion I have at this point is "refresh". So I'd be happy if
> either:
>
> git refresh --add
> or:
> git add --refresh
>
> would provide the behavior that currently is provided by "git add",
> (that is, add a new path to the index and update the content of that
> path in the index from the content of the named file in the working
> tree). But it would be great if "git add" without the --refresh would
> add the path without updating the content.
The end result you're trying to achieve is worthwhile, but it seems the
new git add capabilities have already taken root. What do you think
about accepting the new behavior of add, but offer a new command, say:
$ git track-file <file>
Which would do exactly as you propose in your email, add the path to
the index with empty content?
Sean
^ permalink raw reply
* Re: [PATCH] fix vc git
From: Duncan Mak @ 2006-12-22 4:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcvo92fx.fsf@assigned-by-dhcp.cox.net>
I don't think vc-git-registered-file will ever be called with a
filename without a directory, as it is used as a hook on
vc-next-action, which works on a real file.
Either way, it's a modified patch:
Fix vc-git.el to not cd into a non-existent directory.
---
contrib/emacs/vc-git.el | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
base c902c9a608c1b727160d6fbb04fa363d9418cd00
last 96e9944b714094ab81f8091711a92506886b8004
diff --git a/contrib/emacs/vc-git.el b/contrib/emacs/vc-git.el
index 8b6361922fd6e6a2fcd9acb20fd54f5b645b36f0..668bd4a98653046aadf91e7a91af6cd76ba044d4
100644
--- a/contrib/emacs/vc-git.el
+++ b/contrib/emacs/vc-git.el
@@ -58,7 +58,7 @@
(with-temp-buffer
(let* ((dir (file-name-directory file))
(name (file-relative-name file dir)))
- (when dir (cd dir))
+ (when (and dir (file-exists-p dir)) (cd dir))
(and (ignore-errors (eq 0 (call-process "git" nil '(t nil) nil
"ls-files" "-c" "-z" "--" name)))
(let ((str (buffer-string)))
(and (> (length str) (length name))
--
1.4.4.1
^ permalink raw reply
* Re: Updated Kernel Hacker's guide to git
From: Linus Torvalds @ 2006-12-22 4:13 UTC (permalink / raw)
To: Carl Worth; +Cc: Francis Moreau, Jay Cliburn, git, Jeff Garzik
In-Reply-To: <87slf83erg.wl%cworth@cworth.org>
On Thu, 21 Dec 2006, Carl Worth wrote:
>
> On Thu, 21 Dec 2006 10:23:30 -0800 (PST), Linus Torvalds wrote:
> > In short, for git diff (and ONLY) git diff, all of these are the same:
> >
> > git diff a..b
> > git diff a b
>
> I admit that I had had never passed a range of commits to git diff,
> nor even given any thought to what it might do, but I definitely find
> the above very surprising---and not necessarily very useful. Why is
> anyone ever typing those two dots here if they have no effect on the
> result?
I do it all the time, I never even use the old-fashioned syntax any more.
It's much more concise and easy to read, and it has all the nice shortcuts
(like empty meaning "HEAD", so you can do "git diff ..next" to see the
diff from HEAD to another branch).
It's also useful exactly because of the semantics of things like "...".
In other words, sure, "git diff a b" works, but it just _looks_ more
pleasing to use "a..b" and you mentally always pronounce the ".." as "to".
So "git diff a b" doesn't even look good to me any more, because it's
literally missing that mental "to" that the ".." adds for me when I read
it.
Linus
^ permalink raw reply
* Re: [PATCH] sha1_name(): accept ':directory/' to get at the cache_tree
From: Junio C Hamano @ 2006-12-22 4:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, junkio
In-Reply-To: <Pine.LNX.4.63.0612220318320.19693@wbgn013.biozentrum.uni-wuerzburg.de>
(1) Why is this needed?
(2) What does this do when the index is unmerged?
^ permalink raw reply
* Re: [PATCH] fix vc git
From: Junio C Hamano @ 2006-12-22 4:54 UTC (permalink / raw)
To: Duncan Mak; +Cc: git
In-Reply-To: <8e745ecf0612212011q26f81d91uce143b4212fc5e8b@mail.gmail.com>
"Duncan Mak" <duncan@a-chinaman.com> writes:
> I don't think vc-git-registered-file will ever be called with a
> filename without a directory, as it is used as a hook on
> vc-next-action, which works on a real file.
I am showing my ignorance, but
(1) if it works on a real file then can it ever give you a file
that is in nonexisting directory?
(2) when it works on a file at the root level of the project
tree, say, just "Makefile" wouldn't dir which is the result
of (file-name-directory file) be sometimes nil? I suspect
that is the reason of the original (when dir ...)
In either case, your change would not break anything. I am just
being curious.
^ permalink raw reply
* Re: Separating "add path to index" from "update content in index"
From: Nicolas Pitre @ 2006-12-22 5:06 UTC (permalink / raw)
To: Carl Worth; +Cc: Junio C Hamano, Peter Baumann, git
In-Reply-To: <87d56cirs8.wl%cworth@cworth.org>
On Thu, 21 Dec 2006, Carl Worth wrote:
> So, I think what I really want here is a complete separation in the
> interface between adding a path to the index and updating content into
> the index.
Strangely enough I think this separation is unnecessary and redundent.
> We've long had a command that updates content to the index, and it
> takes a command-line option (--add) to allow it to first do the
> necessary path addition as well.
And it is still there.
> The symmetry I would like is if we
> had a command, ("git add", say), that just did the path addition and
> could accept a command-line option (--update, say) to get it to the
> the updating of the content as well.
And you can do just that with git-update-index.
> And I think that any talk about "git cannot accept a file name without
> content" is misplaced. The proposal here does not change any internal
> models of git. I'm talking about an interface issue, and if the
> interface isn't helping the user then it's wrong. That "git diff"
> usually shows me what I've just typed but I can't (easily[*]) get it
> to do that when I'm adding a new file is really annoying.
The problem lies with the git-diff interface then, not git-add.
> [*] Well, I could get it to do that by carefully creating the file,
> running "git add" immediately, and only _then_ going on to type
> content into the file. But that's not how I work. I do a bunch of file
> manipulations without thinking about git at all, and then when I'm
> happy with that, only then do I want to turn to git and use "git add",
> "git diff", and "git commit" to get the results I want.
>
> So I suppose I could implement the "add path without updating content"
> I want by doing something like:
>
> mv file file.tmp
> touch file
> git update-index --add file
> mv file.tmp file
>
> There. That gives me the result I want without breaking any git
> internals, (since I'm just building a new operation on top of existing
> git primitives).
>
> > Carl talks about would be useful in practice. I do not know
> > what the option should be called.
> >
> > "git add --modified"?
> > "git add --tracked"?
> > "git add --updated"?
> >
> > It would work in the same way as the pre-commit step of "git
> > commit -a".
>
> I think the best would be:
>
> git update-index --all
>
> which would still allow room for:
>
> git add --all
>
> as a consistent way to get at the current behavior of "git add .".
There is no consistency needed between git-add and git-update-index.
The first is for users while the second is more suited for scripting
your own interface.
> So here I'm arguing against "git add" being a more convenient synonym
> for "git update-index". I still think it would be nice to have a more
> convenient synonym. I've proposed "stage" before but that wasn't well
> accepted. Just shortening "update-index" to "update" would be
> problematic as many other RCSs use "update" as a way of picking up new
> content that has become available on the remote end. So, the best
> suggestion I have at this point is "refresh". So I'd be happy if
> either:
>
> git refresh --add
> or:
> git add --refresh
>
> would provide the behavior that currently is provided by "git add",
> (that is, add a new path to the index and update the content of that
> path in the index from the content of the named file in the working
> tree). But it would be great if "git add" without the --refresh would
> add the path without updating the content.
I think you are trying to solve the wrong problem, or at least solve a
problem the wrong way. The problem is that git-diff doesn't give you
the output you expect because of the index interfering in your work
flow. And I understand that.
But the best solution is really for git-diff to have a mode where you
could display a diff between the work tree and the index, _or_ the index
and HEAD, for each file listed in the index while giving priority to the
former.
This would let you see a diff of everything that would be committed,
including new files, if you were to do commit -a. Maybe -a/--all should
be used with git-diff for such a mode by symetry with git-commit -a. (OK
-a is already taken but I doubt it is really used and it already has a
longer equivalent so changing it would not do real harm).
With this, for users acustomed to "commit -a", the natural and pretty
consistent way to see a diff for such a commit before actually
performing it would bi "diff -a". Isn't it logical?
Nicolas
^ permalink raw reply
* Re: Separating "add path to index" from "update content in index"
From: Junio C Hamano @ 2006-12-22 5:10 UTC (permalink / raw)
To: Carl Worth; +Cc: Peter Baumann, git
In-Reply-To: <87d56cirs8.wl%cworth@cworth.org>
Carl Worth <cworth@cworth.org> writes:
> I complained about this when I first encountered git, and back then I
> said what I thought I wanted was "git diff HEAD" by default. I was
> totally wrong, since diff from the index is so obviously correct for
> resolving a conflict. Junio even responded to my complaints by
> providing a new "git status -v -a" but frankly I've never used
> it.
I guess my responding to whatever you said was wasted effort,
and if you do not like "git add" this time, I should not be
surprised. That's kind of sad ;-).
Jokes aside.
I do not remember who advocated for making "git status" the
preview of "git commit" to happen. Was that also you? I wonder
how many people use this form:
git status -v path1 path2...
Because if even somebody who wanted to have "commit preview" in
"git status" does not use it for that intended purpose, I think
we can reuse the good command name for something more useful,
such as "git explain".
> I'd really like "git diff" to be what I want more often.
Running diff with index is what I do almost all the time. I
think "more often" is different from person to person, but if
"git diff" says nothing on a file that I know I added (and you
cannot argue you do not remember it was a new file here --- you
know you added it and that is why you are complaining about not
seeing it), I'd be happy that I did not accidentally edited it
to munge what I added -- because I add a file only when it is in
a presentable, good state, in a good enough shape to take a
snapshot (not necessarily good enough to commit, though).
And it is not just limited to adding the contents of a path that
happened to be told git for the first time. Adding the contents
of a path that was known to git also happens only when it is in
a presentable good state. So running "git diff" and not seeing
what I added before is a GOOD THING.
> So I suppose I could implement the "add path without updating content"
> I want by doing something like:
>
> mv file file.tmp
> touch file
> git update-index --add file
> mv file.tmp file
>
> There. That gives me the result I want without breaking any git
> internals, (since I'm just building a new operation on top of existing
> git primitives).
Sure, what you want is "git add --no-add newfile", and I can
understand that mode of operation if you are always going to
commit with "git commit -a". Maybe we can have a config
variable that makes "commit -a" and "add --no-add" the default
for these two commands, and we do not have to change anything
else.
One minor detail I wonder about is what mode bits would you give
to that placeholder entry.
> I think the best would be:
>
> git update-index --all
>
> which would still allow room for:
>
> git add --all
Wasn't it you who said "all" is ambiguous (all known to git vs
all in this directory)?
^ 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