* Re: git does the wrong thing with ambiguous names
From: Alex Riesen @ 2007-06-06 22:58 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <4667319C.9070302@nrlssc.navy.mil>
Brandon Casey, Thu, Jun 07, 2007 00:13:48 +0200:
>
> When a branch and tag have the same name, a git-checkout using that name
> succeeds (exits zero without complaining), switches to the _branch_, but
> updates the working directory contents to that specified by the _tag_.
> git-status show modified files.
Bad. To reproduce:
mkdir a && cd a && git init && :> a && git add . && git commit -m1 &&
:>b && git add . && git commit -m2 && git tag master HEAD^ &&
find .git/refs/ && gco -b new && gco master && git status
> Looks like the ambiguity issue was brought up last year, and git is now
> *supposed* to warn when it encounters an ambiguous name. I agree with
> Petr, it should fail violently, preferably as Josef Weidendorfer
> suggests also printing out the ambiguous matches so the user can cut and
> paste.
>
That'd be failing friendly :) Very good idea
^ permalink raw reply
* Re: git does the wrong thing with ambiguous names
From: Alex Riesen @ 2007-06-06 23:33 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <20070606225826.GC3969@steel.home>
Alex Riesen, Thu, Jun 07, 2007 00:58:26 +0200:
> Brandon Casey, Thu, Jun 07, 2007 00:13:48 +0200:
> >
> > When a branch and tag have the same name, a git-checkout using that name
> > succeeds (exits zero without complaining), switches to the _branch_, but
> > updates the working directory contents to that specified by the _tag_.
> > git-status show modified files.
>
> Bad. To reproduce:
>
> mkdir a && cd a && git init && :> a && git add . && git commit -m1 &&
> :>b && git add . && git commit -m2 && git tag master HEAD^ &&
> find .git/refs/ && gco -b new && gco master && git status
>
git-rev-parse actually warns about ambguities:
$ git-rev-parse --verify master
warning: refname 'master' is ambiguous.
dd5cdc387f2160bf04d02ac08dfdaf952f769357
It's just that the warning is thrown away in git-checkout.sh
A quick and _very_ messy fix could like like that:
diff --git a/builtin-rev-parse.c b/builtin-rev-parse.c
index 37addb2..3c3bc4e 100644
--- a/builtin-rev-parse.c
+++ b/builtin-rev-parse.c
@@ -368,6 +368,10 @@ int cmd_rev_parse(int argc, const char **argv, const char *prefix)
show_datestring("--min-age=", arg+8);
continue;
}
+ if (!strcmp(arg, "--fail-ambiguous")) {
+ fail_ambiguous_refs = 1;
+ continue;
+ }
if (show_flag(arg) && verify)
die("Needed a single revision");
continue;
diff --git a/cache.h b/cache.h
index 8a9d1f3..4c532c6 100644
--- a/cache.h
+++ b/cache.h
@@ -279,6 +279,7 @@ extern int assume_unchanged;
extern int prefer_symlink_refs;
extern int log_all_ref_updates;
extern int warn_ambiguous_refs;
+extern int fail_ambiguous_refs;
extern int shared_repository;
extern const char *apply_default_whitespace;
extern int zlib_compression_level;
diff --git a/environment.c b/environment.c
index 9d3e5eb..872ab36 100644
--- a/environment.c
+++ b/environment.c
@@ -18,6 +18,7 @@ int prefer_symlink_refs;
int is_bare_repository_cfg = -1; /* unspecified */
int log_all_ref_updates = -1; /* unspecified */
int warn_ambiguous_refs = 1;
+int fail_ambiguous_refs = 0;
int repository_format_version;
const char *git_commit_encoding;
const char *git_log_output_encoding;
diff --git a/git-checkout.sh b/git-checkout.sh
index 6b6facf..4c07fe5 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -57,6 +57,13 @@ while [ "$#" != "0" ]; do
usage
;;
*)
+ if ! git-rev-parse --verify --fail-ambiguous "$arg^0" \
+ 2>/dev/null
+ then
+ echo >&2 "$arg is ambiguous"
+ find "$GIT_DIR/refs/" |grep -F "$arg"|sed -e 's|.git/| |'
+ exit 1
+ fi
if rev=$(git-rev-parse --verify "$arg^0" 2>/dev/null)
then
if [ -z "$rev" ]; then
diff --git a/sha1_name.c b/sha1_name.c
index 7df01af..d094d41 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -345,6 +345,10 @@ static int get_sha1_basic(const char *str, int len, unsigned char *sha1)
if (warn_ambiguous_refs && refs_found > 1)
fprintf(stderr, warning, len, str);
+ if (fail_ambiguous_refs && refs_found > 1) {
+ fprintf(stderr, "found %d refs\n", refs_found);
+ return -1;
+ }
if (reflog_len) {
int nth, i;
^ permalink raw reply related
* Re: git does the wrong thing with ambiguous names
From: Alex Riesen @ 2007-06-07 0:01 UTC (permalink / raw)
To: Git Mailing List; +Cc: Brandon Casey, Junio C Hamano
In-Reply-To: <20070606233327.GD3969@steel.home>
Alex Riesen, Thu, Jun 07, 2007 01:33:27 +0200:
> Alex Riesen, Thu, Jun 07, 2007 00:58:26 +0200:
> > Brandon Casey, Thu, Jun 07, 2007 00:13:48 +0200:
> > >
> > > When a branch and tag have the same name, a git-checkout using that name
> > > succeeds (exits zero without complaining), switches to the _branch_, but
> > > updates the working directory contents to that specified by the _tag_.
> > > git-status show modified files.
> >
> > Bad. To reproduce:
> >
> > mkdir a && cd a && git init && :> a && git add . && git commit -m1 &&
> > :>b && git add . && git commit -m2 && git tag master HEAD^ &&
> > find .git/refs/ && gco -b new && gco master && git status
> >
>
> git-rev-parse actually warns about ambguities:
>
> $ git-rev-parse --verify master
> warning: refname 'master' is ambiguous.
> dd5cdc387f2160bf04d02ac08dfdaf952f769357
>
> It's just that the warning is thrown away in git-checkout.sh
>
> A quick and _very_ messy fix could like like that:
>
This one is much shorter and less friendly. Suggested by Junio on irc.
It makes checkout always prefer a branch.
diff --git a/git-checkout.sh b/git-checkout.sh
index 6b6facf..282c84f 100755
--- a/git-checkout.sh
+++ b/git-checkout.sh
@@ -67,6 +67,8 @@ while [ "$#" != "0" ]; do
new_name="$arg"
if git-show-ref --verify --quiet -- "refs/heads/$arg"
then
+ rev=$(git-rev-parse --verify "refs/heads/$arg^0" 2>/dev/null)
+ new="$rev"
branch="$arg"
fi
elif rev=$(git-rev-parse --verify "$arg^{tree}" 2>/dev/null)
^ permalink raw reply related
* Re: [PATCH] [RFC] Generational repacking
From: Dana How @ 2007-06-07 0:04 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, git, danahow
In-Reply-To: <11811281053874-git-send-email-sam.vilain@catalyst.net.nz>
On 6/6/07, Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> This is a quick hack at generational repacking. The idea is that you
> successively do larger repack runs as the number of packs accumulates.
>
> The commandline interface for this should be considered development
> grade only, and of course there are no tests and very verbose output
> :)
>
> The useful invocation of this is git-repack -d -g
>
> The -a option then becomes a degenerate case of generative repacking.
>
> The intention is that this should end up light enough to be triggered
> automatically whenever the (approximate) count of loose objects hits a
> threshold, like 100 or 1000 - making git repositories "maintenance
> free".
This patch complicates git-repack.sh quite a bit and
I'm unclear on what _problem_ you're addressing.
The recent LRU preferred pack patch
reduces much of the value in keeping a repository tidy
("tidy" == "few pack files").
Already git-gc calls git-repack -a -d. How do you plan to change this?
I wonder if you should be making git-gc more intelligent instead.
Also, you introduce a new pack properties file (.gen) which seems
awkward to me.
Perhaps something like this would be useful on a huge repository
under active use. But delta re-use makes full repacking quite quick for
a reasonably-sized repository already, and I don't see this being very useful
for a repository which is large due to large objects.
Thanks,
--
Dana L. How danahow@gmail.com +1 650 804 5991 cell
^ permalink raw reply
* What's cooking in git.git (topics)
From: Junio C Hamano @ 2007-06-07 2:07 UTC (permalink / raw)
To: git
In-Reply-To: <7v6466oygl.fsf@assigned-by-dhcp.cox.net>
Probably a few topics from the following will graduate to
'master' this weekend, but otherwise I expect that I'll be
extremely slow and won't be doing much git next week.
Here are the topics that have been cooking. Commits prefixed
with '-' are only in 'pu' while commits prefixed with '+' are
in 'next'. The topics list the commits in reverse chronological
order.
"pu" also contains "pu" from git-gui as of tonight.
* ar/clone (Wed Jun 6 16:39:05 2007 -0700) 1 commit
- Fix clone to setup the origin if its name ends with .git
This is meant to be merged to 'maint' as part of 1.5.2.2, but I
am taking things slowly.
* js/merge (Tue Jun 5 03:37:13 2007 +0100) 1 commit
+ git-merge-file: refuse to merge binary files
This series needs to be cherry-picked to 'maint' at some point.
* js/filter (Wed Jun 6 20:38:35 2007 +0200) 8 commits
+ filter-branch: also don't fail in map() if a commit cannot be
mapped
+ filter-branch: Use rev-list arguments to specify revision ranges.
+ filter-branch: fix behaviour of '-k'
+ filter-branch: use $(($i+1)) instead of $((i+1))
+ chmod +x git-filter-branch.sh
+ filter-branch: prevent filters from reading from stdin
+ t7003: make test repeatable
+ Add git-filter-branch
Johannes & Johannes work well together ;-). Will push out to
'master' shortly.
* lh/submodule (Wed Jun 6 11:13:02 2007 +0200) 2 commits
+ git-submodule: clone during update, not during init
+ git-submodule: move cloning into a separate function
Will push out to 'master' shortly.
* aj/pack (Sun Jun 3 20:21:41 2007 +0200) 1 commit
+ pack-check: Sort entries by pack offset before unpacking them.
Makes "git fsck --full" go a lot faster. Will push out to
'master' shortly.
* aw/cvs (Mon Jun 4 10:01:49 2007 +0100) 3 commits
+ cvsimport: add <remote>/HEAD reference in separate remotes more
+ cvsimport: update documentation to include separate remotes option
+ cvsimport: add support for new style remote layout
Makes the ref layout consistent with git managed branches;
git-svn already does this, I think.
* ep/cvstag (Sun Jun 3 02:56:36 2007 -0400) 1 commit
+ Use git-tag in git-cvsimport
Instead of handrolling a tag using lower-level mktag, this uses
git-tag.
* jh/tag (Mon Jun 4 02:54:56 2007 +0200) 6 commits
+ Add fsck_verify_ref_to_tag_object() to verify that refname matches
name stored in tag object
+ git-mktag tests: Fix and expand the mktag tests according to the
new tag object structure
+ Documentation/git-mktag: Document the changes in tag object
structure
+ git-fsck: Do thorough verification of tag objects.
+ git-show: When showing tag objects with no tag name, show tag
object's SHA1 instead of an empty string
+ Refactor git tag objects; make "tag" header optional; introduce
new optional "keywords" header
Tag refactoring. Looking good.
* ml/worktree (Wed Jun 6 23:29:59 2007 +0200) 8 commits
- setup_git_directory: fix segfault if repository is found in cwd
- test GIT_WORK_TREE
- extend rev-parse test for --is-inside-work-tree
- Use new semantics of is_bare/inside_git_dir/inside_work_tree
- introduce GIT_WORK_TREE to specify the work tree
- test git rev-parse
- rev-parse: introduce --is-bare-repository
- rev-parse: document --is-inside-git-dir
Allows you to have GIT_DIR environment that points at a
repository at an unrelated location, and still lets you work in
a working tree subdirectory by pointing its root with another
environment variable. It is an intrusive set of changes.
* ei/worktree+filter (Wed Jun 6 09:16:56 2007 +0200) 1 commit
- filter-branch: always export GIT_DIR if it is set
This is "early integration" that depends on two other topics
(GIT_WORK_TREE and filter-branch). This needs to be merged when
both topics graduate to 'master'.
* dh/repack (Fri May 25 14:40:24 2007 -0700) 1 commit
- Enhance unpack-objects for live repo and large objects
* jc/blame (Fri Apr 20 16:25:50 2007 -0700) 4 commits
- blame: show log as it goes
- git-blame: optimize get_origin() from linear search to hash-
lookup.
- git-blame: pass "struct scoreboard *" pointers around.
- blame: lift structure definitions up
* jc/diff (Mon Dec 25 01:08:50 2006 -0800) 2 commits
- test-para: combined diff between HEAD, index and working tree.
- para-walk: walk n trees, index and working tree in parallel
^ permalink raw reply
* Re: [PATCH] Fix clone to setup the origin if its name ends with .git
From: Junio C Hamano @ 2007-06-07 2:08 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070606224906.GB3969@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> The problem is visible when cloning a local repo. The cloned
> repository will have the origin url setup incorrectly: the origin name
> will be copied verbatim in origin url of the cloned repository.
> Normally, the name is to be expanded into absolute path.
Thanks.
> diff --git a/git-clone.sh b/git-clone.sh
> index fdd354f..d45618d 100755
> --- a/git-clone.sh
> +++ b/git-clone.sh
> @@ -20,7 +20,7 @@ usage() {
> get_repo_base() {
> (
> cd "`/bin/pwd`" &&
> - cd "$1" &&
> + cd "$1" || cd "$1.git" &&
> {
> cd .git
> pwd
We would probably need a to clean up this test a bit, though.
When we write our tests, we tend to forget testing the cases
where things ought to fail.
I'll probably redo the test myself, but for the record...
- Please never "unset" GIT_CONFIG. We do not want the tests to
get affected with /etc/gitconfig or $HOME/.gitconfig;
- We would also want to test the cases where a bare repository
x exists and x.git does not, and try cloning it into y and z
respectively. Obviously the former should work and the
latter should fail.
^ permalink raw reply
* What's in git.git (stable)
From: Junio C Hamano @ 2007-06-07 2:08 UTC (permalink / raw)
To: git
In-Reply-To: <7v4plqoyg5.fsf@assigned-by-dhcp.cox.net>
It has been slow on the stable front.
* The 'maint' branch has these fixes since the last announcement.
Johannes Sixt (1):
Accept dates before 2000/01/01 when specified as seconds since the epoch
Michael Milligan (1):
git-cvsimport: Make sure to use $git_dir always instead of .git sometimes
Sam Vilain (1):
fix documentation of unpack-objects -n
* The 'master' branch has these since the last announcement
in addition to the above.
Geert Bosch (1):
Unify write_index_file functions
Johannes Schindelin (5):
Update to SubmittingPatches
git-fsck: learn about --verbose
Move buffer_is_binary() to xdiff-interface.h
merge-recursive: refuse to merge binary files
t5000: skip ZIP tests if unzip was not found
Johannes Sixt (1):
Makefile: Remove git-merge-base from PROGRAMS.
Jon Loeliger (1):
Add the --numbered-files option to git-format-patch.
Josh Triplett (1):
Fix typo in git-mergetool
Junio C Hamano (4):
Remove git-applypatch
Release Notes: start preparing for 1.5.3
git-apply: what is detected and fixed is not just trailing spaces.
git-branch --track: fix tracking branch computation.
Lars Hjemli (2):
Add git-submodule command
Add basic test-script for git-submodule
Martin Koegler (1):
gitweb: Handle non UTF-8 text better
Matthias Lederhofer (2):
add git-filter-branch to .gitignore
make clean should remove all the test programs too
Matthijs Melchior (1):
Teach git-tag about showing tag annotations.
Petr Baudis (1):
git-applymbox: Remove command
Pierre Habouzit (1):
$EMAIL is a last resort fallback, as it's system-wide.
Randal L. Schwartz (1):
Add test-sha1 to .gitignore.
Sam Vilain (1):
Don't assume tree entries that are not dirs are blobs
^ permalink raw reply
* Re: [PATCH] Documentation typo.
From: Junio C Hamano @ 2007-06-07 2:09 UTC (permalink / raw)
To: Pierre Habouzit; +Cc: git
In-Reply-To: <20070606221806.GA23830@artemis>
Pierre Habouzit <madcoder@debian.org> writes:
>> Unfortunately our documentation pages were written with AsciiDoc
>> 7, and are not AsciiDoc 8 compatible.
>>
>> With -aasciidoc7compatible, AsciiDoc 8 is _supposed_ to behave
>> compatibly, but in reality it does not format our documentation
>> correctly. It certainly is possible that AsciiDoc 7 "happens to
>> work" with our documentation pages, and maybe the way we abuse
>> mark-ups can be argued the bug in _our_ documentation, but
>> nobody on our end worked on finding a satisfactory solution to
>> make our documentation format correctly with _both_ versions of
>> AsciiDoc yet.
>> ...
>
> Okay, I see, sorry for the noise then.
Well, it was NOT a noise. Making the docs usable with both 7
and 8 is a task waiting for a volunteer ;-).
^ permalink raw reply
* Re: [PATCH v2] Remove useless uses of cat, and replace with filename arguments or redirection
From: Junio C Hamano @ 2007-06-07 2:09 UTC (permalink / raw)
To: Josh Triplett; +Cc: git
In-Reply-To: <466639D0.1040306@freedesktop.org>
Josh Triplett <josh@freedesktop.org> writes:
> Replace all uses of cat that do nothing other than read a single file. In the
> case of git-quilt-import, this occurs once per patch.
>
> Signed-off-by: Josh Triplett <josh@freedesktop.org>
> ---
>
> This revised version fixes a bug caught by Stephen Rothwell: the output of wc
> -l changes when it has a filename on the command line. The same bug occurred
> in one other place as well.
Hmph...
> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> index 0c8a7df..346cf3f 100644
> --- a/git-filter-branch.sh
> +++ b/git-filter-branch.sh
> @@ -333,7 +333,7 @@ for commit in $unchanged; do
> done
>
> git-rev-list --reverse --topo-order $srcbranch --not $unchanged >../revs
> -commits=$(cat ../revs | wc -l | tr -d " ")
> +commits=$(wc -l ../revs | tr -d -c 0-9)
... and left unfixed ;-)?
^ permalink raw reply
* Re: [PATCH v2] Remove useless uses of cat, and replace with filename arguments or redirection
From: Josh Triplett @ 2007-06-07 2:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vsl94sego.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 1062 bytes --]
Junio C Hamano wrote:
> Josh Triplett <josh@freedesktop.org> writes:
>> Replace all uses of cat that do nothing other than read a single file. In the
>> case of git-quilt-import, this occurs once per patch.
>>
>> Signed-off-by: Josh Triplett <josh@freedesktop.org>
>> ---
>>
>> This revised version fixes a bug caught by Stephen Rothwell: the output of wc
>> -l changes when it has a filename on the command line. The same bug occurred
>> in one other place as well.
>
> Hmph...
>
>> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
>> index 0c8a7df..346cf3f 100644
>> --- a/git-filter-branch.sh
>> +++ b/git-filter-branch.sh
>> @@ -333,7 +333,7 @@ for commit in $unchanged; do
>> done
>>
>> git-rev-list --reverse --topo-order $srcbranch --not $unchanged >../revs
>> -commits=$(cat ../revs | wc -l | tr -d " ")
>> +commits=$(wc -l ../revs | tr -d -c 0-9)
>
> ... and left unfixed ;-)?
No, just fixed differently. :) Note the change to the tr invocation: delete
everything other than digits.
- Josh Triplett
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* Re: [PATCH] [RFC] Generational repacking
From: Sam Vilain @ 2007-06-07 2:28 UTC (permalink / raw)
To: Dana How; +Cc: Junio C Hamano, git
In-Reply-To: <56b7f5510706061704r34692c49v994ff368bbc12d05@mail.gmail.com>
Dana How wrote:
> This patch complicates git-repack.sh quite a bit and
> I'm unclear on what _problem_ you're addressing.
The problem is simple, and it is partially in the eye of the beholder.
That is;
1. without repacking, you get a lot of loose objects.
- unnecessary disk space usage
- bad performance on many OSes
2. repack takes too long to run very regularly; it's an occasional
command.
3. the perception that git repositories are not maintenance free.
What I'm aiming for is something which is light enough that it might
even win back the performance loss you got from 1), and to solve the
perception problem of 3).
Much as users who don't like automatic database maintenance turn it off
and run it at the best time, advanced git users will want to disable
this feature in ~/.gitrc and run repack themselves when it suits them,
or via cron or whatever. Or it's disabled by default and users that
whine get told to turn it on, it really doesn't matter. I can already
do it with a commit hook, so I'm quite happy.
> The recent LRU preferred pack patch
> reduces much of the value in keeping a repository tidy
> ("tidy" == "few pack files").
Great, that is a good thing.
Pack files are an almost indistinguishable concept from database
partitions. In terms of that, scaling problems with lots of partitions
can be managed, certainly.
For instance with database partitioning you would expect your query
planner (in this case, read_packed_sha1()) to be able to select the
right partition (pack) to go to first to avoid excessive index lookups.
That a strategy for picking the best pack quickly N% of the time exists
for git is an excellent measure to reduce the impact of a large number
of pack files. I think you would probably find measurable wins by
ensuring that the gross number of packs is kept limited.
Consider that I'm thinking of running this generational repack somewhere
such as a commit hook, if it found >100 loose objects, so that the first
generation repack is very quick and doesn't annoy me - and the second
generation will similarly be fairly quick as many deltas will already be
computed. The exact behaviour will probably require tuning to get a
good balance between good delta computation and minimal interruption to
commit flow. Someone on IRC floated the idea of making the first
generation do no delta computation to make it lightning fast.
Note that if you had 3 pack generations, only the first two levels will
ever be repacked - you'll end up with an unlimited number of third
generation packs, which will also end up in LRP* order.
> Already git-gc calls git-repack -a -d. How do you plan to change this?
> I wonder if you should be making git-gc more intelligent instead.
>
> Also, you introduce a new pack properties file (.gen) which seems
> awkward to me.
This implementation is a simple demonstration of the logic which was
designed to communicate the idea and stimulate discussion. I think the
logic could probably go elsewhere too, and yes the new file is a bit of
a hack.
It might be better to base the "generation" assessment of the file on
the actual size of the pack, for instance - ie, Instead of the number of
loose objects, the size of the loose objects, call 1st generation = <1MB
pack, 2nd generation = <5MB, etc. When the combined size of 1st
generation packs gets above 5MB then that generation is full and a new
2nd generation pack is made. Then no state file is required.
> Perhaps something like this would be useful on a huge repository
> under active use. But delta re-use makes full repacking quite quick for
> a reasonably-sized repository already, and I don't see this being very useful
> for a repository which is large due to large objects.
I agree with your point of view, however I think if the feature is out
there but disabled by default then this can be found through experience.
As you can see all of the elements to implement it are already there -
and as you mention, combining packs is already quick.
Sam.
* Last Recently Packed ;)
^ permalink raw reply
* Re: [PATCH v2] Remove useless uses of cat, and replace with filename arguments or redirection
From: Junio C Hamano @ 2007-06-07 2:52 UTC (permalink / raw)
To: Josh Triplett; +Cc: git
In-Reply-To: <46676C35.60406@freedesktop.org>
Josh Triplett <josh@freedesktop.org> writes:
> No, just fixed differently. :) Note the change to the tr invocation: delete
> everything other than digits.
Ah, silly me. Sorry for the noise.
^ permalink raw reply
* Re: [PATCH] [RFC] Generational repacking
From: Nicolas Pitre @ 2007-06-07 3:05 UTC (permalink / raw)
To: Dana How; +Cc: Sam Vilain, Junio C Hamano, git
In-Reply-To: <56b7f5510706061704r34692c49v994ff368bbc12d05@mail.gmail.com>
On Wed, 6 Jun 2007, Dana How wrote:
> On 6/6/07, Sam Vilain <sam.vilain@catalyst.net.nz> wrote:
> > This is a quick hack at generational repacking. The idea is that you
> > successively do larger repack runs as the number of packs accumulates.
> >
> This patch complicates git-repack.sh quite a bit and
> I'm unclear on what _problem_ you're addressing.
> The recent LRU preferred pack patch
> reduces much of the value in keeping a repository tidy
> ("tidy" == "few pack files").
[...]
For the record... I didn't comment on this patch because I couldn't
form
a clear opinion about it.
But until its usefulness can be demonstrated I should side with Dana
here.
Nicolas
^ permalink raw reply
* Re: [PATCH] [RFC] Generational repacking
From: Nicolas Pitre @ 2007-06-07 3:20 UTC (permalink / raw)
To: Sam Vilain; +Cc: Dana How, Junio C Hamano, git
In-Reply-To: <46676D44.7070703@vilain.net>
On Thu, 7 Jun 2007, Sam Vilain wrote:
> Dana How wrote:
> > This patch complicates git-repack.sh quite a bit and
> > I'm unclear on what _problem_ you're addressing.
>
> The problem is simple, and it is partially in the eye of the beholder.
>
> That is;
>
> 1. without repacking, you get a lot of loose objects.
> - unnecessary disk space usage
> - bad performance on many OSes
No argument.
> 2. repack takes too long to run very regularly; it's an occasional
> command.
It doesn't take long at all when you don't use -a.
> 3. the perception that git repositories are not maintenance free.
But this perception is true! It is possible to automate it, but some
maintenance is necessary at some point.
> What I'm aiming for is something which is light enough that it might
> even win back the performance loss you got from 1), and to solve the
> perception problem of 3).
Run git-repack without -a from some hook. You can even launch it in the
background.
Or what am I missing?
Nicolas
^ permalink raw reply
* Re: [PATCH v2] Remove useless uses of cat, and replace with filename arguments or redirection
From: Johannes Schindelin @ 2007-06-07 4:06 UTC (permalink / raw)
To: Josh Triplett; +Cc: Junio C Hamano, git
In-Reply-To: <46676C35.60406@freedesktop.org>
Hi,
On Wed, 6 Jun 2007, Josh Triplett wrote:
> Junio C Hamano wrote:
> > Josh Triplett <josh@freedesktop.org> writes:
> >> Replace all uses of cat that do nothing other than read a single file. In the
> >> case of git-quilt-import, this occurs once per patch.
> >>
> >> Signed-off-by: Josh Triplett <josh@freedesktop.org>
> >> ---
> >>
> >> This revised version fixes a bug caught by Stephen Rothwell: the output of wc
> >> -l changes when it has a filename on the command line. The same bug occurred
> >> in one other place as well.
> >
> > Hmph...
> >
> >> diff --git a/git-filter-branch.sh b/git-filter-branch.sh
> >> index 0c8a7df..346cf3f 100644
> >> --- a/git-filter-branch.sh
> >> +++ b/git-filter-branch.sh
> >> @@ -333,7 +333,7 @@ for commit in $unchanged; do
> >> done
> >>
> >> git-rev-list --reverse --topo-order $srcbranch --not $unchanged >../revs
> >> -commits=$(cat ../revs | wc -l | tr -d " ")
> >> +commits=$(wc -l ../revs | tr -d -c 0-9)
> >
> > ... and left unfixed ;-)?
>
> No, just fixed differently. :) Note the change to the tr invocation: delete
> everything other than digits.
Actually, it feels wrong. For example, if some wc some day decides to
display the size in kilobyte, even if you say "-l", it would fail badly.
That is, it would fail to function properly, but would not tell you that
it failed.
Things like that are known to happen, and that's why "wc -l < file" is a
better fix than "wc -l file | tr -dc 0-9". In this case, it might not
matter for a long time, but why not stop being sloppy here and now?
Ciao,
Dscho
^ permalink raw reply
* pull/merge --no-commit
From: kurt_p_lloyd @ 2007-06-07 4:26 UTC (permalink / raw)
To: git
Hello,
I'm new to git, thought I'd take it for a spin.
Found what seems to me to be a problem,
hoping someone can shed light on it.
I /really/ want --no-commit to work, bit it doesn't seem to:
I run: git pull --no-commit ssh://<blah blah blah>
then I run: git status
it says: nothing to commit (working directory clean)
then I run: git log
it shows the commit message from the other user below a
commit sha1, and the change I pulled was indeed merged to
my file.
Does this seem to be a bug, or am I doing something wrong?
BTW, merge --no-commit gives me the same problem. It merges
fine but does the commit.
I put a 'set -x' in the git-merge shell script (which gets
called by pull) from one of my 'pull' runs, I have the output
if anyone wants it.
-Kurt
^ permalink raw reply
* Re: Git Vs. Svn for a project which *must* distribute binaries too.
From: linux @ 2007-06-07 4:36 UTC (permalink / raw)
To: git, godeater
There's no reason that git can't do everything you have svn doing.
What SVN calls "commit access" is what git refers to as "push access",
but it's exactly the same thing. I don't see how it's the tiniest bit
more difficult.
The only difference is that in git, it's a two-stage process: you commit
locally, and then push that commit (or, more commonly, a whole chain of
commits) when it's ready. But to the receiving repository, it's just
another commit.
You can have a central server, just like you have with SVN, and when it
gets new versions, it can auto-build them and do whatever it likes with
the binaries. (Including stick them in the same git repository, or
a different one.)
There's no need for such a central repository to be "owned" by one particular
person. You can have a shared repository with multiple people having commit
access. Linus likes to keep very tight security over his master repoisitory
and only pull, but git supports a shared-access repository just fine.
The only thing, and it's not a very big thing, is that if you want
fine-grained access control, you have to implement it yourself via the
pre-receive hook rather than having a canned implementation ready.
As for making a binary of every commit, git encourages a slightly
different workflow:
- Because commits are very easy, and private (until pushed), you're
encouraged to make lots of small commits. I used to hold of committing to
CVS if working on a big patch. Now, I use git freely on a private branch
to keep track of my own hacking.
(git-gui is nice for encouraging me to commit frequently. As I make
edits, I write the commit message and watch the patch grow. When it
gets big enough, click "commit" and keep going. I have a perfectly good
memory, but after three phone calls, two "just a quick question"s and
an impromptu meeting, the notes make it quicker to get back into it.)
- If you later decide the commits aren't something you want to show the world,
then don't. You can cherry-pick the good ideas and kill the lousy ones.
- The simplest example of this is "git commit --amend". Git lets you
commit before testing, and if you find some stupid typo that prevents
the code from even compiling, you can just fix it and re-do the commit.
*Poof*, your embarassing mistake just disappeared.
(When learning git merges, it took me a log time to get over my fear of
committing a mis-merge. With git, it doesn't matter; it's just as
easy to undo a commit as to do one, as long as you haven't published
the results.)
- On the other hand, if you want to enjoy the full benefits of git-bisect,
which can let J. Random Bug-submitter find the commit that caused a
regression while you eat chilled grapes on the beach, you want both
small commits and commits that don't break the build. So cleaning up
your history before publishing can be a very worthwhile effort.
This is a step that many people aren't used to doing, and you don't
need to force it on your developers. Linus has long required such
efforts, to make code review easier, but there are different traditions.
But it really does make tracking down bugs a lot easier.
Anyway, because of the small-commit tendency, you might want to only
build one binary per push, not one binary per version. (Oh, I should
note that it is perfectly legal to push an old version that the receiving
repository already has. It has no effect on the repository, but you
could have it tickle your autobuilder. Check with someone who knows
whether git even runs the commit hooks in that case, though.)
But you can do whatever. git-archive is a useful little tool for getting
source snapshots to compile.
Once you've built the binary, you can, if you like, put it into a git
branch by itself. You could even put it in the same repository as the
sources, but with a totally disjoint history, but if you never intend
to merge the branches, that just complicates your life and increases
the chance that somebody will clone that branch. It makes more sense
to use a separate repository.
^ permalink raw reply
* Re: pull/merge --no-commit
From: kurt_p_lloyd @ 2007-06-07 4:39 UTC (permalink / raw)
To: git
In-Reply-To: <46678909.10608@alcatel-lucent.com>
PS - Sorry, I should have mentioned the git version: 1.5.2.1
kurt_p_lloyd wrote:
> Hello,
> I'm new to git, thought I'd take it for a spin.
> Found what seems to me to be a problem,
> hoping someone can shed light on it.
>
> I /really/ want --no-commit to work, bit it doesn't seem to:
>
> I run: git pull --no-commit ssh://<blah blah blah>
>
> then I run: git status
>
> it says: nothing to commit (working directory clean)
>
> then I run: git log
>
> it shows the commit message from the other user below a
> commit sha1, and the change I pulled was indeed merged to
> my file.
>
> Does this seem to be a bug, or am I doing something wrong?
> BTW, merge --no-commit gives me the same problem. It merges
> fine but does the commit.
>
> I put a 'set -x' in the git-merge shell script (which gets
> called by pull) from one of my 'pull' runs, I have the output
> if anyone wants it.
>
> -Kurt
^ permalink raw reply
* Re: [PATCH] Accept dates before 2000/01/01 when specified as seconds since the epoch
From: Sam Vilain @ 2007-06-07 5:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vtztl5vvb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> I vaguely recall hitting the same issue soon after date.c was
> done, and sending in a patch in the same spirit but with
> different implementation (I essentially duplicated that "seconds
> since epoch" without any cutoff as the last ditch fallback) long
> time ago (this was before I took git over; the patch was rejected).
>
> It almost makes me wonder if it is better to introduce a special
> syntax to denote "seconds since epoch plus timezone offset" for
> our Porcelain use, instead of keeping this arbitrary cut-off
> date which nobody can agree on and which forces us to roll back
> from time to time. For one thing, such a syntax would allow us
> to talk about a timestamp before the epoch.
>
> Perhaps
>
> "epoch" [-+] [0-9]+ " " [-+][0-9][0-9][0-9][0-9]
Probably a good idea, though it would break cg-admin-rewritehist. I had
to make a similar change when working with the Perl history. Perhaps
allow both?
There is a 10 digit ISO forms (YYYYMMDDHH) and a 9 digit form
(YYYYDDDHH), but these are very rare :)
Sam.
^ permalink raw reply
* Re: [ANNOUNCE] qgit new "smart browsing" feature
From: Marco Costalba @ 2007-06-07 5:11 UTC (permalink / raw)
To: Andy Parkins; +Cc: git, Pavel Roskin, Jan Hudec
In-Reply-To: <200706060930.49621.andyparkins@gmail.com>
On 6/6/07, Andy Parkins <andyparkins@gmail.com> wrote:
> On Tuesday 2007 June 05, Marco Costalba wrote:
>
>
> I've experienced a few occasions when the wheel scroll goes a bit strange.
> I've not figured exactly what I did to trigger it, but it was something like
> this: when scrolling up and down a lot, and causing the page flip to the
> message view, suddenly the scroll didn't work for normal upward scrolling. I
> flipped pages again and it started working.
>
> I'll try and narrow down exactly what I'm doing and be more precise.
>
Thanks I'll appreciate.
This wheel scroll thing turned out to be really not trivial, BTW your
tabbed panes are far easier to implement. There are many little nasty
details to take care of to make it work correctly.
> For now, latest qgit is in /usr/local/bin, so will be getting daily use.
>
Great.
Marco
^ permalink raw reply
* Re: [PATCH] [RFC] Generational repacking
From: Sam Vilain @ 2007-06-07 5:13 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.99.0706062314410.12885@xanadu.home>
Nicolas Pitre wrote:
>> 2. repack takes too long to run very regularly; it's an occasional
>> command.
> It doesn't take long at all when you don't use -a.
Well that depends how many loose objects there are :) I heard about on
Windows a case where packing 30k loose objects took over an hour.
>> What I'm aiming for is something which is light enough that it might
>> even win back the performance loss you got from 1), and to solve the
>> perception problem of 3).
>
> Run git-repack without -a from some hook. You can even launch it in the
> background.
>
> Or what am I missing?
If you repack every 100 objects without -a, sure it will be fast, but
you'll end up with too many packs.
Sam.
^ permalink raw reply
* Re: pull/merge --no-commit
From: Junio C Hamano @ 2007-06-07 5:24 UTC (permalink / raw)
To: kurt_p_lloyd; +Cc: git
In-Reply-To: <46678909.10608@alcatel-lucent.com>
kurt_p_lloyd <kplloyd@alcatel-lucent.com> writes:
> I run: git pull --no-commit ssh://<blah blah blah>
>
> then I run: git status
>
> it says: nothing to commit (working directory clean)
>
> then I run: git log
>
> it shows the commit message from the other user below a
> commit sha1, and the change I pulled was indeed merged to
> my file.
>
> Does this seem to be a bug, or am I doing something wrong?
No bug, no user error.
I suspect you did not have _ANY_ of your own development. If
that is the case, then it worked as you told it to. You asked
no merge commit to be made, and it did not create a new merge
commit.
Illustration. Earlier you had (probably your git-clone created
this) this history:
---A---B---C---D
^ HEAD
and your tip of the branch (and HEAD) was at commit D. You did
not do any of your own development yourself, and then you
pulled.
In the meantime, the other repository had been busily working
and has a few more commits:
---A---B---C---D---E---F---G---H
^ ^
Your HEAD The tip of the branch you
was here. pulled is here.
In this case, because you do not have anything new to add to the
history (remember, git history is a global DAG -- you and the
other repository are building it by pushing and pulling), we
move your HEAD to H (the tip of the branch you are pulling).
There is no need to create a new merge commit, with or without
the --no-commit option. This is called "fast forward".
In a more interesting case, you will see a different behaviour.
Let's suppose you started from the same state (i.e. cloned up to
D), and built your own changes on top of it:
Your HEAD
v
X---Y---Z
/
---A---B---C---D
while the other repository had the same E...H development line.
You pull from them. Remember, pull is a fetch followed by a
merge. After the fetch, you get this:
Your HEAD
v
X---Y---Z
/
---A---B---C---D---E---F---G---H
^
The tip of the branch you
pulled is here.
This is not a "fast forward" situation and "git pull" would need
a new merge commit, like this:
Your HEAD used to be here
v
X---Y---Z-------M <- A new merge commit
/ / becomes HEAD
---A---B---C---D---E---F---G---H
^
The tip of the branch you
pulled is here.
What --no-commit does is to prepare a tree to be used to create
the merge commit "M", without actually creating a commit. So if
you did "git pull --no-commit", your HEAD would stay at Z and
your index and working tree is prepared to create the tree
suitable to be committed as "M". After that, you have a chance
to make further changes to your working tree before creating a
commit with "git commit", to affect what is recorded in the
resulting merge commit "M".
In the case of "fast forward", --no-commit still moves the HEAD,
and this is deliberate. Imagine if we did not move the head.
Because the merge is "fast forward" in reality, what is left in
the index and the working tree to be committed should exactly
match what is in H. You may futz with the working tree further
before actually creating the commit, and the next "git commit"
would give you this graph:
.---------------M
/ /
---A---B---C---D---E---F---G---H
^ ^
Your HEAD The tip of the branch you
is still here. pulled is here.
The difference between H and M is strictly what you did to the
index and the working tree between "pull --no-commit" and
"commit".
That is insane. Why? Because what you really did was to start
from the tree of H, did your own development (i.e. "diff H M"),
and made a commit. This is the reason why --no-commit does not
do anything special when the pull is a fast forward.
The resulting history should not be the above merge, but just
like this:
---A---B---C---D---E---F---G---H---M
You did a "fast forward", and did your own development to make a
single commit, which is what this history should look like.
There was no merge performed. Just a straight line of
development on top of what you got from the other side.
^ permalink raw reply
* Re: [PATCH] Accept dates before 2000/01/01 when specified as seconds since the epoch
From: Junio C Hamano @ 2007-06-07 5:29 UTC (permalink / raw)
To: Sam Vilain; +Cc: Johannes Sixt, git
In-Reply-To: <46679320.6000309@vilain.net>
Sam Vilain <sam@vilain.net> writes:
>> Perhaps
>>
>> "epoch" [-+] [0-9]+ " " [-+][0-9][0-9][0-9][0-9]
>
> Probably a good idea, though it would break cg-admin-rewritehist.
I was saying "additionally allow that to express timestamp even
before the epoch", and existing cg-admin-rewritehist does not
feed such a string, so I do not know how the additionally
allowed format could break it. Maybe I am missing something?
In any case, "timestamps after March 1973" patch from j6t is
a good change independent from the above one.
^ permalink raw reply
* Re: [PATCH] Accept dates before 2000/01/01 when specified as seconds since the epoch
From: Johannes Schindelin @ 2007-06-07 5:30 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, Johannes Sixt, git
In-Reply-To: <46679320.6000309@vilain.net>
Hi,
On Thu, 7 Jun 2007, Sam Vilain wrote:
> Junio C Hamano wrote:
> > I vaguely recall hitting the same issue soon after date.c was
> > done, and sending in a patch in the same spirit but with
> > different implementation (I essentially duplicated that "seconds
> > since epoch" without any cutoff as the last ditch fallback) long
> > time ago (this was before I took git over; the patch was rejected).
> >
> > It almost makes me wonder if it is better to introduce a special
> > syntax to denote "seconds since epoch plus timezone offset" for
> > our Porcelain use, instead of keeping this arbitrary cut-off
> > date which nobody can agree on and which forces us to roll back
> > from time to time. For one thing, such a syntax would allow us
> > to talk about a timestamp before the epoch.
> >
> > Perhaps
> >
> > "epoch" [-+] [0-9]+ " " [-+][0-9][0-9][0-9][0-9]
>
> Probably a good idea, though it would break cg-admin-rewritehist.
FWIW I don't think we have to care that much about cg-admin-rewritehist,
since it lives on as git-filter-branch, and we can adapt it as we go.
Ciao,
Dscho
^ permalink raw reply
* Re: git-svn "cannot lock ref" error during fetch
From: Eric Wong @ 2007-06-07 6:31 UTC (permalink / raw)
To: James Peach; +Cc: git
In-Reply-To: <50C9688F-9C62-43AC-A84D-D84561671BAC@mac.com>
James Peach <jamespeach@mac.com> wrote:
> Hi all,
>
> I'm new to git, and I'm experimenting with using git-svn to interact
> with a large SVN repository with lots of branches.
>
> I initially did an init like this:
>
> git-svn init -t tags -b branches -T trunk svn+ssh://server/svn/project
>
> Then I did a git-svn fetch, which started pulling all the branches.
> After a while, however, it hit a branch that it couldn't pull:
>
> Found branch parent: (tags/project-92~9)
> 767f1f1601a4deae459c99ea6c1d1b9ba8f57a65
> Following parent with do_update
> ...
> Successfully followed parent
> fatal: refs/remotes/tags/project-92~9: cannot lock the ref
> update-ref -m r13726 refs/remotes/tags/project-92~9
> 950638ff72acc278156a0d55baafbabb43f2b772: command returned error: 128
>
> Some amount of searching failed to turn up any hints on what this
> error means or how I can work around it. I'd appreciate any advice ...
Is there a tag actually named "project-92~9"? If so, it's
an invalid branch name for git. I started working on a way
around it by mapping new names to it, but haven't gotten around to
finishing it....
--
Eric Wong
^ 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