* Re: [PATCH] format-patch: use cwd as default output directory
From: Nguyen Thai Ngoc Duy @ 2006-09-28 10:25 UTC (permalink / raw)
To: git, Junio C Hamano
In-Reply-To: <20060922111201.GA10124@moooo.ath.cx>
This patch works great. I assume you forgot it?
On 9/22/06, Matthias Lederhofer <matled@gmx.net> wrote:
> ---
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> wrote:
> > git format-patch in subdir generates files in topdir instead of
> > current dir as documented in its man page
> Here is a patch for this.
> ---
> builtin-log.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/builtin-log.c b/builtin-log.c
> index fbc58bb..130b53a 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -270,6 +270,8 @@ int cmd_format_patch(int argc, const cha
>
> rev.extra_headers = extra_headers;
>
> + output_directory = prefix;
> +
> /*
> * Parse the arguments before setup_revisions(), or something
> * like "git fmt-patch -o a123 HEAD^.." may fail; a123 is
> --
> 1.4.2.1.ge767
>
>
--
Duy
^ permalink raw reply
* [PATCH/RFC] daemon: default to 256 for HOST_NAME_MAX if it is not defined
From: Johannes Schindelin @ 2006-09-28 10:00 UTC (permalink / raw)
To: git, junkio
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
---
... or should we make it wider available, by putting it into
cache.h?
daemon.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/daemon.c b/daemon.c
index 5335d21..fc3951c 100644
--- a/daemon.c
+++ b/daemon.c
@@ -15,6 +15,10 @@ #include "cache.h"
#include "exec_cmd.h"
#include "interpolate.h"
+#ifndef HOST_NAME_MAX
+#define HOST_NAME_MAX 256
+#endif
+
static int log_syslog;
static int verbose;
static int reuseaddr;
--
1.4.2.1.g430572-dirty
^ permalink raw reply related
* Re: What's in git.git
From: Petr Baudis @ 2006-09-28 9:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodt0zbhc.fsf@assigned-by-dhcp.cox.net>
Dear diary, on Thu, Sep 28, 2006 at 09:39:11AM CEST, I got a letter
where Junio C Hamano <junkio@cox.net> said that...
> -
BTW, what's the difference between '-' and '+'?
> + Git.pm lost Git.xs; its remnant still remains, though.
> Notably, we still compile x86_64 with -fPIC, and the top
> level Makefile has {BASIC,ALL}_{CFLAGS,LDFLAGS} distinction
> and INSTALL talks about perl/blib/arch/auto. I am torn
> between removing these and keeping them; on one hand, they
> are not needed and makes new developers wonder what the
> distinction between BASIC and ALL are. On the other hand,
> we may eventually would want to reintroduce Git.xs in the
> future and keeping them might help us. But on the third
> hand ;-), we can always resurrect it from the repository and
> that is the point of using git to keep track of the project,
> so removing them might not be such a big deal. I'd like to
> decide between this two and push it out to 'master' before
> doing the -rc1.
FWIW, I'd say kill it all (perhaps except BASIC_*, I don't know about
that one) - we indeed can easily resurrect this, and that was the
presumption with which I've killed the rest of Git.xs. There's no point
in keeping legacy cruft around when we can take it back from the
history.
Perhaps we could throw a note to perl/Makefile saying
# If you are thinking about adding Git.xs support, please note
# that we have already been there before - see the #next branch
# history for more-or-less working one already added, and also
# the reason why it was removed for now.
so that noone wastes their time.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
#!/bin/perl -sp0777i<X+d*lMLa^*lN%0]dsXx++lMlN/dsM0<j]dsj
$/=unpack('H*',$_);$_=`echo 16dio\U$k"SK$/SM$n\EsN0p[lN*1
lK[d2%Sa2/d0$^Ixp"|dc`;s/\W//g;$_=pack('H*',/((..)*)$/)
^ permalink raw reply
* Re: [PATCH 3/3] diff --stat: sometimes use non-linear scaling.
From: Junio C Hamano @ 2006-09-28 9:20 UTC (permalink / raw)
To: Martin Waitz; +Cc: git
In-Reply-To: <20060928081757.GF8056@admingilde.org>
Martin Waitz <tali@admingilde.org> writes:
>> It should at least never be superlinear, I believe.
>
> So if we want to keep the logarithmic scale we can do some maths:
>...
> But only I have not succeeded in solving these equations, I always stop
> at the last invariant :-(
There is another constraint you did not mention. Here is the
output from my another failed experiment:
.gitignore | 1 -
Documentation/git-tar-tree.txt | 3 +++
Documentation/git-upload-tar.txt | 39 -----------------------------
Documentation/git.txt | 4 ----
Makefile | 1 -
builtin-tar-tree.c | 130 +++++++++++++++-----------------------
builtin-upload-tar.c | 74 ----------------------------------
git.c | 1 -
8 files changed, 53 insertions(+), 200 deletions(-)
The deletion from Documentation/git-upload-tar.txt looks much
larger than addition to builtin-tar-tree.c in the above, but
there are 50 lines added to builtin-tar-tree.c (which is why
this experiment is a failure).
Because we are dealing with non-linear scaling, the total of
scaled adds and scaled deletes does not equal to scaled total.
We can deal with this in two ways. Scale the total and
distribute it, or scale adds and deletes individually and make
sure the sum of scaled adds and deletes never exceed the width.
Obviously the former is easier to implement but it was _wrong_.
The fitting algorithm in the posted patch scales the total to
fit the alloted width and then distributes the result to adds
and deletes.
^ permalink raw reply
* Re: [PATCH 3/3] diff --stat: sometimes use non-linear scaling.
From: Martin Waitz @ 2006-09-28 8:17 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, git, Jan Engelhardt, Adrian Bunk
In-Reply-To: <Pine.LNX.4.64.0609270810470.3952@g5.osdl.org>
[-- Attachment #1: Type: text/plain, Size: 890 bytes --]
hoi :)
On Wed, Sep 27, 2006 at 08:12:49AM -0700, Linus Torvalds wrote:
> No _way_ is it correct to show more than three characters if there were
> three lines of changes.
>
> I think "nonlinear" is fine, but this is something that is "superlinear"
> in small changes, and then sublinear in bigger ones (and then apparently
> totally wrong for one-line changes).
>
> It should at least never be superlinear, I believe.
So if we want to keep the logarithmic scale we can do some maths:
Assume we use a formula ala
length = a log(change + b) + c
with three invariants a, b, and c.
We want to scale linearly at first, but want to reach width at
max_change:
0 = a log(b) + c
1 = a log(b + 1) + c
width = a log(max_change + b) + c
But only I have not succeeded in solving these equations, I always stop
at the last invariant :-(
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* What's in git.git
From: Junio C Hamano @ 2006-09-28 7:39 UTC (permalink / raw)
To: git
* The 'master' branch has these since the last announcement.
There are some small bits I'd like to merge still brewing in
'next' before the -rc1, but please expect a real 1.4.3-rc1
soon.
- git-daemon virtual hosting.
- With git-branch, deleting branch a/b and then creating
branch a did not work. Fixed.
- Updated git-archive documentation.
- git-repack can be run from project subdirectory.
- git-log and friends can limit output with --author,
--committer and --grep options.
- Minor git-runstatus by Johannes Schindelin.
- git-diff --color highlights whitespace errors.
- git-apply --whitespace={warn,error,strip} notices whitespace
errors in indentation.
- git-tar is now a thin wrapper to "git-archive --format=tar";
"git-tar --remote" talks with "git-upload-archive" on the
other end.
- Python-based merge-recursive is deprecated. It is still
available as "recursive-old" strategy, but "recursive"
strategy now uses the C implementation. The earlier synonym
"recur" still available.
- "git-grep --fixed-strings" with boolean expression did not
work; fixed.
- git-pack-objects generates packfile version 3 that can
express copying of larger block from delta base.
- Many internal routines that deal with using packfiles have
been cleaned up.
- Many updates to gitweb by the usual suspects.
- Default repository to fetch from, and the remote branches to
merge, can be specified by per-branch configuration items.
- git-svnimport gets the full author name from Signed-off-by:
line when available.
- git-svn got a few updates.
- git-checkout while not on a branch (e.g. git-init-db
followed by git-fetch to create branches from remotes) did
not work; fixed.
- Even when core.filemode is set to false (i.e. the filesystem
does not have reliable mode bits), git-update-index still
registered new paths with random mode bits obtained from the
filesystem. Fixed.
* The 'next' branch, in addition, has these. I think the ones
marked with + could be 1.4.3-rc1 material:
- Triggered by the packed-ref series from Linus, we have
accumulated a few topics, but I decided to consolidate them
into one topic branch. It contains:
- resolve_ref() API cleanup;
- for_each_ref() API cleanup;
- git-show-ref helper;
- git-for-each-ref helper;
- ref locking fix-up to tighten races for ref creation and
deletion cases;
- packed refs and pruning of refs;
- git-receive-pack now uses lock_ref_sha1() API and updates
ref-log like other programs;
The series still has a few problems I listed in my earlier
message:
Subject: What will happen to git.git in the near future
Message-ID: <7v7iztbldm.fsf@assigned-by-dhcp.cox.net>
I do not plan to include this in the next release; hopefully
soon after the next release we can have it in 'master'.
- cvsimport was updated to use for-each ref. This obviously
depends on the above.
+ Git.pm lost Git.xs; its remnant still remains, though.
Notably, we still compile x86_64 with -fPIC, and the top
level Makefile has {BASIC,ALL}_{CFLAGS,LDFLAGS} distinction
and INSTALL talks about perl/blib/arch/auto. I am torn
between removing these and keeping them; on one hand, they
are not needed and makes new developers wonder what the
distinction between BASIC and ALL are. On the other hand,
we may eventually would want to reintroduce Git.xs in the
future and keeping them might help us. But on the third
hand ;-), we can always resurrect it from the repository and
that is the point of using git to keep track of the project,
so removing them might not be such a big deal. I'd like to
decide between this two and push it out to 'master' before
doing the -rc1.
+ More gitweb updates from usual suspects.
+ "git-diff --stat" can now be told to use custom output width
with --stat-width=N option instead of the default 80.
+ "git-diff --stat --color" shows the graph in colors.
- "git-grep --all-match" limits output to files that have all
the top-level ORed expressions. I suck at documentation and
the description I added to the manual needs rewriting.
Help?
- git-log and friends learned the same --all-match flag. With
it:
git log --all-match --author=Linus --committer=Junio --grep=list
would show only changes written by Linus and committed by me
and talks about "list".
- updates to packfile format that allows delta base objects to
be expressed by offset in the stream, not by 20-byte object
name. Just completed and started cooking in 'next'.
- upload-pack: stop the other side when they have more roots than we do.
* The 'pu' branch, in addition, has these.
- change "git-diff" output for paths with embedded SP a bit
friendlier to "GNU patch". This is done by appending an
extra TAB after "--- a/file name" and "+++ b/file name"
lines. This needs to be done in two steps:
- prepare git-apply to take the new output format.
- update git-diff to produce such, after people's git-apply
has been updated.
Do people have objection to the output format change?
Otherwise I'd like to merge the first stage to 'next', and
perhaps soon after 1.4.3 to 'master'.
- two git-cvsexportcommit improvements, which unfortunately
fails with certain combination of patch/perl/cvs; breakage
under investigation by the author.
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Martin Waitz @ 2006-09-28 7:37 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Shawn Pearce, Daniel Barkalow, git
In-Reply-To: <451AADC3.40201@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1918 bytes --]
hoi :)
On Wed, Sep 27, 2006 at 09:58:43AM -0700, A Large Angry SCM wrote:
> This means that modules are not separate, stand alone projects but,
> rather, just a sub part of your bigger project. Very useful and
> applicable in some situations but other situations want/need separate,
> stand alone subprojects.
you can do everything with the submodule which would be possible with
a normal GIT repository. And you can always clone it into an directory
which is not controlled by a parent project.
I really think that this is an very important property of a submodule.
> >By storing the complete refs/heads directory for each submodule instead
> >of only one head, it is possible to track multiple branches of a
> >subproject. I'm don't know yet how this works out in praktice but I
> >think that it can be nice to be able to atomically commit to several
> >branches of one submodule (perhaps one branch per customer, per
> >hardware platform, whatever).
>
> It's not immediately clear to me if tracking several long term
> (globally) visible branches in a checkout sub module is generally useful
> or only useful in special situations. I need to think about this...
One use-case which may be important here:
The submodule has two different branches which got forked and are not
intended to be merged again. At some point in time the parent project
wants to switch from one branch of the submodule to another branch.
If a user still has modifications in the old branch and wants to
update the parent project then it is important to know if the local
modifications and those coming from the parent have to be merged or
should stay in different branches.
If the parent is switching branches there should only be some warning
if the user still has modifications in the old branch, giving him the
chance to port the modifications to the other branch.
--
Martin Waitz
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Why gitweb commitdiff NO diff output ?
From: Dongsheng Song @ 2006-09-28 7:32 UTC (permalink / raw)
To: git
My git repository import from subversion, and the latest files has
correct mime-type property, but gitweb commitdiff NO diff output !
file:82dc767b3f1425435fa6d8fa7511718d3f614172 ->
file:4c7269ed65bf8691c46541497fbecc706f7d012f
file:6817671d9af75b9adcc439d62f9047c7b2a9adb2 ->
file:575d40108f550ac5965bb6ea8b6792fa9cc10536
Thanks for some help,
Donogsheng
^ permalink raw reply
* gitweb commitdiff output error
From: Dongsheng Song @ 2006-09-28 7:20 UTC (permalink / raw)
To: git
Hi,
When the file enconding is not utf8, the gitweb commitdiff output
error for non-ascii characters.
Can I do iconv for commitdiff ?
Dongsheng
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: A Large Angry SCM @ 2006-09-28 5:02 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Shawn Pearce, Martin Waitz, Daniel Barkalow, git
In-Reply-To: <451B0F59.6070901@dawes.za.net>
Rogan Dawes wrote:
[...]
> Does it not make sense that a commit of the higher level project should
> include the contents of its subprojects at that particular moment in time?
>
> e.g. using the previous example of a kernel, apache, glibc, etc
>
> You may track the subprojects using whatever scm applies to THAT
> subproject. But when you want to record the state of the entire project,
> you want to include the state of the subprojects. So, your super-project
> commit would actually recurse down into the working directories of the
> subprojects and record the state/contents of each file that makes up
> each of the subprojects.
>
> So, if someone is tracking the overall project, and they do a pull of
> v1.1 (tag), they will see exactly what v1.1 looked like in your repo.
>
> What this makes me think is that it might be useful to have a mechanism
> for recalculating the tree-ish of a subdirectory and finding an
> associated commit, for the case where a subproject is also managed by git.
>
> i.e. given a super-project in this state, and knowing that this
> subproject is managed by git, which revision of the subproject are we
> talking about, and can we find a commit that matches this tree-ish?
> (assuming we have the history of the subproject available, of course)
Some development environments will require that all the (used) code is
imported into the local VCS of choice. But not all environments. For
some development environments, recording the version of the subproject
is sufficient. Assuming it's possible at some future time to get the
state associated with the version.
Also keep in mind, to effectively participate in a project, you will
likely need to use the VCS of the project. So importing everything into
another VCS (Git) will just cause _you_ more work.
^ permalink raw reply
* [PATCH 3/3] Uncomment test case: git branch c/d should barf if branch c exists.
From: Christian Couder @ 2006-09-28 5:02 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t3210-pack-refs.sh | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/t/t3210-pack-refs.sh b/t/t3210-pack-refs.sh
index 2cc03e6..193fe1f 100755
--- a/t/t3210-pack-refs.sh
+++ b/t/t3210-pack-refs.sh
@@ -37,12 +37,12 @@ test_expect_success \
git-show-ref b >result &&
diff expect result'
-# test_expect_failure \
-# 'git branch c/d should barf if branch c exists' \
-# 'git-branch c &&
-# git-pack-refs &&
-# rm .git/refs/heads/c &&
-# git-branch c/d'
+test_expect_failure \
+ 'git branch c/d should barf if branch c exists' \
+ 'git-branch c &&
+ git-pack-refs &&
+ rm .git/refs/heads/c &&
+ git-branch c/d'
test_expect_success \
'see if a branch still exists after git pack-refs --prune' \
--
1.4.2.1.g3bab
^ permalink raw reply related
* [PATCH 2/3] When creating branch c/d check that branch c does not already exists.
From: Christian Couder @ 2006-09-28 5:00 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
With packed refs, there may not be a ".git/refs/heads/c" file
when branch c exists. And currently in this case, there is no check
to prevent creation of branch c/d.
This should probably be rewritten in C and done after the ref lock
has been taken to make sure no race exists though.
This is mainly to make all test cases in "t3210-pack-refs.sh" work.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
git-branch.sh | 10 ++++++++++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/git-branch.sh b/git-branch.sh
index 4826c75..4a1e7d9 100755
--- a/git-branch.sh
+++ b/git-branch.sh
@@ -122,6 +122,16 @@ then
done
fi
+branchdir=$(dirname $branchname)
+while test "$branchdir" != "."
+do
+ if git-show-ref --verify --quiet -- "refs/heads/$branchdir"
+ then
+ die "$branchdir already exists."
+ fi
+ branchdir=$(dirname $branchdir)
+done
+
if git-show-ref --verify --quiet -- "refs/heads/$branchname"
then
if test '' = "$force"
--
1.4.2.1.g3bab
^ permalink raw reply related
* [PATCH 1/3] Add pack-refs and show-ref test cases.
From: Christian Couder @ 2006-09-28 4:58 UTC (permalink / raw)
To: Junio Hamano; +Cc: git
Some of these test cases are from Junio.
One test case is commented out because it doesn't work right now.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
---
t/t3210-pack-refs.sh | 70 ++++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 70 insertions(+), 0 deletions(-)
diff --git a/t/t3210-pack-refs.sh b/t/t3210-pack-refs.sh
new file mode 100755
index 0000000..2cc03e6
--- /dev/null
+++ b/t/t3210-pack-refs.sh
@@ -0,0 +1,70 @@
+#!/bin/sh
+#
+# Copyright (c) 2005 Amos Waterland
+# Copyright (c) 2006 Christian Couder
+#
+
+test_description='git pack-refs should not change the branch semantic
+
+This test runs git pack-refs and git show-ref and checks that the branch
+semantic is still the same.
+'
+. ./test-lib.sh
+
+test_expect_success \
+ 'prepare a trivial repository' \
+ 'echo Hello > A &&
+ git-update-index --add A &&
+ git-commit -m "Initial commit." &&
+ HEAD=$(git-rev-parse --verify HEAD)'
+
+SHA1=
+
+test_expect_success \
+ 'see if git show-ref works as expected' \
+ 'git-branch a &&
+ SHA1=$(< .git/refs/heads/a) &&
+ echo "$SHA1 refs/heads/a" >expect &&
+ git-show-ref a >result &&
+ diff expect result'
+
+test_expect_success \
+ 'see if a branch still exists when packed' \
+ 'git-branch b &&
+ git-pack-refs &&
+ rm .git/refs/heads/b &&
+ echo "$SHA1 refs/heads/b" >expect &&
+ git-show-ref b >result &&
+ diff expect result'
+
+# test_expect_failure \
+# 'git branch c/d should barf if branch c exists' \
+# 'git-branch c &&
+# git-pack-refs &&
+# rm .git/refs/heads/c &&
+# git-branch c/d'
+
+test_expect_success \
+ 'see if a branch still exists after git pack-refs --prune' \
+ 'git-branch e &&
+ git-pack-refs --prune &&
+ echo "$SHA1 refs/heads/e" >expect &&
+ git-show-ref e >result &&
+ diff expect result'
+
+test_expect_failure \
+ 'see if git pack-refs --prune remove ref files' \
+ 'git-branch f &&
+ git-pack-refs --prune &&
+ ls .git/refs/heads/f'
+
+test_expect_success \
+ 'git branch g should work when git branch g/h has been deleted' \
+ 'git-branch g/h &&
+ git-pack-refs --prune &&
+ git-branch -d g/h &&
+ git-branch g &&
+ git-pack-refs &&
+ git-branch -d g'
+
+test_done
--
1.4.2.1.g4f95-dirty
^ permalink raw reply related
* Re: Notes on Using Git with Subprojects
From: A Large Angry SCM @ 2006-09-28 4:48 UTC (permalink / raw)
To: Shawn Pearce; +Cc: Johannes Schindelin, Martin Waitz, Daniel Barkalow, git
In-Reply-To: <20060927233639.GE21839@spearce.org>
Shawn Pearce wrote:
[...]
> - Git Porcelain should help the user.
>
> Git operations should translate down through lower level projects
> when possible, and lower level project changes should push up
> when possible.
>
> E.g. git-fetch in a higher level repository should percolate
> down into the lower level repositories automatically. Ditto with
> git-checkout and probably git-push. git-commit in a lower level
> repository probably should update the specification file(s)
> in the higher level repository but not commit the higher level
> repository.
I think recursing through all subprojects for most Git commands is
actually the exception. Plus, porcelains aren't going to help much past
the first subproject that isn't Git managed.
[...]
> However an annoted tag probably should not be able to be created
> on the higher level project unless all lower-level subprojects
> are referenced by tags (or the equivilant) in their SCM. Which
> implies using a "stable tag" in CVS, a "/tags/foo@rev" in SVN,
> or an annotated tag in Git and updating the specification file(s)
> to reflect that.
I fail to see a reason for this restriction. Each project should be
managed separately. Also, how do you enforce the restriction on other VCSs?
^ permalink raw reply
* Re: [PATCH 2nd try] runstatus: do not recurse into subdirectories if not needed
From: Junio C Hamano @ 2006-09-28 4:40 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0609280240060.14200@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> This speeds up the case when you run git-status, having an untracked
> subdirectory containing huge amounts of files.
>
> Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
>
> ---
>
> On Thu, 28 Sep 2006, Johannes Schindelin wrote:
>
> Okay, so no more dir_is_empty(). Instead, read_directory_recursive()
> gets a flag. With this flag, "check_only", it exits as soon as it
> found valid entries, but does not add any. Way easier.
Yeah, the logic is a lot easier to follow.
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Shawn Pearce @ 2006-09-28 4:09 UTC (permalink / raw)
To: Jeff King; +Cc: A Large Angry SCM, Martin Waitz, Daniel Barkalow, git
In-Reply-To: <20060928040027.GA22489@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Wed, Sep 27, 2006 at 11:58:55PM -0400, Shawn Pearce wrote:
>
> > If you are fetching a set of commits from a repository you probably
> > should be fetching any tags that point at the commits you've fetched.
> > They tend to be few compared to the commits, they tend to be small,
> > and they tend to be important milestones in the tracked project.
> >
> > I think that's why the native Git protocol sends tags for any
> > commits that were also sent. :)
>
> Oh, that's clever. :)
>
> Do we do the right thing for non-git transports?
Yes, I think we do.
Only its not quite as clever as the HTTP/FTP commit walker first
needs to get a list of available refs (which includes tag and
tag^{}) and compares each obtained commit to the ^{} entries.
If there's a match it gets the tag.
And rsync being as dumb as it is should be fetching everything. :)
--
Shawn.
^ permalink raw reply
* Re: git and time
From: Junio C Hamano @ 2006-09-28 4:07 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609272252041.9349@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Wed, 27 Sep 2006, Junio C Hamano wrote:
>
>> .... He tends to batch, so he would have many such pulls and
>> patch applications in his private repository, perhaps over a few
>> hour, but the result will be pushed out to kernel.org with one
>> push operation. To show the "truthful" time, your gitweb would
>> give the timestamp of that push operation for hundreds of
>> commits pushed out during that operation.
>>
>> I do not personally think that would be useful at all. And I
>> happen to know how expensive to teach gitweb to produce such an
>> output, so I would not seriously suggest anybody to try it.
>
> I beg to differ. Such information might be really useful. I agree
> though that this is an expensive operation and gitweb might not be the
> best place for it at all.
>
> For example... some times I look at git-log output and finds about a
> certain bug fix that was apparently committed a month ago. And
> incidentally I recall having been bitten by that bug not really long
> ago, say last week. Although the bug fix was committed _somewhere_ last
> month, what I would really want to know is just when _i_ received that
> bug fix in my own repository to determine if it was before or after last
> week. So if it was before last week then I could conclude that the bug
> fix didn't actually fix my bug. Knowing that it has been committed last
> month is absolutely useless to me in this case.
I beg to agree ;-). Being able to inspect a particular commit
to find out when it hit the branch is probably useful. I do not
have much objection to have it on the commit page.
It is totally a separate matter to use that timestamp to order
the commits listed on the shortlog page, which Matthew seemed to
be after. I would say that _is_ wasteful and loses more
interesting information by listing all several dozen commits
Linus pushed out the last time with the same timestamps.
^ permalink raw reply
* Re: git and time
From: Junio C Hamano @ 2006-09-28 4:03 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0609272232040.9349@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> What I think you want and what you should talk about is that you're
> interested into the "local appearance time" for a given commit and not
> "local commit time". Using that terminology is probably much less
> confusing in the GIT world.
>
> To do so you'll need a GIT command that doesn'T exist yet. Let's call
> it git-local-arrival. It could be defined as follows:
>
> SYNOPSIS
>
> git-local-arrival <committish>
>
> DESCRIPTION
>
> The command displays the time when given commit appeared in the
> local repository.
This should be certainly doable, but local-arrival may not be
interesting if the repository has more than one branches. Maybe
git-local-arrival <committish> [<branch>]
which defaults to the current branch?
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Jeff King @ 2006-09-28 4:00 UTC (permalink / raw)
To: Shawn Pearce; +Cc: A Large Angry SCM, Martin Waitz, Daniel Barkalow, git
In-Reply-To: <20060928035855.GD22897@spearce.org>
On Wed, Sep 27, 2006 at 11:58:55PM -0400, Shawn Pearce wrote:
> If you are fetching a set of commits from a repository you probably
> should be fetching any tags that point at the commits you've fetched.
> They tend to be few compared to the commits, they tend to be small,
> and they tend to be important milestones in the tracked project.
>
> I think that's why the native Git protocol sends tags for any
> commits that were also sent. :)
Oh, that's clever. :)
Do we do the right thing for non-git transports?
-Peff
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Shawn Pearce @ 2006-09-28 3:58 UTC (permalink / raw)
To: Jeff King; +Cc: A Large Angry SCM, Martin Waitz, Daniel Barkalow, git
In-Reply-To: <20060928035225.GA22006@coredump.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Wed, Sep 27, 2006 at 08:47:34PM -0700, A Large Angry SCM wrote:
>
> > >A first step to this would be an argument to git-clone to allow cloning
> > >only a subset of refs.
> > Something like this?
> >
> > git-init-db
> > git-fetch <repository> <refspecs>
>
> Exactly, but I was suggesting something more user-friendly (e.g., it's
> nice to use git-clone because it creates the remotes file). I was going
> to hack up a quick change to git-clone, but I think some thought needs
> to be given to semantics, especially with respect to tags (should it
> imply no tags? Only tags which point to refs we're already fetching?).
If you are fetching a set of commits from a repository you probably
should be fetching any tags that point at the commits you've fetched.
They tend to be few compared to the commits, they tend to be small,
and they tend to be important milestones in the tracked project.
I think that's why the native Git protocol sends tags for any
commits that were also sent. :)
--
Shawn.
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Shawn Pearce @ 2006-09-28 3:52 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Jeff King, Martin Waitz, Daniel Barkalow, git
In-Reply-To: <451B45D6.1010006@gmail.com>
A Large Angry SCM <gitzilla@gmail.com> wrote:
> Jeff King wrote:
> [...]
> >One thing that I believe some people have requested for subprojects is
> >to avoid downloading files/history for subprojects you're not interested
> >in. I think this could be faciliated in this scheme by only cloning the
> >heads of the subprojects you're interested in (there would need to be
> >special machinery to handle this at the root level if we want to allow
> >making root commits without necessarily having all of the subprojects).
>
> In what I'm suggesting, commits are local to a project's working
> directory repository and are pushed somewhere else to be recorded long
> term. Since projects are stand alone, possibly with dependencies,
> working on a (sub)project without having other associated (sub)projects
> is accomplished by checking it out.
>
> >A first step to this would be an argument to git-clone to allow cloning
> >only a subset of refs.
>
> Something like this?
>
> git-init-db
> git-fetch <repository> <refspecs>
More like:
git-init-db
git-fetch --keep <repository> <refspecs>
but yes. :-)
--
Shawn.
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: Jeff King @ 2006-09-28 3:52 UTC (permalink / raw)
To: A Large Angry SCM; +Cc: Martin Waitz, Shawn Pearce, Daniel Barkalow, git
In-Reply-To: <451B45D6.1010006@gmail.com>
On Wed, Sep 27, 2006 at 08:47:34PM -0700, A Large Angry SCM wrote:
> >A first step to this would be an argument to git-clone to allow cloning
> >only a subset of refs.
> Something like this?
>
> git-init-db
> git-fetch <repository> <refspecs>
Exactly, but I was suggesting something more user-friendly (e.g., it's
nice to use git-clone because it creates the remotes file). I was going
to hack up a quick change to git-clone, but I think some thought needs
to be given to semantics, especially with respect to tags (should it
imply no tags? Only tags which point to refs we're already fetching?).
-Peff
^ permalink raw reply
* Re: Notes on Using Git with Subprojects
From: A Large Angry SCM @ 2006-09-28 3:47 UTC (permalink / raw)
To: Jeff King; +Cc: Martin Waitz, Shawn Pearce, Daniel Barkalow, git
In-Reply-To: <20060927173335.GC2807@coredump.intra.peff.net>
Jeff King wrote:
[...]
> One thing that I believe some people have requested for subprojects is
> to avoid downloading files/history for subprojects you're not interested
> in. I think this could be faciliated in this scheme by only cloning the
> heads of the subprojects you're interested in (there would need to be
> special machinery to handle this at the root level if we want to allow
> making root commits without necessarily having all of the subprojects).
In what I'm suggesting, commits are local to a project's working
directory repository and are pushed somewhere else to be recorded long
term. Since projects are stand alone, possibly with dependencies,
working on a (sub)project without having other associated (sub)projects
is accomplished by checking it out.
> A first step to this would be an argument to git-clone to allow cloning
> only a subset of refs.
Something like this?
git-init-db
git-fetch <repository> <refspecs>
^ permalink raw reply
* Re: git and time
From: Shawn Pearce @ 2006-09-28 3:47 UTC (permalink / raw)
To: Tom Prince; +Cc: git
In-Reply-To: <20060928033948.GC3650@socrates.priv>
Tom Prince <tom.prince@ualberta.net> wrote:
> On Wed, Sep 27, 2006 at 11:07:35PM -0400, Nicolas Pitre wrote:
> > I beg to differ. Such information might be really useful. I agree
> > though that this is an expensive operation and gitweb might not be the
> > best place for it at all.
> >
> > For example... some times I look at git-log output and finds about a
> > certain bug fix that was apparently committed a month ago. And
> > incidentally I recall having been bitten by that bug not really long
> > ago, say last week. Although the bug fix was committed _somewhere_ last
> > month, what I would really want to know is just when _i_ received that
> > bug fix in my own repository to determine if it was before or after last
> > week. So if it was before last week then I could conclude that the bug
> > fix didn't actually fix my bug. Knowing that it has been committed last
> > month is absolutely useless to me in this case.
> >
>
> But even knowing when the commit arrived in your local repository does
> you no good unless you are compiling every time you pull, in which case,
> the reflog support on you local machine will give you the information
> you need. Otherwise, you need to know the name of the commit you were
> running when you got bitten by the bug which is a separate issue.
Which is why Git embeds its version number from git-describe as
part of its build process. So "git --version" can give you back
an identifier.
And given that identifier (and the new schooling given to the
sha1 expression parser) you can easily ask git to determine if the
given bug fix commit was an ancestor of that identifier, or not.
No reflog involved and you have your answer.
As it happens I build and install `next` every time I fetch from
Junio's public tree. But I never rely on my reflog to associate
back to a commit; I always use `git --version`.
--
Shawn.
^ permalink raw reply
* Re: git and time
From: Tom Prince @ 2006-09-28 3:39 UTC (permalink / raw)
To: git
In-Reply-To: <Pine.LNX.4.64.0609272252041.9349@xanadu.home>
On Wed, Sep 27, 2006 at 11:07:35PM -0400, Nicolas Pitre wrote:
> I beg to differ. Such information might be really useful. I agree
> though that this is an expensive operation and gitweb might not be the
> best place for it at all.
>
> For example... some times I look at git-log output and finds about a
> certain bug fix that was apparently committed a month ago. And
> incidentally I recall having been bitten by that bug not really long
> ago, say last week. Although the bug fix was committed _somewhere_ last
> month, what I would really want to know is just when _i_ received that
> bug fix in my own repository to determine if it was before or after last
> week. So if it was before last week then I could conclude that the bug
> fix didn't actually fix my bug. Knowing that it has been committed last
> month is absolutely useless to me in this case.
>
But even knowing when the commit arrived in your local repository does
you no good unless you are compiling every time you pull, in which case,
the reflog support on you local machine will give you the information
you need. Otherwise, you need to know the name of the commit you were
running when you got bitten by the bug which is a separate issue.
> Nicolas
Tom
^ 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