* Re: "git revert" (Re: pci_update_resource() getting called on sparc64)
From: Junio C Hamano @ 2005-08-08 20:47 UTC (permalink / raw)
To: Linus Torvalds; +Cc: git
In-Reply-To: <Pine.LNX.4.58.0508081257190.3258@g5.osdl.org>
Linus Torvalds <torvalds@osdl.org> writes:
>> It may not have the nicest error messages: if you try to revert a merge
>> (which won't have a diff), git-apply will say something like
>>
>> fatal: No changes
>>
>> which isn't exactly being helpful. And the revert message could be made
>> more interesting (like putting the first line of the description of what
>> we reverted into the message instead of just the revision number).
> Comments?
>
> Linus
I like the general idea, and if we had a commit pretty format
"oneline", then something like this would make it look nicer.
Totally untested. I acquired your habit of coding in my e-mail
client ;-).
#!/bin/sh
. git-sh-setup-script || die "Not a git archive"
rev=$(git-rev-parse --verify --revs-only "$@") &&
commit=$(git-rev-parse --verify --revs-only "$commit^0") || exit
if git-diff-tree -R -p $commit | git-apply --index &&
msg=$(git-rev-list --pretty=oneline --max-count=1 $commit)
then
{
echo "Revert $msg"
echo
echo "This reverts $commit commit."
test "$rev" = "$commit" ||
echo "(original 'git revert' arguments: $@)"
} | git commit
else
# Now why did it fail?
parents=`git-cat-file commit "$commit" 2>/dev/null |
sed -ne '/^$/q;/^parent /p' |
wc -l`
case $parents in
0) die "Cannot revert the root commit nor non commit-ish" ;;
1) die "The patch does not apply" ;;
*) die "Cannot revert a merge commit" ;;
esac
fi
^ permalink raw reply
* [PATCH 1/1] git_mkstemp() fix
From: Holger Eitzenberger @ 2005-08-08 20:33 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 84 bytes --]
Hi,
attached is a bugfix for the newly introduced git_mkstemp() function.
/holger
[-- Attachment #2: git_mkstemp_fix.patch --]
[-- Type: text/x-patch, Size: 819 bytes --]
git_mkstemp() bugfix
---
commit 8cccfa75e0095afd2dd4ec354f2786068c9e7a2f
tree 354e00b03039e0c42284442c9764dcd3bf8f608f
parent d59a6043a8a7aed97c684fb4f14fe5221df1fcaf
author Holger Eitzenberger <holger@my-eitzenberger.de> Mon, 08 Aug 2005 23:29:28 +0200
committer Holger Eitzenberger <holger@jonathan.my-eitzenberger.de> Mon, 08 Aug 2005 23:29:28 +0200
path.c | 9 +++++++--
1 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/path.c b/path.c
--- a/path.c
+++ b/path.c
@@ -68,8 +68,13 @@ int git_mkstemp(char *path, size_t len,
if ((env = getenv("TMPDIR")) == NULL) {
strcpy(pch, "/tmp/");
len -= 5;
- } else
- len -= snprintf(pch, len, "%s/", env);
+ pch += 5;
+ } else {
+ size_t n = snprintf(pch, len, "%s/", env);
+
+ len -= n;
+ pch += n;
+ }
safe_strncpy(pch, template, len);
^ permalink raw reply
* "git revert" (Re: pci_update_resource() getting called on sparc64)
From: Linus Torvalds @ 2005-08-08 19:57 UTC (permalink / raw)
To: Git Mailing List
In-Reply-To: <Pine.LNX.4.58.0508081249110.3258@g5.osdl.org>
Comments?
Linus
On Mon, 8 Aug 2005, Linus Torvalds wrote:
>
>
> On Mon, 8 Aug 2005, Greg KH wrote:
> >
> > Hm, how do you revert a git patch?
>
> Something like this?
>
> #!/bin/sh
> . git-sh-setup-script || die "Not a git archive"
> rev=$(git-rev-parse --verify --revs-only "$@") || exit
> git-diff-tree -R -p $rev | git-apply --index &&
> echo "Revert $rev" | git commit
>
> Just name it "git-revert-script" and it might do what you want to do.
>
> It may not have the nicest error messages: if you try to revert a merge
> (which won't have a diff), git-apply will say something like
>
> fatal: No changes
>
> which isn't exactly being helpful. And the revert message could be made
> more interesting (like putting the first line of the description of what
> we reverted into the message instead of just the revision number).
>
> Linus
>
^ permalink raw reply
* Re: Request for help from binary packaging people.
From: Chris Wright @ 2005-08-08 18:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtmw5nx7.fsf_-_@assigned-by-dhcp.cox.net>
* Junio C Hamano (junkio@cox.net) wrote:
> For RPM, from my lack of RPM expertise (and RPM capable
> environment until recently), I have not updated the "Prereq:"
> field in git-core.spec.in at all. I would appreciate somebody
> to sanity check the list of dependencies. The dependency list
> Debian side has is more up-to-date and I am reasonably sure it
> is accurate. It lists patch, diff, and rcs (for the "merge"
> command) as the essential dependency (aside from the shared
> libraries like libc), and libmail-sendmail-perl, rsync, curl,
> ssh, and libemail-valid-perl as the recommended dependency. I
> do not even know if RPM has the notion of such multi-tier
> dependencies, but the latter list is meant to mean "you could
> live without these, but to exercise this package fully you may
> want them" (in our case of git-core, you could live without the
> networking if you do not do multi-user, multi-repository). If
> RPM spec file has a way to say something like that, I would like
> to see these packages (probably their names are different
> between Debian and RPM) listed on the recommended dependency
> list; otherwise I would want to see them added to the main
> "Prereq:" list.
I'd say the proper rpm method would be with subpackages with their own
prereqs. Also, rpm is able to determine the perl dependencies
automatically (of course, ditto for shared libraries).
Now, the only issue is this package is unlikely to install because of the
Mail/Sendmail.pm and Email/Valid.pm requirements. We can add specific
package requirements for those since they are less common.
Here's the actual install dependency list:
$ rpm -qp /home/chrisw/rpms/RPMS/i386/git-core-0.99.4-1.i386.rpm --requires
/bin/sh
/usr/bin/env
/usr/bin/perl
diffutils
libc.so.6
libc.so.6(GLIBC_2.0)
libc.so.6(GLIBC_2.1)
libc.so.6(GLIBC_2.1.3)
libc.so.6(GLIBC_2.2.3)
libc.so.6(GLIBC_2.3)
libcrypto.so.4
libcurl.so.3
libssl.so.4
libz.so.1
mktemp >= 1.5
perl(Data::Dumper)
perl(Email::Valid)
perl(File::Basename)
perl(File::Path)
perl(File::Spec)
perl(File::Temp)
perl(Getopt::Long)
perl(Getopt::Std)
perl(IO::Pipe)
perl(IO::Socket)
perl(Mail::Sendmail)
perl(POSIX)
perl(Term::ReadLine)
perl(Time::Local)
perl(strict)
perl(warnings)
rcs
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(VersionedDependencies) <= 3.0.3-1
rsync
sh-utils
^ permalink raw reply
* [PATCH 4/4] Plug memory leak in git-pack-objects
From: Sergey Vlasov @ 2005-08-08 18:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050808184332.GA5789@procyon.home>
[PATCH] Plug memory leak in git-pack-objects
find_deltas() should free its temporary objects before returning.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
pack-objects.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
8b38f80b97affd0d9808b8f276a9e2e04bf03464
diff --git a/pack-objects.c b/pack-objects.c
--- a/pack-objects.c
+++ b/pack-objects.c
@@ -382,6 +382,10 @@ static void find_deltas(struct object_en
if (idx >= window)
idx = 0;
}
+
+ for (i = 0; i < window; ++i)
+ free(array[i].data);
+ free(array);
}
int main(int argc, char **argv)
^ permalink raw reply
* [PATCH 3/4] Plug memory leak in sha1close()
From: Sergey Vlasov @ 2005-08-08 18:46 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050808184332.GA5789@procyon.home>
[PATCH] Plug memory leak in sha1close()
sha1create() and sha1fd() malloc the returned struct sha1file;
sha1close() should free it.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
csum-file.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
2207ae4977cbaa84636487ca24bad9d1116f54e0
diff --git a/csum-file.c b/csum-file.c
--- a/csum-file.c
+++ b/csum-file.c
@@ -45,6 +45,7 @@ int sha1close(struct sha1file *f, unsign
sha1flush(f, 20);
if (close(f->fd))
die("%s: sha1 file error on close (%s)", f->name, strerror(errno));
+ free(f);
return 0;
}
^ permalink raw reply
* [PATCH 2/4] Plug memory leak in write_sha1_to_fd()
From: Sergey Vlasov @ 2005-08-08 18:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050808184332.GA5789@procyon.home>
[PATCH] Plug memory leak in write_sha1_to_fd()
If the object to write was packed, both its uncompressed and compressed
data were leaked. If the object was not packed, its file was not unmapped.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
sha1_file.c | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
683b9e4bb090c115242392a1f1dc7b1a7c76c4be
diff --git a/sha1_file.c b/sha1_file.c
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1297,8 +1297,11 @@ int write_sha1_to_fd(int fd, const unsig
ssize_t size;
unsigned long objsize;
int posn = 0;
- void *buf = map_sha1_file_internal(sha1, &objsize);
+ void *map = map_sha1_file_internal(sha1, &objsize);
+ void *buf = map;
+ void *temp_obj = NULL;
z_stream stream;
+
if (!buf) {
unsigned char *unpacked;
unsigned long len;
@@ -1314,7 +1317,7 @@ int write_sha1_to_fd(int fd, const unsig
memset(&stream, 0, sizeof(stream));
deflateInit(&stream, Z_BEST_COMPRESSION);
size = deflateBound(&stream, len + hdrlen);
- buf = xmalloc(size);
+ temp_obj = buf = xmalloc(size);
/* Compress it */
stream.next_out = buf;
@@ -1332,6 +1335,7 @@ int write_sha1_to_fd(int fd, const unsig
while (deflate(&stream, Z_FINISH) == Z_OK)
/* nothing */;
deflateEnd(&stream);
+ free(unpacked);
objsize = stream.total_out;
}
@@ -1348,6 +1352,12 @@ int write_sha1_to_fd(int fd, const unsig
}
posn += size;
} while (posn < objsize);
+
+ if (map)
+ munmap(map, objsize);
+ if (temp_obj)
+ free(temp_obj);
+
return 0;
}
^ permalink raw reply
* [PATCH 1/4] Plug memory leak in read_object_with_reference()
From: Sergey Vlasov @ 2005-08-08 18:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20050808184332.GA5789@procyon.home>
[PATCH] Plug memory leak in read_object_with_reference()
When following a reference, read_object_with_reference() did not free the
intermediate object data.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
---
sha1_file.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
f7d16d6b83698fd7858ad28340b3e87780322261
diff --git a/sha1_file.c b/sha1_file.c
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1165,6 +1165,7 @@ void *read_object_with_reference(const u
free(buffer);
return NULL;
}
+ free(buffer);
/* Now we have the ID of the referred-to object in
* actual_sha1. Check again. */
}
^ permalink raw reply
* [PATCH 0/4] Plug some more memory leaks in git
From: Sergey Vlasov @ 2005-08-08 18:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 193 bytes --]
Hello!
This set of patches fixes some more memory leaks which I have found in
git. Especially the write_sha1_to_fd() leak was noticeable when
running git-ssh-push.
--
Sergey Vlasov
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Request for help from binary packaging people.
From: Sergey Vlasov @ 2005-08-08 18:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwtmw5nx7.fsf_-_@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 2797 bytes --]
On Mon, 08 Aug 2005 10:38:44 -0700 Junio C Hamano wrote:
> For RPM, from my lack of RPM expertise (and RPM capable
> environment until recently), I have not updated the "Prereq:"
> field in git-core.spec.in at all.
That "Prereq:" should be "Requires:" instead. "Prereq:" also
enforces installation ordering between packages; it is required
when the package has some installation scripts (%pre, %post) -
in this case all packages which are needed to execute these
scripts must be listed in "Prereq:". In case of git-core there
are no such scripts (at least for now), so "Requires:" should be
used - then the package manager will be free to install packages
in any order as long as all dependencies will be satisfied in
the end.
> I would appreciate somebody to sanity check the list of
> dependencies. The dependency list Debian side has is more
> up-to-date and I am reasonably sure it is accurate. It lists
> patch, diff, and rcs (for the "merge" command) as the
> essential dependency (aside from the shared libraries like
> libc), and libmail-sendmail-perl, rsync, curl, ssh, and
> libemail-valid-perl as the recommended dependency. I do not
> even know if RPM has the notion of such multi-tier
> dependencies, but the latter list is meant to mean "you could
> live without these, but to exercise this package fully you may
> want them" (in our case of git-core, you could live without
> the networking if you do not do multi-user, multi-repository).
RPM does not have "Suggests" and "Recommends" like dpkg - all
RPM dependencies are strict. Because of this limitation, a
single RPM package is often split into several binary
subpackages.
> If RPM spec file has a way to say something like that, I would
> like to see these packages (probably their names are different
> between Debian and RPM) listed on the recommended dependency
> list; otherwise I would want to see them added to the main
> "Prereq:" list.
Not only the names of packages are different between Debian and
RPM - the names of similar RPM packages are different between
different RPM-based distributions. :(
E.g., in ALT Linux distributions /usr/bin/ssh is contained in
the openssh-clients package; SuSE 9.3 seems to have it in the
package named "openssh". There are lots of such differences.
Most modern RPM-based distributions have some mechanism to find
dependencies automatically (e.g., by scanning all Perl scripts
in the package for "use" statements). But these mechanisms are
incompatible between different distributions too.
Different distributions also have different RPM packaging
conventions, different RPM macros, etc etc...
So the best thing you can really do is to provide an RPM package
for some distribution you choose, which would then be used as a
basis for packages on other distributions.
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Request for help from binary packaging people.
From: Junio C Hamano @ 2005-08-08 17:38 UTC (permalink / raw)
To: git
In-Reply-To: <7vacjsdcbj.fsf@assigned-by-dhcp.cox.net>
I need a bit more help from binary packaging people.
I have not heard from Darwin or BSD people for some time. Is
your portfile up to date? Do you have updates you want me to
include? Have we introduced non-Linux non-GNU incompatibilities
lately that you want to see fixed and/or worked around?
For RPM, from my lack of RPM expertise (and RPM capable
environment until recently), I have not updated the "Prereq:"
field in git-core.spec.in at all. I would appreciate somebody
to sanity check the list of dependencies. The dependency list
Debian side has is more up-to-date and I am reasonably sure it
is accurate. It lists patch, diff, and rcs (for the "merge"
command) as the essential dependency (aside from the shared
libraries like libc), and libmail-sendmail-perl, rsync, curl,
ssh, and libemail-valid-perl as the recommended dependency. I
do not even know if RPM has the notion of such multi-tier
dependencies, but the latter list is meant to mean "you could
live without these, but to exercise this package fully you may
want them" (in our case of git-core, you could live without the
networking if you do not do multi-user, multi-repository). If
RPM spec file has a way to say something like that, I would like
to see these packages (probably their names are different
between Debian and RPM) listed on the recommended dependency
list; otherwise I would want to see them added to the main
"Prereq:" list.
For Debian, we recommend lib*-*-perl packages. Do we need to
recommend perl itself as well, or is it the case that things
that are covered with the automatic dependency chain need not be
listed? Earlier I said that the Debian side is reasonably
accurate to the best of my knowledge, but I would appreciate it
if somebody ran lintian on it.
Pretty please?
^ permalink raw reply
* Re: [PATCH] Teach git push .git/branches shorthand
From: Josef Weidendorfer @ 2005-08-08 16:22 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0508081234300.32668@wgmdd8.biozentrum.uni-wuerzburg.de>
On Monday 08 August 2005 12:36, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 8 Aug 2005, Josef Weidendorfer wrote:
> > Your example defaults to the master head.
>
> My point being that I still can say
>
> git pull x some_non_default_head
>
> with a file "x" in .git/branches.
Is this currently possible?
My understanding of .git/branches was that Cogito uses this as mapping of
remote branches/heads to local branches/refs, and not to store shortcuts for
remote git repositories.
IMHO, the above usage is a kind of "type mismatch", as the "x" already
contains the branch.
But perhaps for git it is enough to only have a directory of shortcuts for
remote repositories, to be found in .git/remotes?
And cogito can use its own subdirectory for remote/local head mappings. This
mapping even could use the shortcuts from .git/remotes.
> Anyway, I don't care much either way, if
> it be "remotes/" or "remoterefs/" or
> "magic_mapping_for_remote_repositories/" or even "repositories/".
Me either.
Josef
>
> Ciao,
> Dscho
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Teach git push .git/branches shorthand
From: Johannes Schindelin @ 2005-08-08 10:36 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200508081225.59949.Josef.Weidendorfer@gmx.de>
Hi,
On Mon, 8 Aug 2005, Josef Weidendorfer wrote:
> Your example defaults to the master head.
My point being that I still can say
git pull x some_non_default_head
with a file "x" in .git/branches. Anyway, I don't care much either way, if
it be "remotes/" or "remoterefs/" or
"magic_mapping_for_remote_repositories/" or even "repositories/".
Ciao,
Dscho
^ permalink raw reply
* Re: use of temporary refs in resolve
From: Catalin Marinas @ 2005-08-08 10:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vfytkdcgm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Catalin Marinas <catalin.marinas@gmail.com> writes:
>> Is FETCH_HEAD going to be preserved by the git-fetch-script operation?
>> It should be, unless, git-pull-script removes it or it is changed to
>> do the fetch as well.
>
> I am not quite sure what is being asked (especially "operation";
> I take it you meant "surgery" or "butchering"), so my answer may
> be missing the point.
OK, I wasn't that clear. Currently git-fetch-script stores the fetched
head in the FETCH_HEAD file and git-pull-script uses this file to do
the merging (by passing its content to git-resolve-script). Anyway, I
can easily change StGIT to only use git-pull-script directly, without
the intermediate fetch.
> I would like to update fetch to deal with multiple references,
> and if the user tells it to fetch N references, the FETCH_HEAD
> file would contain N lines, one line for each SHA1 object name.
> Initially I will not allow pull to take more than one reference
> because I will need to make resolve capable of resolving more
> than two parents (i.e. octopus merge) before that happens. But
> once that is done, then pull will accept N references and call
> fetch with these N references, then fetch leaves N lines in
> FETCH_HEAD, and those N SHA1 object names along with the current
> head would be given to resolve to create an (N+1)-head king
> ghidorah. I do not know how well this would go, but at least
> that is the current plan.
It might be hard to deal with conflicts resulted from merging N > 2
heads at the same time. I suspect it would call 'merge' (diff3) for
every new head but it might not be that obvious which head merging
failed (it depends on how you implement it). A way of continuing the
merge for the rest of the fetched heads after a failure needs to be
available.
--
Catalin
^ permalink raw reply
* Re: [PATCH] Teach git push .git/branches shorthand
From: Josef Weidendorfer @ 2005-08-08 10:25 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0508081154190.32406@wgmdd8.biozentrum.uni-wuerzburg.de>
On Monday 08 August 2005 11:55, Johannes Schindelin wrote:
> Hi,
>
> On Mon, 8 Aug 2005, Josef Weidendorfer wrote:
> > IMHO, $GIT_DIR/branches/ is really confusing.
> > Hmmm... in $GIT_DIR/branches/ there are named references to remote
> > (named) references.
>
> Not necessarily. The following is perfectly valid:
>
> echo "rsync://rsync.kernel.org/pub/scm/git/git.git > .git/branches/x
>
> It does not contain a named reference, just a host.
Not really.
Your example defaults to the master head. It is perfectly valid (at least
cogito usage), to have the reference appended as an anchor:
echo "rsync://rsync.kernel.org/pub/scm/git/git.git#pu" > .git/branches/pu
For lightweight remote tag, even a SHA1 as anchor should be possible.
Josef
> Ciao,
> Dscho
>
> -
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH] Teach git push .git/branches shorthand
From: Johannes Schindelin @ 2005-08-08 9:55 UTC (permalink / raw)
To: Josef Weidendorfer; +Cc: git
In-Reply-To: <200508081141.23242.Josef.Weidendorfer@gmx.de>
Hi,
On Mon, 8 Aug 2005, Josef Weidendorfer wrote:
> IMHO, $GIT_DIR/branches/ is really confusing.
> Hmmm... in $GIT_DIR/branches/ there are named references to remote (named)
> references.
Not necessarily. The following is perfectly valid:
echo "rsync://rsync.kernel.org/pub/scm/git/git.git > .git/branches/x
It does not contain a named reference, just a host.
Ciao,
Dscho
^ permalink raw reply
* [PATCH] Make curl fail on server error
From: Catalin Marinas @ 2005-08-08 9:53 UTC (permalink / raw)
To: git
Some http servers return an HTML error page and git reads it as normal
data. Adding -f option makes curl fail silently.
Signed-off-by: Catalin Marinas <catalin.marinas@gmail.com>
---
git-clone-dumb-http | 2 +-
git-fetch-script | 2 +-
git-ls-remote-script | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/git-clone-dumb-http b/git-clone-dumb-http
--- a/git-clone-dumb-http
+++ b/git-clone-dumb-http
@@ -14,7 +14,7 @@ if [ -n "$GIT_SSL_NO_VERIFY" ]; then
fi
http_fetch () {
# $1 = Remote, $2 = Local
- curl -ns $curl_extra_args "$1" >"$2"
+ curl -nsf $curl_extra_args "$1" >"$2"
}
cd "$D" &&
diff --git a/git-fetch-script b/git-fetch-script
--- a/git-fetch-script
+++ b/git-fetch-script
@@ -15,7 +15,7 @@ http://* | https://*)
fi
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]' &&
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40" &&
- head=$(curl -ns $curl_extra_args "$merge_repo/$merge_head") &&
+ head=$(curl -nsf $curl_extra_args "$merge_repo/$merge_head") &&
expr "$head" : "$_x40\$" >/dev/null || {
echo >&2 "Failed to fetch $merge_head from $merge_repo"
exit 1
diff --git a/git-ls-remote-script b/git-ls-remote-script
--- a/git-ls-remote-script
+++ b/git-ls-remote-script
@@ -46,7 +46,7 @@ http://* | https://* )
if [ -n "$GIT_SSL_NO_VERIFY" ]; then
curl_extra_args="-k"
fi
- curl -ns $curl_extra_args "$peek_repo/info/refs" || exit 1
+ curl -nsf $curl_extra_args "$peek_repo/info/refs" || exit 1
;;
rsync://* )
^ permalink raw reply
* Re: [PATCH] Teach git push .git/branches shorthand
From: Josef Weidendorfer @ 2005-08-08 9:41 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.63.0508081106580.26210@wgmdd8.biozentrum.uni-wuerzburg.de>
On Monday 08 August 2005 11:10, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 7 Aug 2005, Junio C Hamano wrote:
> > I hear a lot of people mention $GIT_DIR/branches/ is confusing.
> > Maybe we should rename it to $GIT_DIR/remote/ directory?
>
> I'd prefer $GIT_DIR/remotes/.
IMHO, $GIT_DIR/branches/ is really confusing.
Hmmm... in $GIT_DIR/branches/ there are named references to remote (named)
references.
Perhaps we should call it "remoterefs/" instead?
Josef
^ permalink raw reply
* [PATCH] add *--no-merges* flag to suppress display of merge commits
From: Johannes Schindelin @ 2005-08-08 9:37 UTC (permalink / raw)
To: git
As requested by Junio (who suggested --single-parents-only, but this
could forget a no-parent root).
Also, adds a few missing options to the usage string.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
rev-list.c | 12 +++++++++++-
1 files changed, 11 insertions(+), 1 deletions(-)
4c24c4de403dcb658622590f6f6ef35232bbe709
diff --git a/rev-list.c b/rev-list.c
--- a/rev-list.c
+++ b/rev-list.c
@@ -15,12 +15,15 @@ static const char rev_list_usage[] =
" --max-count=nr\n"
" --max-age=epoch\n"
" --min-age=epoch\n"
+ " --parents\n"
" --bisect\n"
" --objects\n"
" --unpacked\n"
" --header\n"
" --pretty\n"
- " --merge-order [ --show-breaks ]";
+ " --no-merges\n"
+ " --merge-order [ --show-breaks ]\n"
+ " --topo-order";
static int unpacked = 0;
static int bisect_list = 0;
@@ -39,6 +42,7 @@ static int merge_order = 0;
static int show_breaks = 0;
static int stop_traversal = 0;
static int topo_order = 0;
+static int no_merges = 0;
static void show_commit(struct commit *commit)
{
@@ -82,6 +86,8 @@ static int filter_commit(struct commit *
}
if (max_count != -1 && !max_count--)
return STOP;
+ if (no_merges && (commit->parents && commit->parents->next))
+ return CONTINUE;
return DO;
}
@@ -498,6 +504,10 @@ int main(int argc, char **argv)
verbose_header = 1;
hdr_termination = '\n';
prefix = "commit ";
+ continue;
+ }
+ if (!strncmp(arg, "--no-merges", 11)) {
+ no_merges = 1;
continue;
}
if (!strcmp(arg, "--parents")) {
^ permalink raw reply
* Re: [PATCH] Stash away the original head in ORIG_HEAD when resetting.
From: Johannes Schindelin @ 2005-08-08 9:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, torvalds
In-Reply-To: <Pine.LNX.4.63.0508081111020.26210@wgmdd8.biozentrum.uni-wuerzburg.de>
Hi,
On Mon, 8 Aug 2005, Johannes Schindelin wrote:
> Hi,
>
> On Sun, 7 Aug 2005, Junio C Hamano wrote:
>
> > $ git commit -m ORIG_HEAD
>
> Since there are not many users of git-commit's *-m* flag right now: Is it
> necessary to confuse CVS people, who expect to be able to write
>
> git commit -m "I did this and that"
>
> I do not want to be too intrusive, but I think up to now there is just the
> mailbox tools which use this feature, and users of git-reset. Thoughts?
Sorry, forgot -rebase and -cherry.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Stash away the original head in ORIG_HEAD when resetting.
From: Johannes Schindelin @ 2005-08-08 9:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, torvalds
In-Reply-To: <7vy87dgdxb.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 7 Aug 2005, Junio C Hamano wrote:
> $ git commit -m ORIG_HEAD
Since there are not many users of git-commit's *-m* flag right now: Is it
necessary to confuse CVS people, who expect to be able to write
git commit -m "I did this and that"
I do not want to be too intrusive, but I think up to now there is just the
mailbox tools which use this feature, and users of git-reset. Thoughts?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Teach git push .git/branches shorthand
From: Johannes Schindelin @ 2005-08-08 9:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7viryhgdo5.fsf@assigned-by-dhcp.cox.net>
Hi,
On Sun, 7 Aug 2005, Junio C Hamano wrote:
> I hear a lot of people mention $GIT_DIR/branches/ is confusing.
> Maybe we should rename it to $GIT_DIR/remote/ directory?
I'd prefer $GIT_DIR/remotes/. And I propose another extension: Since the
files stored therein right now contain only one <remote> string, it should
be possible to add the default head(s) to the file.
Ciao,
Dscho
^ permalink raw reply
* GIT 0.99.4 preview: current status
From: Junio C Hamano @ 2005-08-08 9:09 UTC (permalink / raw)
To: git
In-Reply-To: <7vr7d6z3pn.fsf@assigned-by-dhcp.cox.net>
Things are looking almost ready for a new release. The list at
the end of this message shows what went into the release
candidate branch since 0.99.3: Dan's commit walker updates to
deal with a packed repository, Johannes fixed quite a lot of
problems in the documentation, I did reference-renaming push, a
couple of usability improvements from Linus, gitk updates from
Paul, and Ryan added an bulk e-mailer. With help from Kalle,
Horst and Chris Wright, binary packaging looks in a better shape
now. I'll let this simmer for a couple more days, and plan to
merge them back to the master branch on Wednesday and tag it as
v0.99.4. Some of the patches I will receive before Wednesday
from the list, and some of what I already have in the proposed
update branch, may graduate to the master branch before that
happens.
Earlier, I posted my itchlist. I would of course appreciate if
somebody scratches them, but at the same time would appreciate
people to voice their own itches. My personal 0.99.5 itches are
to enhance fetch to deal with multiple references and have
local-pull to deal with a packed repository. Dan's help would be
greatly appreciated on the latter one.
Oh, another itch I did not list in the previous message. Is
anybody interested in doing an Emacs VC back-end for GIT?
BTW, I used "git log v0.99.3..rc | git shortlog" to prepare the
attached list, but ended up hand-removing many "Merge with blah"
entries. It may not be a bad idea to have an option to filter
out the merge entries at "git log" time. Adding
'--single-parent-only' flag to git-rev-list would be one way of
doing it. Suggestions?
------------
Alecs King:
Fix sparse warnings
barkalow@iabervon.org:
Object library enhancements
Parallelize the pull algorithm
Parallelize pulling by ssh
Holger Eitzenberger:
git: add git_mkstemp()
git: use git_mkstemp() instead of mkstemp() for diff generation.
Horst von Brand:
RPM spec updates.
Johannes Schindelin:
git-commit-script fix for degenerated merge
Assorted documentation patches
Junio C Hamano:
Clean t/trash upon "make clean" as well.
Make send-pack --all and explicit ref mutually exclusive.
receive-pack hooks updates.
Make sure leading directories exist when pushing refs.
git-send-email-script: minimum whitespace cleanup.
send-pack: handle partial pushes correctly.
Install sample hooks
Renaming push.
git-send-pack: documentation
Retire check-files.
Retire git-check-files documentation too.
git-bisect termination condition fix.
git-init-db: brown paper bag bugfix.
Fix send-pack for non-commitish tags.
Update get_sha1() to grok extended format.
Teach rev-list since..til notation.
daemon.c: squelch error message from EINTR
git-applymbox: allow retrying after fixing up.
Fix refname termination.
Fix ref_newer() in send-pack.
send-pack: allow the same source to be pushed more than once.
send-pack: allow generic sha1 expression on the source side.
gitk proposed fix: handle more than one SHA1 links.
Redo the templates generation and installation.
GIT 0.99.4 (release candidate)
Fix RPM build that omitted templates and tools.
Fix build rules for debian package.
(revert local fix)
Update Maintainer field of debian/control
Kalle Valo:
Fix debian doc-base
Linus Torvalds:
Make git-sh-setup-script do what it was supposed to do
Extend "git reset" to take a reset point
gitk "parent information" in commit window
Nicolas Pitre:
list shortlog items in commit order
Paul Mackerras:
Compress the graph horizontally if it gets too wide.
Add forward and back buttons and make SHA1 IDs clickable links.
Change cursor to a hand cursor when over a SHA1 ID link.
Use lf translation rather than binary when reading commit data.
Better graph line details display and expand history coverage.
Petr Baudis:
Fix git-merge-cache -q
Ryan Anderson:
Add git-send-email-script - tool to send emails from git-format-patch-script
Add documentation for git-send-email-script
Add new dependencies caused by git-send-email-script to debian/control
Convert from using quoted-printable to just 8bit encoding on all emails.
Cleanup initial comments, add copyright notices.
Add "--chain-reply-to" to git-send-email-script, to control whether or not the
git-send-email-script: Reformat readline interface and generate a better message-id.
Make the SMTP server used by git-sendm-email-script configurable on the command line with "--smtp-server"
git-send-email-script - fix 2 small bugs that snuck through an untested bout of editing.
git-send-email-script - Fix loops that limit emails to unique values to be pedantically correct.
Doc: update git-send-email-script documentation.
Sergey Vlasov:
Plug memory leaks in git-unpack-objects
^ permalink raw reply
* Re: use of temporary refs in resolve
From: Junio C Hamano @ 2005-08-08 9:06 UTC (permalink / raw)
To: Catalin Marinas; +Cc: Linus Torvalds, git
In-Reply-To: <tnxk6iwx161.fsf@arm.com>
Catalin Marinas <catalin.marinas@gmail.com> writes:
> gitk ORIG_HEAD..FETCH_HEAD
Yeah, Linus immediately corrected me when I said ORIG_HEAD
seemed useless.
> Is FETCH_HEAD going to be preserved by the git-fetch-script operation?
> It should be, unless, git-pull-script removes it or it is changed to
> do the fetch as well.
I am not quite sure what is being asked (especially "operation";
I take it you meant "surgery" or "butchering"), so my answer may
be missing the point.
I would like to update fetch to deal with multiple references,
and if the user tells it to fetch N references, the FETCH_HEAD
file would contain N lines, one line for each SHA1 object name.
Initially I will not allow pull to take more than one reference
because I will need to make resolve capable of resolving more
than two parents (i.e. octopus merge) before that happens. But
once that is done, then pull will accept N references and call
fetch with these N references, then fetch leaves N lines in
FETCH_HEAD, and those N SHA1 object names along with the current
head would be given to resolve to create an (N+1)-head king
ghidorah. I do not know how well this would go, but at least
that is the current plan.
^ permalink raw reply
* Re: use of temporary refs in resolve
From: Catalin Marinas @ 2005-08-08 8:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7v3bplwmzg.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Here is my understanding of various "temporary heads" left
> directly underneath $GIT_DIR:
>
> HEAD : updated only after successful auto merge.
>
> ORIG_HEAD : records the head value before resolve started.
> if automerge fails, this is the same as HEAD,
> but after successful automerge, this can be used
> to see what the previous head was. This is the
> first parent of the resulting commit.
>
> MERGE_HEAD: present if auto merge is unsuccessful and
> records the other head being merged.
>
> LAST_MERGE: present if merge is unsuccessful or impossible and
> records the other head being merged.
Is FETCH_HEAD going to be preserved by the git-fetch-script operation?
It should be, unless, git-pull-script removes it or it is changed to
do the fetch as well.
In a repository managed with StGIT (i.e. updated with 'stg pull'), the
base of the stack is always the same with FETCH_HEAD and StGIT uses
this file. I also find it quite useful for:
gitk ORIG_HEAD..FETCH_HEAD
to only see the remote commits since the local StGIT patches are
always seen as commits on top of the FETCH_HEAD. It's also useful for
people using 'git rebase'.
--
Catalin
^ 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