* [PATCH 2/5] Change order of -m option to update-ref.
From: Shawn Pearce @ 2006-05-19 9:15 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
The actual position doesn't matter but most people prefer to see
options appear before the arguments.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/git-update-ref.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
75d5d46e9d911ab657af3c2eef9b585ac6a36b18
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index dfbd886..e062030 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -7,7 +7,7 @@ git-update-ref - update the object name
SYNOPSIS
--------
-'git-update-ref' <ref> <newvalue> [<oldvalue>] [-m <reason>]
+'git-update-ref' [-m <reason>] <ref> <newvalue> [<oldvalue>]
DESCRIPTION
-----------
--
1.3.2.g7278
^ permalink raw reply related
* [PATCH 3/5] Include ref log detail in commit, reset, etc.
From: Shawn Pearce @ 2006-05-19 9:16 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
When updating a ref at the direction of the user include a reason why
head was changed as part of the ref log (assuming it was enabled).
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
git-am.sh | 2 +-
git-applypatch.sh | 2 +-
git-branch.sh | 2 +-
git-commit.sh | 3 ++-
git-reset.sh | 2 +-
5 files changed, 6 insertions(+), 5 deletions(-)
2a83d6835922e222caadf03b25ebc72e773291ff
diff --git a/git-am.sh b/git-am.sh
index 97ec2d0..4232e27 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -413,7 +413,7 @@ do
parent=$(git-rev-parse --verify HEAD) &&
commit=$(git-commit-tree $tree -p $parent <"$dotest/final-commit") &&
echo Committed: $commit &&
- git-update-ref HEAD $commit $parent ||
+ git-update-ref -m "am: $SUBJECT" HEAD $commit $parent ||
stop_here $this
if test -x "$GIT_DIR"/hooks/post-applypatch
diff --git a/git-applypatch.sh b/git-applypatch.sh
index 12cab1e..e4b0947 100755
--- a/git-applypatch.sh
+++ b/git-applypatch.sh
@@ -204,7 +204,7 @@ echo Wrote tree $tree
parent=$(git-rev-parse --verify HEAD) &&
commit=$(git-commit-tree $tree -p $parent <"$final") || exit 1
echo Committed: $commit
-git-update-ref HEAD $commit $parent || exit
+git-update-ref -m "applypatch: $SUBJECT" HEAD $commit $parent || exit
if test -x "$GIT_DIR"/hooks/post-applypatch
then
diff --git a/git-branch.sh b/git-branch.sh
index 134e68c..d1e3730 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -117,4 +117,4 @@ then
die "cannot force-update the current branch."
fi
fi
-git update-ref "refs/heads/$branchname" $rev
+git update-ref -m "branch: Created from $head" "refs/heads/$branchname" $rev
diff --git a/git-commit.sh b/git-commit.sh
index 6ef1a9d..a4b0a90 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -676,7 +676,8 @@ then
rm -f "$TMP_INDEX"
fi &&
commit=$(cat "$GIT_DIR"/COMMIT_MSG | git-commit-tree $tree $PARENTS) &&
- git-update-ref HEAD $commit $current &&
+ rlogm=$(sed -e 1q "$GIT_DIR"/COMMIT_MSG) &&
+ git-update-ref -m "commit: $rlogm" HEAD $commit $current &&
rm -f -- "$GIT_DIR/MERGE_HEAD" &&
if test -f "$NEXT_INDEX"
then
diff --git a/git-reset.sh b/git-reset.sh
index 0ee3e3e..296f3b7 100755
--- a/git-reset.sh
+++ b/git-reset.sh
@@ -48,7 +48,7 @@ then
else
rm -f "$GIT_DIR/ORIG_HEAD"
fi
-git-update-ref HEAD "$rev"
+git-update-ref -m "reset $reset_type $@" HEAD "$rev"
case "$reset_type" in
--hard )
--
1.3.2.g7278
^ permalink raw reply related
* [PATCH 4/5] Create/delete branch ref logs.
From: Shawn Pearce @ 2006-05-19 9:16 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
When crating a new branch offer '-l' as a way for the user to
quickly enable ref logging for the new branch.
When deleting a branch also delete its ref log.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
This was discussed on #git earlier today and was thought to be a
useful feature. :-)
Documentation/git-branch.txt | 10 ++++++++--
git-branch.sh | 12 +++++++++++-
2 files changed, 19 insertions(+), 3 deletions(-)
e4fb59c8b73009e3bcae71bfb7edd7de2c648117
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index 72fb2f8..a7bec3c 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -9,7 +9,7 @@ SYNOPSIS
--------
[verse]
'git-branch' [-r]
-'git-branch' [-f] <branchname> [<start-point>]
+'git-branch' [-l] [-f] <branchname> [<start-point>]
'git-branch' (-d | -D) <branchname>...
DESCRIPTION
@@ -23,7 +23,8 @@ If no <start-point> is given, the branch
equal to that of the currently checked out branch.
With a `-d` or `-D` option, `<branchname>` will be deleted. You may
-specify more than one branch for deletion.
+specify more than one branch for deletion. If the branch currently
+has a ref log then the ref log will also be deleted.
OPTIONS
@@ -34,6 +35,11 @@ OPTIONS
-D::
Delete a branch irrespective of its index status.
+-l::
+ Create the branch's ref log. This activates recording of
+ all changes to made the branch ref, enabling use of date
+ based sha1 expressions such as "<branchname>@{yesterday}".
+
-f::
Force the creation of a new branch even if it means deleting
a branch that already exists with the same name.
diff --git a/git-branch.sh b/git-branch.sh
index d1e3730..e0501ec 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-USAGE='[(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]] | -r'
+USAGE='[-l] [(-d | -D) <branchname>] | [[-f] <branchname> [<start-point>]] | -r'
LONG_USAGE='If no arguments, show available branches and mark current branch with a star.
If one argument, create a new branch <branchname> based off of current HEAD.
If two arguments, create a new branch <branchname> based off of <start-point>.'
@@ -42,6 +42,7 @@ If you are sure you want to delete it, r
esac
;;
esac
+ rm -f "$GIT_DIR/logs/refs/heads/$branch_name"
rm -f "$GIT_DIR/refs/heads/$branch_name"
echo "Deleted branch $branch_name."
done
@@ -55,6 +56,7 @@ ls_remote_branches () {
}
force=
+create_log=
while case "$#,$1" in 0,*) break ;; *,-*) ;; *) break ;; esac
do
case "$1" in
@@ -69,6 +71,9 @@ do
-f)
force="$1"
;;
+ -l)
+ create_log="yes"
+ ;;
--)
shift
break
@@ -117,4 +122,9 @@ then
die "cannot force-update the current branch."
fi
fi
+if test "$create_log" = 'yes'
+then
+ mkdir -p $(dirname "$GIT_DIR/logs/refs/heads/$branchname")
+ touch "$GIT_DIR/logs/refs/heads/$branchname"
+fi
git update-ref -m "branch: Created from $head" "refs/heads/$branchname" $rev
--
1.3.2.g7278
^ permalink raw reply related
* [PATCH 5/5] Enable ref log creation in git checkout -b.
From: Shawn Pearce @ 2006-05-19 9:17 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Switch git checkout -b to use git-update-ref rather than echo and
a shell I/O redirection. This is more in line with typical GIT
commands and allows -b to be logged according to the normal ref
logging rules.
Added -l option to allow users to create the ref log at the same
time as creating a branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Documentation/git-checkout.txt | 7 ++++++-
git-checkout.sh | 19 +++++++++++++++----
2 files changed, 21 insertions(+), 5 deletions(-)
46409624159100ad958c3168b13e384168c12713
diff --git a/Documentation/git-checkout.txt b/Documentation/git-checkout.txt
index 0951289..0643943 100644
--- a/Documentation/git-checkout.txt
+++ b/Documentation/git-checkout.txt
@@ -8,7 +8,7 @@ git-checkout - Checkout and switch to a
SYNOPSIS
--------
[verse]
-'git-checkout' [-f] [-b <new_branch>] [-m] [<branch>]
+'git-checkout' [-f] [-b <new_branch> [-l]] [-m] [<branch>]
'git-checkout' [-m] [<branch>] <paths>...
DESCRIPTION
@@ -37,6 +37,11 @@ OPTIONS
-b::
Create a new branch and start it at <branch>.
+-l::
+ Create the new branch's ref log. This activates recording of
+ all changes to made the branch ref, enabling use of date
+ based sha1 expressions such as "<branchname>@{yesterday}".
+
-m::
If you have local modifications to one or more files that
are different between the current branch and the branch to
diff --git a/git-checkout.sh b/git-checkout.sh
index a11c939..360aabf 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -5,10 +5,13 @@ SUBDIRECTORY_OK=Sometimes
. git-sh-setup
old=$(git-rev-parse HEAD)
+old_name=HEAD
new=
+new_name=
force=
branch=
newbranch=
+newbranch_log=
merge=
while [ "$#" != "0" ]; do
arg="$1"
@@ -24,6 +27,9 @@ while [ "$#" != "0" ]; do
git-check-ref-format "heads/$newbranch" ||
die "git checkout: we do not like '$newbranch' as a branch name."
;;
+ "-l")
+ newbranch_log=1
+ ;;
"-f")
force=1
;;
@@ -44,6 +50,7 @@ while [ "$#" != "0" ]; do
exit 1
fi
new="$rev"
+ new_name="$arg^0"
if [ -f "$GIT_DIR/refs/heads/$arg" ]; then
branch="$arg"
fi
@@ -51,9 +58,11 @@ while [ "$#" != "0" ]; do
then
# checking out selected paths from a tree-ish.
new="$rev"
+ new_name="$arg^{tree}"
branch=
else
new=
+ new_name=
branch=
set x "$arg" "$@"
shift
@@ -114,7 +123,7 @@ then
cd "$cdup"
fi
-[ -z "$new" ] && new=$old
+[ -z "$new" ] && new=$old && new_name="$old_name"
# If we don't have an old branch that we're switching to,
# and we don't have a new branch name for the target we
@@ -187,9 +196,11 @@ # be based on them, since we re-set the
#
if [ "$?" -eq 0 ]; then
if [ "$newbranch" ]; then
- leading=`expr "refs/heads/$newbranch" : '\(.*\)/'` &&
- mkdir -p "$GIT_DIR/$leading" &&
- echo $new >"$GIT_DIR/refs/heads/$newbranch" || exit
+ if [ "$newbranch_log" ]; then
+ mkdir -p $(dirname "$GIT_DIR/logs/refs/heads/$branchname")
+ touch "$GIT_DIR/logs/refs/heads/$branchname"
+ fi
+ git-update-ref -m "checkout: Created from $new_name" "refs/heads/$newbranch" $new || exit
branch="$newbranch"
fi
[ "$branch" ] &&
--
1.3.2.g7278
^ permalink raw reply related
* Re: [RFD] Git glossary: 'branch' and 'head' description
From: Shawn Pearce @ 2006-05-19 9:21 UTC (permalink / raw)
To: David Kågedal; +Cc: git
In-Reply-To: <87y7wyv72m.fsf@morpheus.hq.vtech>
David K?gedal <davidk@lysator.liu.se> wrote:
> I noticed that some of this seems to be changing slightly with the
> introduction of branch logs, but I don't know how those are supposed
> to be used yet.
$ git commit -a
$ git pull . some/other-tag
# go to lunch
$ git pull . some/bad-stuff
$ git commit -a
# go home
$ test...
# realize this is all bad
$ git reset --hard "master@{yesterday}"
:-)
Its really only useful for recording the history of your ref's state,
so you can 'undo' a bad merge that you might have done a few days
ago but not realized was bad until now.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Implement git-quiltimport (take 2)
From: Eric W. Biederman @ 2006-05-19 9:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy7x09qet.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
>> For Andrews tree before I play anymore with technical solutions I
>> need to talk to Andrew and see if we can improve the situation
>> upstream. Possibly with a quilt-audit script that finds problem
>> patches.
>
> Yes, that sounds very sensible.
Anyway I had a first pass conversation with Andrew and it looks like
he will start addressing the problem patches there. So things
should be resolvable.
The final piece on my agenda for getting the proper authors from
the -mm tree is coping with Andrew's git patches. They have enough
information to determine the Author but they are really several
different patches. Ideally I will be able recognize they are
performing a pull from a git repository and get the same results.
Otherwise some other trick will be necessary.
Eric
^ permalink raw reply
* [PATCH] Builtin git-init-db
From: Timo Hirvonen @ 2006-05-19 10:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
Basically this just renames init-db.c to builtin-init-db.c and makes
some strings const.
Signed-off-by: Timo Hirvonen <tihirvon@gmail.com>
---
ea0920d755efa314e2be014e2a1eccda89d8f850
Makefile | 13 ++++++-------
init-db.c => builtin-init-db.c | 12 +++++++-----
builtin.h | 1 +
git.c | 1 +
4 files changed, 15 insertions(+), 12 deletions(-)
rename init-db.c => builtin-init-db.c (96%)
ea0920d755efa314e2be014e2a1eccda89d8f850
diff --git a/Makefile b/Makefile
index 2149fb8..a4e9643 100644
--- a/Makefile
+++ b/Makefile
@@ -154,7 +154,7 @@ PROGRAMS = \
git-convert-objects$X git-diff-files$X \
git-diff-index$X git-diff-stages$X \
git-diff-tree$X git-fetch-pack$X git-fsck-objects$X \
- git-hash-object$X git-index-pack$X git-init-db$X git-local-fetch$X \
+ git-hash-object$X git-index-pack$X git-local-fetch$X \
git-ls-files$X git-ls-tree$X git-mailinfo$X git-merge-base$X \
git-merge-index$X git-mktag$X git-mktree$X git-pack-objects$X git-patch-id$X \
git-peek-remote$X git-prune-packed$X git-read-tree$X \
@@ -170,7 +170,8 @@ PROGRAMS = \
BUILT_INS = git-log$X git-whatchanged$X git-show$X \
git-count-objects$X git-diff$X git-push$X \
- git-grep$X git-rev-list$X git-check-ref-format$X
+ git-grep$X git-rev-list$X git-check-ref-format$X \
+ git-init-db$X
# what 'all' will build and 'install' will install, in gitexecdir
ALL_PROGRAMS = $(PROGRAMS) $(SIMPLE_PROGRAMS) $(SCRIPTS)
@@ -218,7 +219,8 @@ LIB_OBJS = \
BUILTIN_OBJS = \
builtin-log.o builtin-help.o builtin-count.o builtin-diff.o builtin-push.o \
- builtin-grep.o builtin-rev-list.o builtin-check-ref-format.o
+ builtin-grep.o builtin-rev-list.o builtin-check-ref-format.o \
+ builtin-init-db.o
GITLIBS = $(LIB_FILE) $(XDIFF_LIB)
LIBS = $(GITLIBS) -lz
@@ -473,6 +475,7 @@ strip: $(PROGRAMS) git$X
git$X: git.c common-cmds.h $(BUILTIN_OBJS) $(GITLIBS)
$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
+ -DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_SQ)"' \
$(ALL_CFLAGS) -o $@ $(filter %.c,$^) \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
@@ -565,10 +568,6 @@ git-http-push$X: revision.o http.o http-
$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
-init-db.o: init-db.c
- $(CC) -c $(ALL_CFLAGS) \
- -DDEFAULT_GIT_TEMPLATE_DIR='"$(template_dir_SQ)"' $*.c
-
$(LIB_OBJS) $(BUILTIN_OBJS): $(LIB_H)
$(patsubst git-%$X,%.o,$(PROGRAMS)): $(GITLIBS)
$(DIFF_OBJS): diffcore.h
diff --git a/init-db.c b/builtin-init-db.c
similarity index 96%
rename from init-db.c
rename to builtin-init-db.c
index ff29496..2a1384c 100644
--- a/init-db.c
+++ b/builtin-init-db.c
@@ -4,6 +4,7 @@
* Copyright (C) Linus Torvalds, 2005
*/
#include "cache.h"
+#include "builtin.h"
#ifndef DEFAULT_GIT_TEMPLATE_DIR
#define DEFAULT_GIT_TEMPLATE_DIR "/usr/share/git-core/templates/"
@@ -116,7 +117,7 @@ static void copy_templates_1(char *path,
}
}
-static void copy_templates(const char *git_dir, int len, char *template_dir)
+static void copy_templates(const char *git_dir, int len, const char *template_dir)
{
char path[PATH_MAX];
char template_path[PATH_MAX];
@@ -163,7 +164,7 @@ static void copy_templates(const char *g
closedir(dir);
}
-static void create_default_files(const char *git_dir, char *template_path)
+static void create_default_files(const char *git_dir, const char *template_path)
{
unsigned len = strlen(git_dir);
static char path[PATH_MAX];
@@ -234,15 +235,16 @@ static const char init_db_usage[] =
* On the other hand, it might just make lookup slower and messier. You
* be the judge. The default case is to have one DB per managed directory.
*/
-int main(int argc, char **argv)
+int cmd_init_db(int argc, const char **argv, char **envp)
{
const char *git_dir;
const char *sha1_dir;
- char *path, *template_dir = NULL;
+ const char *template_dir = NULL;
+ char *path;
int len, i;
for (i = 1; i < argc; i++, argv++) {
- char *arg = argv[1];
+ const char *arg = argv[1];
if (!strncmp(arg, "--template=", 11))
template_dir = arg+11;
else if (!strcmp(arg, "--shared"))
diff --git a/builtin.h b/builtin.h
index ff559de..6054126 100644
--- a/builtin.h
+++ b/builtin.h
@@ -26,5 +26,6 @@ extern int cmd_push(int argc, const char
extern int cmd_grep(int argc, const char **argv, char **envp);
extern int cmd_rev_list(int argc, const char **argv, char **envp);
extern int cmd_check_ref_format(int argc, const char **argv, char **envp);
+extern int cmd_init_db(int argc, const char **argv, char **envp);
#endif
diff --git a/git.c b/git.c
index d0650bb..3216d31 100644
--- a/git.c
+++ b/git.c
@@ -51,6 +51,7 @@ static void handle_internal_command(int
{ "diff", cmd_diff },
{ "grep", cmd_grep },
{ "rev-list", cmd_rev_list },
+ { "init-db", cmd_init_db },
{ "check-ref-format", cmd_check_ref_format }
};
int i;
--
1.3.3.gff62-dirty
^ permalink raw reply related
* Re: [PATCH 0/5] More ref logging
From: Sean @ 2006-05-19 11:16 UTC (permalink / raw)
To: Shawn Pearce; +Cc: junkio, git
In-Reply-To: <20060519091456.GH22257@spearce.org>
On Fri, 19 May 2006 05:14:56 -0400
Shawn Pearce <spearce@spearce.org> wrote:
> * [PATCH 5/5] Enable ref log creation in git checkout -b.
>
> Fix git checkout -b to behave like git branch.
It seems that the ref log is a new way of tagging commits with some
extra meta data. Conceptually this seems very close to what git tags
already do. So... what about using regular git tags rather than
creating a ref log? All the regular git-rev-list tools could be
used to query the tags and prune would delete them automatically etc.
Just a thought, feel free to ignore it :o)
Sean
^ permalink raw reply
* [PATCH] [PARSECVS] add an install target to Makefile
From: Martin Atukunda @ 2006-05-19 11:34 UTC (permalink / raw)
To: git
---
573c3afa5674024df0fd5722404f215c54977699
Makefile | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
573c3afa5674024df0fd5722404f215c54977699
diff --git a/Makefile b/Makefile
index 4ca6ffd..50fa551 100644
--- a/Makefile
+++ b/Makefile
@@ -24,3 +24,5 @@ y.tab.h: gram.c
clean:
rm -f $(OBJS) y.tab.h gram.c lex.c parsecvs
+install:
+ cp parsecvs edit-change-log ${HOME}/bin
--
1.3.3.gff62
^ permalink raw reply related
* Re: [RFC] qgit with tabs
From: Marco Costalba @ 2006-05-19 16:54 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git
In-Reply-To: <1147908094.32050.22.camel@dv>
On 5/18/06, Pavel Roskin <proski@gnu.org> wrote:
>
> > 3) It is true that double clicking on a revision switch to the patch
> > view at top position (if no file is selected), but it's also true that
> > you can select the file's related diff directly in patch view with a
> > single click on the right column file list.
>
> That's true. But I still find myself double clicking on the file in the
> file list and expecting to see the patch for the file. It's very
> natural.
>
> If I see the list of the recent patches, I see the descriptions and the
> affected files. If I'm interested to see what changed in the file, it's
> only natural for me to double-click the corresponding entry in the list.
>
Ok. patch pushed.
Perhaps I'm not using gitk a lot so I still have to get used to this
new file double clicking behaviour.
Marco
^ permalink raw reply
* Libify the index refresh logic
From: Linus Torvalds @ 2006-05-19 16:56 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This cleans up and libifies the "git update-index --[really-]refresh"
functionality. This will be eventually required for eventually doing the
"commit" and "status" commands as built-ins.
It really just moves "refresh_index()" from update-index.c to
read-cache.c, but it also has to change the calling convention so that the
function uses a "unsigned int flags" argument instead of various static
flags variables for passing down the information about whether to be quiet
or not, and allow unmerged entries etc.
That actually cleans up update-index.c too, since it turns out that all
those flags were really specific to that one function of the index update,
so they shouldn't have had file-scope visibility even before.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
---
[ To keep the changes to the refresh_index() function itself minimal, it
currently just unpacks the passed-in "flags" argument into local
variables with the same names as the old static variables. That's
almost certainly worth cleaning up later, but for now it's that way
just to show that no functionality or logic actually changed.
Also, while I could have moved the IS_ERR/ERR_PTR/PTR_ERR macros to be
globally visible in a real header file, they were only used within the
moved function, so I just moved them to read-cache.c too with the only
user. ]
diff --git a/cache.h b/cache.h
index f9b7049..31755c8 100644
--- a/cache.h
+++ b/cache.h
@@ -160,6 +160,12 @@ extern int index_pipe(unsigned char *sha
extern int index_path(unsigned char *sha1, const char *path, struct stat *st, int write_object);
extern void fill_stat_cache_info(struct cache_entry *ce, struct stat *st);
+#define REFRESH_REALLY 0x0001 /* ignore_valid */
+#define REFRESH_UNMERGED 0x0002 /* allow unmerged */
+#define REFRESH_QUIET 0x0004 /* be quiet about it */
+#define REFRESH_IGNORE_MISSING 0x0008 /* ignore non-existent */
+extern int refresh_cache(unsigned int flags);
+
struct cache_file {
struct cache_file *next;
char lockfile[PATH_MAX];
diff --git a/read-cache.c b/read-cache.c
index 9a272f8..36bd4ea 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -577,6 +577,123 @@ int add_cache_entry(struct cache_entry *
return 0;
}
+/* Three functions to allow overloaded pointer return; see linux/err.h */
+static inline void *ERR_PTR(long error)
+{
+ return (void *) error;
+}
+
+static inline long PTR_ERR(const void *ptr)
+{
+ return (long) ptr;
+}
+
+static inline long IS_ERR(const void *ptr)
+{
+ return (unsigned long)ptr > (unsigned long)-1000L;
+}
+
+/*
+ * "refresh" does not calculate a new sha1 file or bring the
+ * cache up-to-date for mode/content changes. But what it
+ * _does_ do is to "re-match" the stat information of a file
+ * with the cache, so that you can refresh the cache for a
+ * file that hasn't been changed but where the stat entry is
+ * out of date.
+ *
+ * For example, you'd want to do this after doing a "git-read-tree",
+ * to link up the stat cache details with the proper files.
+ */
+static struct cache_entry *refresh_entry(struct cache_entry *ce, int really)
+{
+ struct stat st;
+ struct cache_entry *updated;
+ int changed, size;
+
+ if (lstat(ce->name, &st) < 0)
+ return ERR_PTR(-errno);
+
+ changed = ce_match_stat(ce, &st, really);
+ if (!changed) {
+ if (really && assume_unchanged &&
+ !(ce->ce_flags & htons(CE_VALID)))
+ ; /* mark this one VALID again */
+ else
+ return NULL;
+ }
+
+ if (ce_modified(ce, &st, really))
+ return ERR_PTR(-EINVAL);
+
+ size = ce_size(ce);
+ updated = xmalloc(size);
+ memcpy(updated, ce, size);
+ fill_stat_cache_info(updated, &st);
+
+ /* In this case, if really is not set, we should leave
+ * CE_VALID bit alone. Otherwise, paths marked with
+ * --no-assume-unchanged (i.e. things to be edited) will
+ * reacquire CE_VALID bit automatically, which is not
+ * really what we want.
+ */
+ if (!really && assume_unchanged && !(ce->ce_flags & htons(CE_VALID)))
+ updated->ce_flags &= ~htons(CE_VALID);
+
+ return updated;
+}
+
+int refresh_cache(unsigned int flags)
+{
+ int i;
+ int has_errors = 0;
+ int really = (flags & REFRESH_REALLY) != 0;
+ int allow_unmerged = (flags & REFRESH_UNMERGED) != 0;
+ int quiet = (flags & REFRESH_QUIET) != 0;
+ int not_new = (flags & REFRESH_IGNORE_MISSING) != 0;
+
+ for (i = 0; i < active_nr; i++) {
+ struct cache_entry *ce, *new;
+ ce = active_cache[i];
+ if (ce_stage(ce)) {
+ while ((i < active_nr) &&
+ ! strcmp(active_cache[i]->name, ce->name))
+ i++;
+ i--;
+ if (allow_unmerged)
+ continue;
+ printf("%s: needs merge\n", ce->name);
+ has_errors = 1;
+ continue;
+ }
+
+ new = refresh_entry(ce, really);
+ if (!new)
+ continue;
+ if (IS_ERR(new)) {
+ if (not_new && PTR_ERR(new) == -ENOENT)
+ continue;
+ if (really && PTR_ERR(new) == -EINVAL) {
+ /* If we are doing --really-refresh that
+ * means the index is not valid anymore.
+ */
+ ce->ce_flags &= ~htons(CE_VALID);
+ active_cache_changed = 1;
+ }
+ if (quiet)
+ continue;
+ printf("%s: needs update\n", ce->name);
+ has_errors = 1;
+ continue;
+ }
+ active_cache_changed = 1;
+ /* You can NOT just free active_cache[i] here, since it
+ * might not be necessarily malloc()ed but can also come
+ * from mmap(). */
+ active_cache[i] = new;
+ }
+ return has_errors;
+}
+
static int verify_hdr(struct cache_header *hdr, unsigned long size)
{
SHA_CTX c;
diff --git a/update-index.c b/update-index.c
index 21448cc..956b6b3 100644
--- a/update-index.c
+++ b/update-index.c
@@ -19,9 +19,6 @@ #include "tree-walk.h"
static int allow_add;
static int allow_remove;
static int allow_replace;
-static int allow_unmerged; /* --refresh needing merge is not error */
-static int not_new; /* --refresh not having working tree files is not error */
-static int quiet; /* --refresh needing update is not error */
static int info_only;
static int force_remove;
static int verbose;
@@ -29,23 +26,6 @@ static int mark_valid_only = 0;
#define MARK_VALID 1
#define UNMARK_VALID 2
-
-/* Three functions to allow overloaded pointer return; see linux/err.h */
-static inline void *ERR_PTR(long error)
-{
- return (void *) error;
-}
-
-static inline long PTR_ERR(const void *ptr)
-{
- return (long) ptr;
-}
-
-static inline long IS_ERR(const void *ptr)
-{
- return (unsigned long)ptr > (unsigned long)-1000L;
-}
-
static void report(const char *fmt, ...)
{
va_list vp;
@@ -148,103 +128,6 @@ static int add_file_to_cache(const char
return 0;
}
-/*
- * "refresh" does not calculate a new sha1 file or bring the
- * cache up-to-date for mode/content changes. But what it
- * _does_ do is to "re-match" the stat information of a file
- * with the cache, so that you can refresh the cache for a
- * file that hasn't been changed but where the stat entry is
- * out of date.
- *
- * For example, you'd want to do this after doing a "git-read-tree",
- * to link up the stat cache details with the proper files.
- */
-static struct cache_entry *refresh_entry(struct cache_entry *ce, int really)
-{
- struct stat st;
- struct cache_entry *updated;
- int changed, size;
-
- if (lstat(ce->name, &st) < 0)
- return ERR_PTR(-errno);
-
- changed = ce_match_stat(ce, &st, really);
- if (!changed) {
- if (really && assume_unchanged &&
- !(ce->ce_flags & htons(CE_VALID)))
- ; /* mark this one VALID again */
- else
- return NULL;
- }
-
- if (ce_modified(ce, &st, really))
- return ERR_PTR(-EINVAL);
-
- size = ce_size(ce);
- updated = xmalloc(size);
- memcpy(updated, ce, size);
- fill_stat_cache_info(updated, &st);
-
- /* In this case, if really is not set, we should leave
- * CE_VALID bit alone. Otherwise, paths marked with
- * --no-assume-unchanged (i.e. things to be edited) will
- * reacquire CE_VALID bit automatically, which is not
- * really what we want.
- */
- if (!really && assume_unchanged && !(ce->ce_flags & htons(CE_VALID)))
- updated->ce_flags &= ~htons(CE_VALID);
-
- return updated;
-}
-
-static int refresh_cache(int really)
-{
- int i;
- int has_errors = 0;
-
- for (i = 0; i < active_nr; i++) {
- struct cache_entry *ce, *new;
- ce = active_cache[i];
- if (ce_stage(ce)) {
- while ((i < active_nr) &&
- ! strcmp(active_cache[i]->name, ce->name))
- i++;
- i--;
- if (allow_unmerged)
- continue;
- printf("%s: needs merge\n", ce->name);
- has_errors = 1;
- continue;
- }
-
- new = refresh_entry(ce, really);
- if (!new)
- continue;
- if (IS_ERR(new)) {
- if (not_new && PTR_ERR(new) == -ENOENT)
- continue;
- if (really && PTR_ERR(new) == -EINVAL) {
- /* If we are doing --really-refresh that
- * means the index is not valid anymore.
- */
- ce->ce_flags &= ~htons(CE_VALID);
- active_cache_changed = 1;
- }
- if (quiet)
- continue;
- printf("%s: needs update\n", ce->name);
- has_errors = 1;
- continue;
- }
- active_cache_changed = 1;
- /* You can NOT just free active_cache[i] here, since it
- * might not be necessarily malloc()ed but can also come
- * from mmap(). */
- active_cache[i] = new;
- }
- return has_errors;
-}
-
static int add_cacheinfo(unsigned int mode, const unsigned char *sha1,
const char *path, int stage)
{
@@ -602,6 +485,7 @@ int main(int argc, const char **argv)
const char *prefix = setup_git_directory();
int prefix_length = prefix ? strlen(prefix) : 0;
char set_executable_bit = 0;
+ unsigned int refresh_flags = 0;
git_config(git_default_config);
@@ -622,7 +506,7 @@ int main(int argc, const char **argv)
continue;
}
if (!strcmp(path, "-q")) {
- quiet = 1;
+ refresh_flags |= REFRESH_QUIET;
continue;
}
if (!strcmp(path, "--add")) {
@@ -638,15 +522,15 @@ int main(int argc, const char **argv)
continue;
}
if (!strcmp(path, "--unmerged")) {
- allow_unmerged = 1;
+ refresh_flags |= REFRESH_UNMERGED;
continue;
}
if (!strcmp(path, "--refresh")) {
- has_errors |= refresh_cache(0);
+ has_errors |= refresh_cache(refresh_flags);
continue;
}
if (!strcmp(path, "--really-refresh")) {
- has_errors |= refresh_cache(1);
+ has_errors |= refresh_cache(REFRESH_REALLY | refresh_flags);
continue;
}
if (!strcmp(path, "--cacheinfo")) {
@@ -719,7 +603,7 @@ int main(int argc, const char **argv)
goto finish;
}
if (!strcmp(path, "--ignore-missing")) {
- not_new = 1;
+ refresh_flags |= REFRESH_IGNORE_MISSING;
continue;
}
if (!strcmp(path, "--verbose")) {
^ permalink raw reply related
* Re: Libify the index refresh logic
From: Linus Torvalds @ 2006-05-19 17:42 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0605190942060.10823@g5.osdl.org>
On Fri, 19 May 2006, Linus Torvalds wrote:
>
> This cleans up and libifies the "git update-index --[really-]refresh"
> functionality. This will be eventually required for eventually doing the
> "commit" and "status" commands as built-ins.
Oops, that's one "eventually" too many. That's what you get for editing
and moving text around.
Linus
^ permalink raw reply
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Yann Dirson @ 2006-05-19 18:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsln7lzbj.fsf@assigned-by-dhcp.cox.net>
On Thu, May 18, 2006 at 03:53:36PM -0700, Junio C Hamano wrote:
> Yann Dirson <ydirson@altern.org> writes:
>
> > To make my point maybe more clear: if someone really wants to make a
> > graft permanent, wouldn't some history rewriting ... be the
> > way to go,...
>
> Yes.
So if temporary usage is a typical use for grafts, don't we want to
protect people using them from pruning ? I got no feedback to my
suggestion of changing the default behaviour, even to say it was a bad
idea :)
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Jakub Narebski @ 2006-05-19 19:00 UTC (permalink / raw)
To: git
In-Reply-To: <20060519185558.GE6535@nowhere.earth>
Yann Dirson wrote:
> On Thu, May 18, 2006 at 03:53:36PM -0700, Junio C Hamano wrote:
>> Yann Dirson <ydirson@altern.org> writes:
>>
>> > To make my point maybe more clear: if someone really wants to make a
>> > graft permanent, wouldn't some history rewriting ... be the
>> > way to go,...
>>
>> Yes.
>
> So if temporary usage is a typical use for grafts, don't we want to
> protect people using them from pruning ? I got no feedback to my
> suggestion of changing the default behaviour, even to say it was a bad
> idea :)
Perhaps prune should be conservative by default, and follow both grafts and
original parents, and use appropriate options to preserve or not preserve
grafts.
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Linus Torvalds @ 2006-05-19 19:02 UTC (permalink / raw)
To: Yann Dirson; +Cc: Junio C Hamano, git
In-Reply-To: <20060519185558.GE6535@nowhere.earth>
On Fri, 19 May 2006, Yann Dirson wrote:
> On Thu, May 18, 2006 at 03:53:36PM -0700, Junio C Hamano wrote:
> > Yann Dirson <ydirson@altern.org> writes:
> >
> > > To make my point maybe more clear: if someone really wants to make a
> > > graft permanent, wouldn't some history rewriting ... be the
> > > way to go,...
> >
> > Yes.
>
> So if temporary usage is a typical use for grafts, don't we want to
> protect people using them from pruning ? I got no feedback to my
> suggestion of changing the default behaviour, even to say it was a bad
> idea :)
I don't actually know how much grafts end up being used. Right now, the
only really valid use I know about is to graft together the old kernel
history kind of thing, and I suspect not a whole lot of people do that (I
keep a separate kernel history tree around for when I need to look at it,
and it doesn't happen all that often).
So I think the lack of feedback on the graft-related issue comes directly
from that lack of graft usage.
We _could_ decide that fsck should just follow the "real parents" and the
grafts _both_. That's the safe thing to do by default. Possibly with a
flag to say "prefer one over the other", or even a "prefer which-ever
exists".
Linus
^ permalink raw reply
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Yann Dirson @ 2006-05-19 20:25 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605191159520.10823@g5.osdl.org>
On Fri, May 19, 2006 at 12:02:48PM -0700, Linus Torvalds wrote:
>
>
> On Fri, 19 May 2006, Yann Dirson wrote:
>
> > On Thu, May 18, 2006 at 03:53:36PM -0700, Junio C Hamano wrote:
> > > Yann Dirson <ydirson@altern.org> writes:
> > >
> > > > To make my point maybe more clear: if someone really wants to make a
> > > > graft permanent, wouldn't some history rewriting ... be the
> > > > way to go,...
> > >
> > > Yes.
> >
> > So if temporary usage is a typical use for grafts, don't we want to
> > protect people using them from pruning ? I got no feedback to my
> > suggestion of changing the default behaviour, even to say it was a bad
> > idea :)
>
> I don't actually know how much grafts end up being used. Right now, the
> only really valid use I know about is to graft together the old kernel
> history kind of thing, and I suspect not a whole lot of people do that (I
> keep a separate kernel history tree around for when I need to look at it,
> and it doesn't happen all that often).
>
> So I think the lack of feedback on the graft-related issue comes directly
> from that lack of graft usage.
I take this as an incentive to share my use of the think :)
On several projects managed with CVS, I use a git mirror (maintained
with git-cvsimport for now) to prepare my sets of patches with stgit,
before committing them to cvs (through git-cvsexportcommit). In this
context, since merges are not recorded in cvs, and cvs insists that
all branches must derive from the trunk, I use grafts to:
1. record merges
2. cause git to believe that the trunk derives from the vendor
branch
3. hide those pseudo revisions cvs adds to rcs files saying
"file was initially added to branch foo"
It is the latter use which caused the loss previously mentionned. It
could have been avoided by making cvsimport, or more likely cvsps more
clever wrt this case.
> We _could_ decide that fsck should just follow the "real parents" and the
> grafts _both_. That's the safe thing to do by default. Possibly with a
> flag to say "prefer one over the other", or even a "prefer which-ever
> exists".
I'm not sure I see how "prefer which-ever exists" would be useful - do
you have anything precise in mind ?
Best regards,
--
Yann Dirson <ydirson@altern.org> |
Debian-related: <dirson@debian.org> | Support Debian GNU/Linux:
| Freedom, Power, Stability, Gratis
http://ydirson.free.fr/ | Check <http://www.debian.org/>
^ permalink raw reply
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Linus Torvalds @ 2006-05-19 20:45 UTC (permalink / raw)
To: Yann Dirson; +Cc: Junio C Hamano, git
In-Reply-To: <20060519202540.GF6535@nowhere.earth>
On Fri, 19 May 2006, Yann Dirson wrote:
>
> > We _could_ decide that fsck should just follow the "real parents" and the
> > grafts _both_. That's the safe thing to do by default. Possibly with a
> > flag to say "prefer one over the other", or even a "prefer which-ever
> > exists".
>
> I'm not sure I see how "prefer which-ever exists" would be useful - do
> you have anything precise in mind ?
It would be a "once you've pruned one or the other, don't complain any
more about the fact that it doesn't exist" flag.
Linus
^ permalink raw reply
* [PATCH] Document that "git add" only adds non-ignored files.
From: Santi @ 2006-05-19 21:02 UTC (permalink / raw)
To: git, Junio C Hamano
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
Documentation/git-add.txt | 9 ++++++---
1 files changed, 6 insertions(+), 3 deletions(-)
9c057bcba388450963085eb5c751b734c04ff045
diff --git a/Documentation/git-add.txt b/Documentation/git-add.txt
index 5e31129..1b6a22a 100644
--- a/Documentation/git-add.txt
+++ b/Documentation/git-add.txt
@@ -7,18 +7,20 @@ git-add - Add files to the index file
SYNOPSIS
--------
-'git-add' [-n] [-v] [--] <file>...
+'git-add' [-n] [-v] [--] <filepattern>...
DESCRIPTION
-----------
A simple wrapper for git-update-index to add files to the index,
for people used to do "cvs add".
+It only adds non-ignored files, to add ignored files use
+"git update-index --add".
OPTIONS
-------
-<file>...::
- Files to add to the index.
+<filepattern>...::
+ Files to add to the index, see gitlink:git-ls-files[1].
-n::
Don't actually add the file(s), just show if they exist.
@@ -68,6 +70,7 @@ git-add git-*.sh::
See Also
--------
gitlink:git-rm[1]
+gitlink:git-ls-files[1]
Author
------
--
1.3.3.g97ee3
^ permalink raw reply related
* Re: [PATCH] built-in tar-tree and remote tar-tree
From: Sven Ekman @ 2006-05-19 21:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j4ik1fr.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> skrev:
> Sorry for sending a crapoid that does not even
> compile. I ran format-patch while on a wrong
> branch.
>
> Tonight's "pu" will have a fixed up one for
> people who are interested to play with.
Hi Junio,
Thanks for your answer. I'm looking forward to try the
remote tar-tree at the weekend. While this will
definitely make it much more easy to grab single
revisions out of a git tree, it only solves a part of
the issue I was trying to address. If one wanted a
simple snapshot of the source, it's usually easier to
download a tarball.
The great thing about having the kernel source in a
git repository is that it lets me upgrade the kernel
source tree in place with a single simple command. No
firing up a browser, downloading and applying a patch.
It is also braindead easy to maintain a set of local
patches across different kernel versions. Git makes
all this quick and easy.
Is there a simple way to retrieve a single object or a
list of objects _without_ any of their parents? If so
one could retrieve the wanted commit and the
corresponding tree and parse it on the client side to
retrieve its descendents and commits. If so, the
number of roundtrips would be roughly proportional to
the depth of the trees, which would probably still be
acceptable.
Greetings, Sven
^ permalink raw reply
* Re: [PATCH] built-in tar-tree and remote tar-tree
From: Jakub Narebski @ 2006-05-19 21:56 UTC (permalink / raw)
To: git
In-Reply-To: <20060519214318.38240.qmail@web25910.mail.ukl.yahoo.com>
Sven Ekman wrote:
> Is there a simple way to retrieve a single object or a
> list of objects _without_ any of their parents? If so
> one could retrieve the wanted commit and the
> corresponding tree and parse it on the client side to
> retrieve its descendents and commits. If so, the
> number of roundtrips would be roughly proportional to
> the depth of the trees, which would probably still be
> acceptable.
Perhaps alternates file which points to _remote_ git repository,
leaving all unused objects at remote directory, and needing constant
net access to said remote repository for almost all operations?
--
Jakub Narebski
Warsaw, Poland
^ permalink raw reply
* Re: [PATCH] Document that "git add" only adds non-ignored files.
From: Junio C Hamano @ 2006-05-19 21:56 UTC (permalink / raw)
To: Santi; +Cc: git, Junio C Hamano
In-Reply-To: <8aa486160605191402k2863e5edk@mail.gmail.com>
Thanks for the reminder, but I wonder if it is good to update
the description of this command, and ls-files to use the
same wording for consistency. We seem to use <pathspec> to mean
"this is not necessarily a filename -- we glob", so that may be
a good candidate (we do not have <pathspec> in glossary yet --
we would need to add).
Please don't touch description for diff-* family -- right now,
they say <path>, because they do not glob. If we decide that it
is a good idea to glob (which I suspect we don't for the
low-level stuff, but we probably do for the "git-diff" wrapper),
we would update the code and the description at the same time.
^ permalink raw reply
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw away revs hidden by a graft.
From: Junio C Hamano @ 2006-05-19 22:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Yann Dirson, git
In-Reply-To: <Pine.LNX.4.64.0605191159520.10823@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> On Fri, 19 May 2006, Yann Dirson wrote:
>
>> On Thu, May 18, 2006 at 03:53:36PM -0700, Junio C Hamano wrote:
>> > Yann Dirson <ydirson@altern.org> writes:
>> >
>> > > To make my point maybe more clear: if someone really wants to make a
>> > > graft permanent, wouldn't some history rewriting ... be the
>> > > way to go,...
>> >
>> > Yes.
>>
>> So if temporary usage is a typical use for grafts, don't we want to
>> protect people using them from pruning ? I got no feedback to my
>> suggestion of changing the default behaviour, even to say it was a bad
>> idea :)
I just gave a terse "Yes" because I agree with Yann that if
really a permanent history rewriting is needed it should be done
by history rewriting not with graft (I do not necessarily
encourage people to rewrite history but if somebody wants to,
that is).
> We _could_ decide that fsck should just follow the "real parents" and the
> grafts _both_. That's the safe thing to do by default. Possibly with a
> flag to say "prefer one over the other", or even a "prefer which-ever
> exists".
I agree with everything Linus said about the current grafts
usage. My vote for fsck is to make it default to follow both by
default for safety, and perhaps an optional --ignore-graft
flag.
^ permalink raw reply
* Re: [PATCH] [BUG] Add a test to check git-prune does not throw awayrevs hidden by a graft.
From: David Lang @ 2006-05-19 22:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Yann Dirson, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0605191159520.10823@g5.osdl.org>
On Fri, 19 May 2006, Linus Torvalds wrote:
> On Fri, 19 May 2006, Yann Dirson wrote:
>
>> On Thu, May 18, 2006 at 03:53:36PM -0700, Junio C Hamano wrote:
>>> Yann Dirson <ydirson@altern.org> writes:
>>>
>>>> To make my point maybe more clear: if someone really wants to make a
>>>> graft permanent, wouldn't some history rewriting ... be the
>>>> way to go,...
>>>
>>> Yes.
>>
>> So if temporary usage is a typical use for grafts, don't we want to
>> protect people using them from pruning ? I got no feedback to my
>> suggestion of changing the default behaviour, even to say it was a bad
>> idea :)
>
> I don't actually know how much grafts end up being used. Right now, the
> only really valid use I know about is to graft together the old kernel
> history kind of thing, and I suspect not a whole lot of people do that (I
> keep a separate kernel history tree around for when I need to look at it,
> and it doesn't happen all that often).
>
> So I think the lack of feedback on the graft-related issue comes directly
> from that lack of graft usage.
if/when shallow clones become available I would expect to see graft useage
climb significantly
David Lang
--
There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies.
-- C.A.R. Hoare
^ permalink raw reply
* Re: Libify the index refresh logic
From: Junio C Hamano @ 2006-05-19 22:36 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0605190942060.10823@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
> This cleans up and libifies the "git update-index --[really-]refresh"
> functionality. This will be eventually required for eventually doing the
> "commit" and "status" commands as built-ins.
Thanks.
With the recent torrent of moving functions around across files
without necessarily making the old file empty (thus resulting in
what some people call "file rename"), the Porcelainish people
would have enough testcases to think about how to handle merges
that involve with cases like these.
^ permalink raw reply
* Re: [PATCH] built-in tar-tree and remote tar-tree
From: Junio C Hamano @ 2006-05-19 22:56 UTC (permalink / raw)
To: Sven Ekman; +Cc: git
In-Reply-To: <20060519214318.38240.qmail@web25910.mail.ukl.yahoo.com>
Sven Ekman <svekman@yahoo.se> writes:
> Thanks for your answer. I'm looking forward to try the
> remote tar-tree at the weekend.
A word of caution. This obviously needs the updated stuff on
both ends. The downloader needs to have updated tar-tree, and
the other end needs the new command upload-tar.
> Is there a simple way to retrieve a single object or a
> list of objects _without_ any of their parents?
The thing is, I do not think that is what you really want.
If you do not have the necessary parents, many of the benefit
you list as "why do I want kernel from git repo" would not work.
The next fetch will try to see where the common ancestry commit
is, in order to download only from that one, for example. For
that you would need a well formed repositories on both ends.
Obviously bisect and anything that deal with the traversal of
ancestry chain would break, and while you would say "I accept
that some things may not work", their failure mode do not even
consider that the user might start from such an incomplete
repositories to begin with, so one thing is that the user would
be very confused, and another thing is that I would not be
surprised if some operations further "corrupt" such an already
incomplete repository (fsck, prune and probably bisect when it
tries to rewind the bisection branch -- your branch head may
point at nowhere and the user might need to do manual update-ref
instead of "git checkout master" to recover from it), causing
further grief.
In other words, to support such partial/incomplete repositories
properly, you are talking about a major major surgery. I just
do not want to think about it right now.
On the other hand, the primary point of my patch is that the
result does _not_ pretend it is a proper git repository, so we
do not have to worry about all the above issues.
^ 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