* suggestion: store the URL somewhere in .git/
From: Jeff Carr @ 2005-08-22 20:08 UTC (permalink / raw)
To: git
It would be nice if the URL could be stored somewhere in .git/ This
makes it a lot easier to update repositories because you don't always
have to go and track down where you got it in the first place. Something
like this perhaps:
~$ cat .git/location
rsync://rsync.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git/
~$ git-pull-script
Then something like below could be added to handle that easy enough.
Jeff
--- git-pull-script.orig 2005-07-31 22:23:50.000000000 -0700
+++ git-pull-script 2005-08-22 13:01:22.000000000 -0700
@@ -4,13 +4,24 @@
# cogito.]
#
+LOCATION="$@"
+
+if [ ! $LOCATION ]
+then
+ if [ -f .git/location ]
+ then
+ LOCATION=`cat .git/location`
+ fi
+fi
+
. git-sh-setup-script || die "Not a git archive"
-. git-parse-remote "$@"
+. git-parse-remote "$LOCATION"
merge_name="$_remote_name"
-git-fetch-script "$@" || exit 1
+git-fetch-script "$LOCATION" || exit 1
git-resolve-script \
"$(cat "$GIT_DIR"/HEAD)" \
"$(cat "$GIT_DIR"/FETCH_HEAD)" \
"Merge $merge_name"
+
^ permalink raw reply
* Re: suggestion: store the URL somewhere in .git/
From: Johannes Schindelin @ 2005-08-22 20:18 UTC (permalink / raw)
To: Jeff Carr; +Cc: git
In-Reply-To: <430A30C8.3080908@linuxmachines.com>
Hi,
On Mon, 22 Aug 2005, Jeff Carr wrote:
> It would be nice if the URL could be stored somewhere in .git/ This
> makes it a lot easier to update repositories because you don't always
> have to go and track down where you got it in the first place.
This is why your original target (when you clone) is stored as "origin".
Hth,
Dscho
^ permalink raw reply
* Versioning for template directory?
From: Josef Weidendorfer @ 2005-08-22 15:59 UTC (permalink / raw)
To: git
Hi,
as more and more hooks are added to git, I would want to have the hook
scripts, part of the per-repository configuration, itself in version control.
If you look at CVS, the configuration there is also under version control (in
CVSROOT). I can do this manually: after git-init-db, go into .git/hooks, do a
git-init-db again, adding the hooks for version control, and commiting the
initial version of the hooks.
But I get the feeling that the different hooks should be versioned
on a file basis, and not on a directory/whole project basis.
Here, I explicitly want to have the RCS/CVS way of versioning.
[Another use case: a wiki site managed via a GIT archive, to be able to change
the site offline. Here too, I would want to have versioning on a file basis]
Is there a way to "extend" git to allow for this kind of versioning? This
needs multiple simultaneous checkouts of heads representing independent
project parts (i.e. single files). There would be a GIT index for every such
independent project part; the problem being that the checkouts should be done
into the same directory.
So what is the best way to accomplish this?
I have to use multiple index files (index1, index2, ...), allowing multiple
independent branches could be checked out independently. Another extension
would be kind of a "super-head" specifying multiple heads (SHAs)
which are to be checked out simultaneously (via index1, index2...). It should
be possible to create signed tags out of such super-heads.
Is this feasable?
Josef
^ permalink raw reply
* Re: Multi-head pulling series
From: Josef Weidendorfer @ 2005-08-22 16:35 UTC (permalink / raw)
To: git
In-Reply-To: <7vfyt4l9q9.fsf@assigned-by-dhcp.cox.net>
On Saturday 20 August 2005 20:54, Junio C Hamano wrote:
> Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> >> $ cat $GIT_DIR/remotes/www
> >> URL: http://www.kernel.org/pub/scm/git/git.git/
> >> Pull: master:ko-master pu:ko-pu
> >> Push: master:master pu:pu foo:bar
> >
> > Isn't this mixing two kinds of information:
> > 1) Some default/persistent mapping of local to remote heads
> > 2) The default heads which are pulled/pushed when only giving the remote
>
> I am not convinced myself that default/persistent mapping makes
> much sense,
I think that both, default and non-default persistant mappings, are only a
handy convenience issue for less typing. If GIT core is not doing this, some
(most?) porcelains will invent their own way for storing these mappings (like
Cogito is doing with branches/). I think it is better if this is
"standardized".
Currently missing here is automatic detection of the remote repository for a
given head to be pulled/pushed. But this is no format issue.
> and updating the stored mappings dynamically when
> the user uses non-default mappings in push/pull as a one-shot
> operation does not make any sense at all at least to me.
Yes, you are right.
Josef
^ permalink raw reply
* Re: [RFC] Stgit - patch history / add extra parents
From: Daniel Barkalow @ 2005-08-22 22:10 UTC (permalink / raw)
To: Jan Veldeman; +Cc: Catalin Marinas, git
In-Reply-To: <20050821094059.GA5453@fanta>
On Sun, 21 Aug 2005, Jan Veldeman wrote:
> Catalin Marinas wrote:
>
> > > So for example, you only tag (freeze) the history when exporting the
> > > patches. When an error is being reported on that version, it's easy to view
> > > it and also view the progress that was already been made on those patches.
> >
> > I agree that it is a useful feature to be able to individually tag the
> > patches. The problem is how to do this best. Your approach looks to me
> > like it's not following the GIT DAG structure recommendation. Maybe the
> > GIT designers could further comment on this but a commit object with
> > multiple parents should be a result of a merge operation. A commit with
> > a single parent should represent a transition of the tree from one state
> > to another. With the freeze command you proposed, a commit with multiple
> > parents is no longer a result of a merge operation, but just a
> > convenience for tracking the patch history with gitk.
>
> My interpretation of parents is broader than only merges, and reading the
> README file, I believe it also the intension to do so (snippet from README
> file):
>
> A "commit" object ties such directory hierarchies together into
> a DAG of revisions - each "commit" is associated with exactly one tree
> (the directory hierarchy at the time of the commit). In addition, a
> "commit" refers to one or more "parent" commit objects that describe the
> history of how we arrived at that directory hierarchy.
One factor not mentioned there is that, as things move upstream, we often
want to discard a lot of history; if someone commits constantly to deal
with editor malfunction or something, we don't really want to take all of
this junk into the project history when it is cleaned up and accepted.
So the point is that there are things which are, in fact, parents, but we
don't want to list them, because it's not desired information.
Probably the right thing is to have two views of the stack: the internal
view, showing what actually happened, and the external view, showing what
would have happened if the developers had done everything right the first
time. When you make changes to the series, this adds to the internal view
and entirely replaces the external view.
I think that users will also want to discard the commits from the stack
before rebasing in favor of the commits after, because (a) rebasing isn't
all that interesting, especially if there's minimal merging, and (b)
otherwise you'd get a ton of boring commits that obscure the interesting
ones.
I think that the best rule would be that, when you modify a patch, the
previous version is the new version's parent, and when you rebase a
series, you include as a parent any parent of the input that isn't also in
the input (but never include the input itself as a parent of the output;
the point of rebasing is to pretend that it was the newer mainline that
you modified). This should mean that the internal history of a patch
consists of the present version, based on each version that was replaced
due to changing the patch rather than rebasing it.
Of course, there's an interesting situation with the commits earlier in a
series from a patch that was changed not being ancestors of the newer
versions of those patches (because they weren't interesting in the
development of those patches) but accessible as the commits that an
interesting patch was based on.
A possible solution is just to consider the revision of any patch a
significant event in the history of the whole stack, causing all of the
patches to get a new retained version.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: "git reset" and newly created files.
From: Junio C Hamano @ 2005-08-22 8:17 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Linus Torvalds, git
In-Reply-To: <20050821214605.GA4134@mars.ravnborg.org>
Sam Ravnborg <sam@ravnborg.org> writes:
>> So you would naturally be tempted to do this:
>>
>> ... Re-edit, compile, and test. This time it is perfect.
>> $ git commit -a -C ORIG_HEAD
>>
>> Well, not really. You can lose any file newly created in
>> ORIG_HEAD this way. Instead, you need to do this:
>>
>> ... Re-edit, compile, and test. This time it is perfect.
>> $ git add <whatever file you have changed>
>> $ git commit -a -C ORIG_HEAD
>>
>> Do people find this a big problem?
>
> I often do some maybe not that brilliant changes in my tree,
> and when I then ask git to reset these I expect git to reset
> everything.
>
> After a git-reset HEAD^ I really expect git to have rewinded back till
> where I started with no files added whatsoever.
That is another thing I initially expected from the "git reset"
command, but I do not think that is what this command is about.
It is about reverting your working tree and index file to the
state just before you make your commit to create the botched
commit, so that you can make minor fixes and recommit.
Viewing it that way, it might even be a good idea to "git add"
the files that are in ORIG_HEAD but not in the head you are
"resetting" to.
> From the matter of least suprise git should not remember files added,
> one have to do that by themself again if needed.
What I was getting at was that doing things that way means new
files and modified files are handled inconsistently. With the
current implementation, git "remembers" the files modified, but
not files added. And if the purpose of "reset" is to eventually
re-commit, it would be useful if git remembers both, not just
modified files.
One way to achieve that would be "git-update-cache --add-maybe"
I talked about in the original message, but at least something
like the following would still be an improvement. Instead of
echoing the output from diff-tree, we might even be better off
if we just feed it to "xargs git-update-cache --add".
------------
[PATCH] Remind the user of "about to be lost" files.
Files that are in the current HEAD but not in the head we are
resetting to can easily be lost when "git reset HEAD^" is
followed by re-edit and "git commit".
This patch reminds the user about those files.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff --git a/git-reset-script b/git-reset-script
--- a/git-reset-script
+++ b/git-reset-script
@@ -6,6 +6,16 @@ git-read-tree --reset "$rev" && {
if orig=$(git-rev-parse --verify HEAD 2>/dev/null)
then
echo "$orig" >"$GIT_DIR/ORIG_HEAD"
+
+ # Remind the user about files that are in ORIG_HEAD
+ # but not in $rev. We would really want to do
+ # "git-update-cache --add-maybe" on these paths, but
+ # that is not available (yet).
+ git-diff-tree -r --diff-filter=D $rev ORIG_HEAD |
+ while path
+ do
+ echo "$path: needs add"
+ done
fi
echo "$rev" > "$GIT_DIR/HEAD"
}
^ permalink raw reply
* Re: 1dfcfbce2d643b7c7b56dc828f36ced9de2bf9f2
From: Dirk Behme @ 2005-08-22 8:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vpss6bel3.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Dirk Behme <dirk.behme@de.bosch.com> writes:
>
>
>>Seems to me that this breaks http update
>>
>>cg-update http://www.kernel.org/pub/scm/git/git.git
>>
>>error: Tried
>>http://www.kernel.org/pub/scm/git/git.git/objects/6f/f87c4664981e4397625791c8ea3bbb5f2279a3
>>Cannot obtain needed blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3
>>while processing commit 1dfcfbce2d643b7c7b56dc828f36ced9de2bf9f2.
>>cg-pull: objects pull failed
>
>
> I suspect that your copy of Cogito/git is old and incapable of
> fetching from a packed repository. Did your Cogito come with
> its own copy of git (specifically, git-http-pull)? Modern
> Cogito "cg-pull" uses git-http-pull from core GIT as its
> underlying pull driver for http transport, which should not have
> the problem anymore.
My cogito source directory has no git* files any more. I update directly
from git.git and cogito.git. Last time this was done last week
(wednesday, thursday?). Is this old? I have no problems with cg-update
using http of cogito.git. I think cogito.git uses packed repository as well?
Many thanks
Dirk
^ permalink raw reply
* Re: 1dfcfbce2d643b7c7b56dc828f36ced9de2bf9f2
From: Junio C Hamano @ 2005-08-22 7:44 UTC (permalink / raw)
To: Dirk Behme; +Cc: git
In-Reply-To: <43096B50.60605@de.bosch.com>
Dirk Behme <dirk.behme@de.bosch.com> writes:
> Seems to me that this breaks http update
>
> cg-update http://www.kernel.org/pub/scm/git/git.git
>
> error: Tried
> http://www.kernel.org/pub/scm/git/git.git/objects/6f/f87c4664981e4397625791c8ea3bbb5f2279a3
> Cannot obtain needed blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3
> while processing commit 1dfcfbce2d643b7c7b56dc828f36ced9de2bf9f2.
> cg-pull: objects pull failed
I suspect that your copy of Cogito/git is old and incapable of
fetching from a packed repository. Did your Cogito come with
its own copy of git (specifically, git-http-pull)? Modern
Cogito "cg-pull" uses git-http-pull from core GIT as its
underlying pull driver for http transport, which should not have
the problem anymore.
^ permalink raw reply
* Re: 1dfcfbce2d643b7c7b56dc828f36ced9de2bf9f2
From: Dirk Behme @ 2005-08-22 6:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy86vf7lg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> A couple of people noticed that the latest commit in the
> "master" branch seems, eh, odd.
Seems to me that this breaks http update
cg-update http://www.kernel.org/pub/scm/git/git.git
error: Tried
http://www.kernel.org/pub/scm/git/git.git/objects/6f/f87c4664981e4397625791c8ea3bbb5f2279a3
Cannot obtain needed blob 6ff87c4664981e4397625791c8ea3bbb5f2279a3
while processing commit 1dfcfbce2d643b7c7b56dc828f36ced9de2bf9f2.
cg-pull: objects pull failed
Dirk
^ permalink raw reply
* Re: Pushing back to shared repo with a different named branch
From: Martin Langhoff @ 2005-08-22 3:01 UTC (permalink / raw)
To: GIT
In-Reply-To: <46a038f9050821185965869612@mail.gmail.com>
Resolved checking last week's thread of cogito push to branches:
git-push-script ssh://locke.catalyst.net.nz/var/git/project.git
master:branchname
cheers,
martin
^ permalink raw reply
* Pushing back to shared repo with a different named branch
From: Martin Langhoff @ 2005-08-22 1:59 UTC (permalink / raw)
To: GIT
Following earlier discussions, I've setup a team repo where all
heads/branches are. We have many interrelated branches so it makes
sense to keep it all together. to work, we do single-branch checkouts
using ssh like:
cg-clone locke.catalyst.net.nz:/var/git/moodle.git#mdl-osc-ceed moodle-osc-ceed
now, after a few commits, I'm ready to push back onto the branch.
cg-push won't let me, and I kind of expected that. It says:
$ cg-push origin
cg-push: pushing to a different head not supported yet
But git isn't playing ball either. What is the right incantation to
tell it to push origin to where it came from.
$ cat .git/branches/origin
locke.catalyst.net.nz:/var/git/moodle.git#mdl-osc-ceed
git-push-script origin
error: remote ref 'refs/heads/master' is not a strict subset of local
ref 'refs/heads/master'.
error: remote ref 'refs/heads/origin' is not a strict subset of local
ref 'refs/heads/origin'.
I am not using the 'remotes' setup, because I want to avoid too much
setup of each repo/working copy. Is there a simple way of doing this?
cheers,
martin
^ permalink raw reply
* git-ls-files: generalized pathspecs
From: Linus Torvalds @ 2005-08-22 0:27 UTC (permalink / raw)
To: Junio C Hamano, Git Mailing List
This generalizes the git "glob" string to be a lot more like the
git-diff-* pathspecs (but there are still differences: the diff family
doesn't do any globbing, and because the diff family always generates the
full native pathname, it doesn't have the issue with "..").
It does three things:
- it allows multiple matching strings, ie you can do things like
git-ls-files arch/i386/ include/asm-i386/ | xargs grep pattern
- the "matching" criteria is a combination of "exact path component
match" (the same as the git-diff-* family), and "fnmatch()". However,
you should be careful with the confusion between the git-ls-files
internal globbing and the standard shell globbing, ie
git-ls-files fs/*.c
does globbing in the shell, and does something totally different from
git-ls-files 'fs/*.c'
which does the globbing inside git-ls-files.
The latter has _one_ pathspec with a wildcard, and will match any .c
file anywhere under the fs/ directory, while the former has been
expanded by the shell into having _lots_ of pathspec entries, all of
which are just in the top-level fs/ subdirectory. They will happily
be matched exactly, but we will thus miss all the subdirectories under
fs/.
As a result, the first one will (on the current kernel) match 55 files,
while the second one will match 664 files!
- it uses the generic path prefixing, so that ".." and friends at the
beginning of the path spec work automatically
NOTE! When generating relative pathname output (the default), a
pathspec that causes the base to be outside the current working
directory will be rejected with an error message like:
fatal: git-ls-files: cannot generate relative filenames containing '..'
because we do not actually generate ".." in the output. However, the
".." format works fine for the --full-name case:
cd arch/i386/kernel
git-ls-files --full-name ../mm/
results in
arch/i386/mm/Makefile
arch/i386/mm/boot_ioremap.c
arch/i386/mm/discontig.c
arch/i386/mm/extable.c
arch/i386/mm/fault.c
arch/i386/mm/highmem.c
arch/i386/mm/hugetlbpage.c
arch/i386/mm/init.c
arch/i386/mm/ioremap.c
arch/i386/mm/mmap.c
arch/i386/mm/pageattr.c
arch/i386/mm/pgtable.c
Perhaps more commonly, the generic path prefixing means that "." and
"./" automatically get simplified and work properly.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
----
diff --git a/ls-files.c b/ls-files.c
--- a/ls-files.c
+++ b/ls-files.c
@@ -21,7 +21,7 @@ static int line_terminator = '\n';
static int prefix_len = 0, prefix_offset = 0;
static const char *prefix = NULL;
-static const char *glob = NULL;
+static const char **pathspec = NULL;
static const char *tag_cached = "";
static const char *tag_unmerged = "";
@@ -302,6 +302,33 @@ static int cmp_name(const void *p1, cons
e2->name, e2->len);
}
+/*
+ * Match a pathspec against a filename. The first "len" characters
+ * are the common prefix
+ */
+static int match(const char **spec, const char *filename, int len)
+{
+ const char *m;
+
+ while ((m = *spec++) != NULL) {
+ int matchlen = strlen(m + len);
+
+ if (!matchlen)
+ return 1;
+ if (!strncmp(m + len, filename + len, matchlen)) {
+ if (m[len + matchlen - 1] == '/')
+ return 1;
+ switch (filename[len + matchlen]) {
+ case '/': case '\0':
+ return 1;
+ }
+ }
+ if (!fnmatch(m + len, filename + len, 0))
+ return 1;
+ }
+ return 0;
+}
+
static void show_dir_entry(const char *tag, struct nond_on_fs *ent)
{
int len = prefix_len;
@@ -310,7 +337,7 @@ static void show_dir_entry(const char *t
if (len >= ent->len)
die("git-ls-files: internal error - directory entry not superset of prefix");
- if (glob && fnmatch(glob, ent->name + len, 0))
+ if (pathspec && !match(pathspec, ent->name, len))
return;
printf("%s%s%c", tag, ent->name + offset, line_terminator);
@@ -373,7 +400,7 @@ static void show_ce_entry(const char *ta
if (len >= ce_namelen(ce))
die("git-ls-files: internal error - cache entry not superset of prefix");
- if (glob && fnmatch(glob, ce->name + len, 0))
+ if (pathspec && !match(pathspec, ce->name, len))
return;
if (!show_stage)
@@ -455,36 +482,44 @@ static void prune_cache(void)
active_nr = last;
}
-/*
- * If the glob starts with a subdirectory, append it to
- * the prefix instead, for more efficient operation.
- *
- * But we do not update the "prefix_offset", which tells
- * how much of the name to ignore at printout.
- */
-static void extend_prefix(void)
+static void verify_pathspec(void)
{
- const char *p, *slash;
- char c;
+ const char **p, *n, *prev;
+ char *real_prefix;
+ unsigned long max;
+
+ prev = NULL;
+ max = PATH_MAX;
+ for (p = pathspec; (n = *p) != NULL; p++) {
+ int i, len = 0;
+ for (i = 0; i < max; i++) {
+ char c = n[i];
+ if (prev && prev[i] != c)
+ break;
+ if (c == '*' || c == '?')
+ break;
+ if (c == '/')
+ len = i+1;
+ }
+ prev = n;
+ if (len < max) {
+ max = len;
+ if (!max)
+ break;
+ }
+ }
+
+ if (prefix_offset > max || memcmp(prev, prefix, prefix_offset))
+ die("git-ls-files: cannot generate relative filenames containing '..'");
- p = glob;
- slash = NULL;
- while ((c = *p++) != '\0') {
- if (c == '*')
- break;
- if (c == '/')
- slash = p;
- }
- if (slash) {
- int len = slash - glob;
- char *newprefix = xmalloc(len + prefix_len + 1);
- memcpy(newprefix, prefix, prefix_len);
- memcpy(newprefix + prefix_len, glob, len);
- prefix_len += len;
- newprefix[prefix_len] = 0;
- prefix = newprefix;
- glob = *slash ? slash : NULL;
+ real_prefix = NULL;
+ prefix_len = max;
+ if (max) {
+ real_prefix = xmalloc(max + 1);
+ memcpy(real_prefix, prev, max);
+ real_prefix[max] = 0;
}
+ prefix = real_prefix;
}
static const char ls_files_usage[] =
@@ -499,7 +534,7 @@ int main(int argc, char **argv)
prefix = setup_git_directory();
if (prefix)
- prefix_offset = prefix_len = strlen(prefix);
+ prefix_offset = strlen(prefix);
for (i = 1; i < argc; i++) {
char *arg = argv[i];
@@ -577,13 +612,16 @@ int main(int argc, char **argv)
prefix_offset = 0;
continue;
}
- if (glob || *arg == '-')
+ if (*arg == '-')
usage(ls_files_usage);
- glob = arg;
+ break;
}
- if (glob)
- extend_prefix();
+ pathspec = get_pathspec(prefix, argv + i);
+
+ /* Verify that the pathspec matches the prefix */
+ if (pathspec)
+ verify_pathspec();
if (show_ignored && !exc_given) {
fprintf(stderr, "%s: --ignored needs some exclude pattern\n",
^ permalink raw reply
* Re: [RFC] Stgit - patch history / add extra parents
From: Junio C Hamano @ 2005-08-23 1:06 UTC (permalink / raw)
To: Jan Veldeman; +Cc: git, Catalin Marinas
In-Reply-To: <20050821094059.GA5453@fanta>
Jan Veldeman <jan.veldeman@gmail.com> writes:
> ... So as you said: we indeed need a git designer to clear this up
> for us.
I understand I am counted as one of the "git designers"; I have
been aware of this thread but I have to admit that I am way
behind and have not caught up with the issues. I'll try to
comment on them when I feel I know enough about the issues
involved, but not right now. Sorry.
Please do not start explain them to me yet, I am behind due to
lack of time and you would end up wasting your time.
^ permalink raw reply
* Re: Multi-head pulling series
From: Junio C Hamano @ 2005-08-23 1:07 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200508221835.31275.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> I think that both, default and non-default persistant
> mappings, are only a handy convenience issue for less
> typing. If GIT core is not doing this, some (most?) porcelains
> will invent their own way for storing these mappings (like
> Cogito is doing with branches/). I think it is better if this
> is "standardized".
I agree in principle, and it should not be hard to add support
for optional "Default-pull" and "Default-push" keywords to
remotes/ files (lack of which means to use LHS of refspecs on
"Pull" or "Push" lines) to git-parse-remote-script. Patches
welcome.
> Currently missing here is automatic detection of the remote
> repository for a given head to be pulled/pushed. But this is
> no format issue.
"git ls-remote <repo>" perhaps?
^ permalink raw reply
* Re: 1dfcfbce2d643b7c7b56dc828f36ced9de2bf9f2
From: Junio C Hamano @ 2005-08-23 1:07 UTC (permalink / raw)
To: Dirk Behme; +Cc: git
In-Reply-To: <430988A7.60906@de.bosch.com>
Dirk Behme <dirk.behme@de.bosch.com> writes:
>>>Seems to me that this breaks http update
Let's clarify one thing first. Did you mean "git rebuilt from
the sources obtained from that seemingly-odd commit, http update
does not work anymore", or did you mean "starting from the state
my repository happened to be in, attempting to pull from the
git.git repository did not work, and the master branch head of
git.git public repository was that commit"?
First we need to make sure your git binary from last week
wednesday or thursday is recent enough. I think you need at
least this commit:
Author: Daniel Barkalow <barkalow@iabervon.org>
Date: Thu Aug 11 23:17:55 2005 -0400
[PATCH] Also parse objects we already have
In the case where we don't know from context what type
an object is, but we don't have to fetch it, we need to
parse it to determine the type before processing it.
If your git binary turns out to be recent enough, then the state
of your repository is needed to diagnose this problem. What do
these command tell you in your git.git repository that cg-pull
from the public repository fails?
$ git fsck-cache | grep -v '^dangling '
$ git ls-remote --heads ./.
$ ls .git/objects/pack
[Note to people who are interested in what I plan to do with the
output from the above commands. If fsck-cache reports any
anomaly other than dangling objects, that means the repository
before pulling is corrupt and the problem is not in http-pull.
Otherwise, I can first make a clone of my git.git repository
while expanding all the packs, overwrite the head references to
what "git ls-remotes" reports for Dirk's repository, run "git
prune" to lose objects Dirk would not have, and then try
running git-http-pull myself.
What set of packs Dirk has (and does not have) is there for
sanity checking --- if he has packs that I do not have myself,
that means he packed his repository himself. Which is not an
illegal thing to do at all, and I do not think that would
affect the operation of http-pull, it would be a good thing to
know while digging deeper, hence the request for that
information. ]
^ permalink raw reply
* [PATCH] Fix "git-diff-script A B"
From: Junio C Hamano @ 2005-08-23 1:07 UTC (permalink / raw)
To: git
When "git-diff-script A..B" notation was introduced, it ended up breaking
the traditional two revisions notation.
[jc: there are other issues with the current "git diff" I would like to
address, but they would be left to later rounds. For example, -M and -p flags
should not be hardcoded default, and it shouldn't be too hard to rewrite
the script without using shell arrays.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-diff-script | 10 ++++++++--
1 files changed, 8 insertions(+), 2 deletions(-)
30e852431bd6b6f8395646749c5baa8cfca88b51
diff --git a/git-diff-script b/git-diff-script
--- a/git-diff-script
+++ b/git-diff-script
@@ -8,8 +8,14 @@ case "${#rev[*]}" in
1)
git-diff-cache -M -p "$@";;
2)
- begin=$(echo "${rev[1]}" | tr -d '^')
- end="${rev[0]}"
+ case "${rev[1]}" in
+ ^?*)
+ begin=$(echo "${rev[1]}" | tr -d '^')
+ end="${rev[0]}" ;;
+ *)
+ begin="${rev[0]}"
+ end="${rev[1]}" ;;
+ esac
git-diff-tree -M -p $flags $begin $end $files;;
*)
echo "I don't understand"
^ permalink raw reply
* [PATCH] Introduce "reset type" flag to "git reset"
From: Junio C Hamano @ 2005-08-23 1:07 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds, Sam Ravnborg
I have been feeling that the current behaviour of "git reset" is
not quite optimal, but so far could not express exactly what I
felt was wrong with it. This patch clarifies it.
There are at least two situations you may want to "reset" your
working tree.
1. You made a mess in your working tree. You want to switch
back to a known good state and start over. This mess may be
a result of your own editing, a merge that had too many
conflicting changes that you do not feel like to resolve by
hand at this moment, or a botched application of a patch you
received from somewhere.
In this case, you would want to have "git reset HEAD" reset
the index file to the tree read from the HEAD commit and the
files in the working tree to match index (i.e. "git status"
should say "Nothing to commit", without any "unrecorded
changes").
The current behaviour leaves the files in the working tree
intact, which requires you to run "git checkout -f". Also
you need to remember "rm -f" any files that the botched patch
may have left in the working tree if the purpose of this
"reset" is to attempt to apply it again; most likely the
patch would fail if such a file is left behind.
2. You have discovered that commits you made earlier need to be
reorganized. The simplest example is to undo the last
commit, re-edit some files, and redo the commit. Another
simple eample is to undo the last two commits, and commit the
changes in those two commits as a single commit.
In this case, you would want to have "git reset HEAD^" reset
the $GIT_DIR/HEAD to the commit object name of the parent
commit of the current commit (i.e. rewinding one commit),
leave the index file and the files in the working tree in a
state where you can easily make a commit that records a tree
that resembles what you have in the current index file and
the working tree.
The current behaviour is almost OK for this purpose, except
that you need to find which files you need to manually run
"git add" yourself. They are files that are in the original
HEAD commit and not in the commit you are resetting to.
The default without the type flag is to do "--mixed", which is
the current behaviour.
$ git reset [ --hard | --soft | --mixed ] [ <commit-ish> ]
A hard reset would be used for 1 and works in this way:
(1) remember the set of paths that appear in the current
index file (which may even have unmerged entries) and
the current $GIT_DIR/HEAD commit.
(2) "read-tree --reset" the specified <commit-ish> (default
to HEAD), followed by "checkout-cache -f -u -a".
(3) remove any files that appear in (1) but not in
<commit-ish> from the working tree.
(4) backup $GIT_DIR/HEAD to $GIT_DIR/ORIG_HEAD and update
$GIT_DIR/HEAD with the specified <commit-ish>.
(5) remove leftover $GIT_DIR/MERGE_HEAD
A soft reset would be used for 2 and works in this way:
(1) Make sure that the index file is merged and we do not
have MERGE_HEAD; otherwise it does not make sense to do
soft reset.
(2) backup $GIT_DIR/HEAD to $GIT_DIR/ORIG_HEAD and update
$GIT_DIR/HEAD with the specified <commit-ish>.
Note that with the current behaviour, "git diff" is the way to
see what could be committed immediately after "git reset". With
the "soft reset" described here you would need to say "git diff
HEAD" to find that out.
I am not sure what mixed reset (the current behaviour) is good
for. If nobody comes up with a good use case it may not be a
bad idea to remove it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
git-reset-script | 96 +++++++++++++++++++++++++++++++++++++++++++++++++++---
1 files changed, 90 insertions(+), 6 deletions(-)
c0e136c6ab8481fb4927f033bb7da105b7417207
diff --git a/git-reset-script b/git-reset-script
--- a/git-reset-script
+++ b/git-reset-script
@@ -1,13 +1,97 @@
#!/bin/sh
. git-sh-setup-script || die "Not a git archive"
+
+tmp=/var/tmp/reset.$$
+trap 'rm -f $tmp-*' 0 1 2 3 15
+
+reset_type=--mixed
+case "$1" in
+--mixed | --soft | --hard)
+ reset_type="$1"
+ shift
+ ;;
+esac
+
rev=$(git-rev-parse --verify --default HEAD "$@") || exit
rev=$(git-rev-parse --verify $rev^0) || exit
-git-read-tree --reset "$rev" && {
- if orig=$(git-rev-parse --verify HEAD 2>/dev/null)
+
+# We need to remember the set of paths that _could_ be left
+# behind before a hard reset, so that we can remove them.
+if test "$reset_type" = "--hard"
+then
+ {
+ git-ls-files --stage -z
+ git-rev-parse --verify HEAD 2>/dev/null &&
+ git-ls-tree -r -z HEAD
+ } | perl -e '
+ use strict;
+ my %seen;
+ $/ = "\0";
+ while (<>) {
+ chomp;
+ my ($info, $path) = split(/\t/, $_);
+ next if ($info =~ / tree /);
+ if (!$seen{$path}) {
+ $seen{$path} = 1;
+ print "$path\0";
+ }
+ }
+ ' >$tmp-exists
+fi
+
+# Soft reset does not touch the index file nor the working tree
+# at all, but requires them in a good order. Other resets reset
+# the index file to the tree object we are switching to.
+if test "$reset_type" = "--soft"
+then
+ if test -f "$GIT_DIR/MERGE_HEAD" ||
+ test "" != "$(git-ls-files --unmerged)"
then
- echo "$orig" >"$GIT_DIR/ORIG_HEAD"
+ die "Cannot do a soft reset in the middle of a merge."
fi
- echo "$rev" > "$GIT_DIR/HEAD"
-}
-git-update-cache --refresh
+else
+ git-read-tree --reset "$rev" || exit
+fi
+
+# Any resets update HEAD to the head being switched to.
+if orig=$(git-rev-parse --verify HEAD 2>/dev/null)
+then
+ echo "$orig" >"$GIT_DIR/ORIG_HEAD"
+else
+ rm -f "$GIT_DIR/ORIG_HEAD"
+fi
+echo "$rev" >"$GIT_DIR/HEAD"
+
+case "$reset_type" in
+--hard )
+ # Hard reset matches the working tree to that of the tree
+ # being switched to.
+ git-checkout-cache -f -u -q -a
+ git-ls-files --cached -z |
+ perl -e '
+ use strict;
+ my (%keep, $fh);
+ $/ = "\0";
+ while (<STDIN>) {
+ chomp;
+ $keep{$_} = 1;
+ }
+ open $fh, "<", $ARGV[0]
+ or die "cannot open $ARGV[0]";
+ while (<$fh>) {
+ chomp;
+ if (! exists $keep{$_}) {
+ print "$_\0";
+ }
+ }
+ ' $tmp-exists | xargs -0 rm -v -f --
+ ;;
+--soft )
+ ;; # Nothing else to do
+--mixed )
+ # Report what has not been updated.
+ git-update-cache --refresh
+ ;;
+esac
+
rm -f "$GIT_DIR/MERGE_HEAD"
^ permalink raw reply
* Re: suggestion: store the URL somewhere in .git/
From: Jeff Carr @ 2005-08-23 1:46 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0508222217310.695@wgmdd8.biozentrum.uni-wuerzburg.de>
On 08/22/2005 01:18 PM, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 22 Aug 2005, Jeff Carr wrote:
>
>
>>It would be nice if the URL could be stored somewhere in .git/ This
>>makes it a lot easier to update repositories because you don't always
>>have to go and track down where you got it in the first place.
>
>
> This is why your original target (when you clone) is stored as "origin".
OK. I rsync'ed the repository directly so a origin file wasn't created.
That explains that. So my small "feature" request reduces to adding
something like this to git-pull-script. Thanks, Jeff
diff --git a/git-pull-script b/git-pull-script
--- a/git-pull-script
+++ b/git-pull-script
@@ -1,10 +1,20 @@
#!/bin/sh
#
+ORIGIN="$@"
+
+if [ ! $ORIGIN ]
+then
+ if [ -f .git/branches/origin ]
+ then
+ ORIGIN=`cat .git/branches/origin`
+ fi
+fi
+
. git-sh-setup-script || die "Not a git archive"
-. git-parse-remote "$@"
+. git-parse-remote "$ORIGIN"
merge_name="$_remote_name"
-git-fetch-script "$@" || exit 1
+git-fetch-script "$ORIGIN" || exit 1
git-resolve-script \
"$(cat "$GIT_DIR"/HEAD)" \
^ permalink raw reply
* git-ls-new-files & make patch, pull, etc.
From: Jeff Carr @ 2005-08-23 2:07 UTC (permalink / raw)
To: git
Something simple like the perl script at the bottom would be useful for
showing files that haven't been added via git-update-cache --add already.
I've also found it useful to start adding things to the Makefile's of
the projects I'm putting in git repositories. I think it would be useful
to come up with some standard or recommended names. That could start to
extend the common "make" "make install" with a few other options for
projects that use git as their SCM.
Thanks,
Jeff
patch:
git-diff-files -p
push:
git-send-pack `cat .git/branches/origin`
pull:
git-pull-script `cat .git/branches/origin`
git-read-tree -m HEAD
git-checkout-cache -q -f -u -a
commit:
vi changelog.txt
GIT_AUTHOR_NAME="$(GIT_AUTHOR_NAME)" \
GIT_AUTHOR_EMAIL="$(GIT_AUTHOR_EMAIL)" \
git-commit-tree `git-write-tree` -p $(HEAD) < changelog.txt > .git/HEAD
rm changelog.txt
add_all:
./git-ls-new-files |xargs -n 1 git-update-cache --add
#!/usr/bin/perl
# Shows you what files have not been added to your git repository
my %allfiles;
# make a hash of all the files except the .git/ directory
foreach my $file ( `find . -type f` ) {
chomp $file;
next if substr($file, 0, 7) eq "./.git/";
$allfiles{ $file } = "";
}
# now delete all the files from the hash that are already commited
foreach my $file ( split "\n", `git-ls-files` ) {
chomp $file;
delete $allfiles{ "./$file" };
}
# print out what's left
foreach my $file ( sort keys %allfiles ) {
print "$file\n";
}
^ permalink raw reply
* Re: git-ls-new-files & make patch, pull, etc.
From: Junio C Hamano @ 2005-08-23 5:15 UTC (permalink / raw)
To: Jeff Carr; +Cc: git
In-Reply-To: <430A84D1.2050206@linuxmachines.com>
Jeff Carr <jcarr@linuxmachines.com> writes:
> Something simple like the perl script at the bottom would be useful for
> showing files that haven't been added via git-update-cache --add already.
If I am not mistaken, you just reinvented:
$ git ls-files --others
in a very expensive way. Notice your `find . -type f` that does
not prune .git directory upfront.
Also you may want to take a look at:
$ git ls-files --others --exclude-from=.git/info/exclude
^ permalink raw reply
* Re: suggestion: store the URL somewhere in .git/
From: Junio C Hamano @ 2005-08-23 5:16 UTC (permalink / raw)
To: Jeff Carr; +Cc: git
In-Reply-To: <430A7FE6.4010801@linuxmachines.com>
Jeff Carr <jcarr@linuxmachines.com> writes:
> So my small "feature" request reduces to adding
> something like this to git-pull-script. Thanks, Jeff
Somebody else earlier asked for fetch and pull to default to
"origin" URL, and the necessary change is already in the
proposed updates branch.
^ permalink raw reply
* Re: Multi-head pulling series
From: Junio C Hamano @ 2005-08-23 5:37 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200508221835.31275.Josef.Weidendorfer@gmx.de>
Josef Weidendorfer <Josef.Weidendorfer@gmx.de> writes:
> I think that both, default and non-default persistant
> mappings, are only a handy convenience issue for less
> typing. If GIT core is not doing this, some (most?) porcelains
> will invent their own way for storing these mappings.
Suppose I have something like this in $GIT_DIR/remotes/ko:
URL: master.kernel.org:/pub/scm/git/git.git/
Pull: master:ko-master rc:ko-rc pu:ko-pu
Push: master:master pu:pu rc:rc
Default-Pull: master rc
That is, "Pull/Push" describe only the default mappings, and
"Default-Pull/Default-Push" names the refs pulled or pushed when
only the shorthand (ko) is specified. I think that is what your
proposal boils down to. Lack of "Default-Push" just means use
the heads listed on "Push" line for the default.
Am I reading you right so far?
With that definition, what these would do would be intuitive and
obvious:
$ git push ko ;# my master, rc, and pu goes there, under
# the same name.
$ git fetch ko ;# their master comes to my ko-master, rc to my ko-rc
# pu is not touched.
But now, what should this do?
$ git fetch ko master
(1) does it use "Pull" mappings and use their "master" to fast
forward my "ko-master"?
or
(2) does it obey "the command line overrides the configuration
file" principle and fetch their "master" but not touch my
local refs (remember, refspec "master" without colon is
equivalent to "master:" in fetch, which means "get the
objects to complete it, but do not store the ref locally")?
If (1), then I would need to say "master:something" on the
command line almost all the time, because the point of remotes/
configuration file is that I do not have to remember which
remote head corresponds to my local head, and by definition I
would not (and should not have to) know if "master" has the
default mappings specified there and to which head, so even that
"something" happens to be exactly what is in the remotes/ file,
I would end up typing that explicitly. Which means that it
defeats the point of having the configuration file to begin
with.
If (2), then I would again need to say master:ko-master if I
wanted to mean "usually I pull from some heads (I do not
remember which ones offhand, but my .git/remotes/ file would
know), but this time I want to only pull from master and update
ko-master".
What this suggests to me is that making set of default refs to
be pulled from and set of ref mappings orthgonal sounds like a
good and clean way in theory, but would not be that much useful
in practice.
^ permalink raw reply
* cogito and merging in steps.
From: Martin Langhoff @ 2005-08-23 6:29 UTC (permalink / raw)
To: GIT
Is there any way to merge patches "selectively"?
I have found that if I do
cg-pull
cg-log -r master:origin
I can review the commits that will be merged if I do cg-update.
Say I do cg-update, it brings a lot of commits and there is a messy
conflict. I immediately can narrow down on which commit I am merging
it is that has a conflict.
With this info, it'd be interesting to be able to merge not to the tip
of the head (head of the head? =- bah, tip of the branch! :) but to an
earlier commit, so I can resolve the conflict with a more specific
commit.
Say I am merging a series of 10 commits that happened in the shared
repo to the project while I worked disconnected (and did lots of local
commits). The first 8 commits merge cleanly, the 9th is an ugly
conflict I have to resolve, and the 10th is clean and unrelated.
I want to be able to
- cg-update
- oops! this is a mess! review with cg-log -r master:origin
- aha! Here is the conflict in the 9th commit from MacFroz, fire off
email / open irc session
- in the meantime, reset the working copy and merge the 8 clean ones
with something like: cg-restore ; cg-update origin^^^ ; cg-commit
- cg-update origin^ ; emacs file-with-conflict.c ; cg-commit
- cg-update # bring in the last pending commit from origin.
How can I achieve the cg-update <somepointinthebranch> ; cg-commit ? I
mean, without faking a head with
echo <somepointinthebranch> > .git/refs/heads/temphead
cheers,
martin
cheers,
martin
^ permalink raw reply
* Re: git-ls-new-files & make patch, pull, etc.
From: Johannes Schindelin @ 2005-08-23 6:48 UTC (permalink / raw)
To: Jeff Carr; +Cc: git
In-Reply-To: <430A84D1.2050206@linuxmachines.com>
Hi,
On Mon, 22 Aug 2005, Jeff Carr wrote:
> patch:
> git-diff-files -p
"git diff"
> push:
> git-send-pack `cat .git/branches/origin`
"git push origin" (or maybe "git push HEAD:origin")
> pull:
> git-pull-script `cat .git/branches/origin`
> git-read-tree -m HEAD
> git-checkout-cache -q -f -u -a
"git pull origin"
> commit:
> vi changelog.txt
> GIT_AUTHOR_NAME="$(GIT_AUTHOR_NAME)" \
> GIT_AUTHOR_EMAIL="$(GIT_AUTHOR_EMAIL)" \
> git-commit-tree `git-write-tree` -p $(HEAD) < changelog.txt > .git/HEAD
> rm changelog.txt
"git commit"
> add_all:
> ./git-ls-new-files |xargs -n 1 git-update-cache --add
"git add $(git ls-files --others)"
Ciao,
Dscho
^ permalink raw reply
* git-rev-parse question.
From: Junio C Hamano @ 2005-08-23 8:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
I have been looking at what git-rev-parse does and could not
figure out a way to convince it to give me only arguments with
a '-' prefix. Specifically, I wanted to remove the hardcoded -p
and -M flags from git-diff-script. Running
$ sh -x git-diff-script -C HEAD^ HEAD
reveals that none of the following would pick up "-C" from the
command line:
rev=($(git-rev-parse --revs-only "$@")) || exit
flags=($(git-rev-parse --no-revs --flags "$@"))
files=($(git-rev-parse --no-revs --no-flags "$@"))
I am not even sure if the current implementation of rev-parse
matches what you originally wanted it to do; I suspect it does
not. I would like to know what was the intended behaviour
first, so that I can enhance it to be usable for my purpose
without breaking things.
What I want the rev-parse flags to mean is as follows. By "rev
argument", I mean what get_sha1() can understand. I have to
admit that some flags are what I introduced while I was
butchering it without really knowing the original intention:
output format:
--sq output in a format usable for shell "eval".
--symbolic output rev argument in symbolic form, not SHA1.
output selection:
--flags show only arguments with '-' prefix.
--no-flags do not show arguments with '-' prefix.
--revs-only show only arguments meant for rev-list.
--no-revs show arguments not meant for rev-list.
input munging:
--default R if no revision, pretend R is given.
--not pretend all rev arguments without prefix ^ have
prefix ^, and the ones with prefix ^ do not.
--all pretend all refs under $GIT_DIR/refs are given
on the command line.
special:
--verify make sure only one rev argument is given, nothing else.
I think flags/no-flags and revs-only/no-revs *should* be
orthogonal. That is, "rev-parse --flags --no-revs" should give
parameters that start with '-' and not meant for rev-list
(e.g. '-C' in earlier example); "rev-parse --revs-only
--merge-order HEAD Documentation/" should yield "--merge-order
HEAD".
Also there is an undocumented --show-prefix. What is it?
-jc
PS. BTW, any response about unsuspecting companies?
^ 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