* Re: [RFC/PATCHv8 00/10] git notes
From: Junio C Hamano @ 2009-11-20 10:46 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Johan Herland, git, spearce
In-Reply-To: <20091120192800.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
>> Step 0. Apply as you specified on top of 'next'
>>
>> $ git checkout next^0
>> $ git am -s your-10-patches
>> $ M=$(git describe)
>>
>> Step 1. Rebase back to the bottom of the old series
>>
>> $ git checkout next...jh/notes
>
> What do three-dots mean in this command?
>
>> $ git rebase --onto HEAD next $M
>> $ N=$(git describe)
Heh, good eyes.
I forgot that I had this toy hidden from the general public.
-- >8 --
Subject: [PATCH] "checkout A...B" switches to the merge base between A and B
When flipping commits around on topic branches, I often end up doing
this sequence:
* Run "log --oneline next..jc/frotz" to find out the first commit
on 'jc/frotz' branch not yet merged to 'next';
* Run "checkout $that_commit^" to detach HEAD to the parent of it;
* Rebuild the series on top of that commit; and
* "show-branch jc/frotz HEAD" and "diff jc/frotz HEAD" to verify.
Introduce a new syntax to "git checkout" to name the commit to switch to,
to make the first two steps easier. When the branch to switch to is
specified as A...B (you can omit either A or B but not both, and HEAD
is used instead of the omitted side), the merge base between these two
commits are computed, and if there is one unique one, we detach the HEAD
at that commit.
With this, I can say "checkout next...jc/frotz".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-checkout.c | 7 +++++--
cache.h | 1 +
sha1_name.c | 42 ++++++++++++++++++++++++++++++++++++++++++
t/t2012-checkout-last.sh | 27 ++++++++++++++++++++++++++-
4 files changed, 74 insertions(+), 3 deletions(-)
diff --git a/builtin-checkout.c b/builtin-checkout.c
index 64f3a11..7167111 100644
--- a/builtin-checkout.c
+++ b/builtin-checkout.c
@@ -690,7 +690,10 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
* case 3: git checkout <something> [<paths>]
*
* With no paths, if <something> is a commit, that is to
- * switch to the branch or detach HEAD at it.
+ * switch to the branch or detach HEAD at it. As a special case,
+ * if <something> is A...B (missing A or B means HEAD but you can
+ * omit at most one side), and if there is a unique merge base
+ * between A and B, A...B names that merge base.
*
* With no paths, if <something> is _not_ a commit, no -t nor -b
* was given, and there is a tracking branch whose name is
@@ -716,7 +719,7 @@ int cmd_checkout(int argc, const char **argv, const char *prefix)
if (!strcmp(arg, "-"))
arg = "@{-1}";
- if (get_sha1(arg, rev)) {
+ if (get_sha1_mb(arg, rev)) {
if (has_dash_dash) /* case (1) */
die("invalid reference: %s", arg);
if (!patch_mode &&
diff --git a/cache.h b/cache.h
index 71a731d..f8df15a 100644
--- a/cache.h
+++ b/cache.h
@@ -703,6 +703,7 @@ extern const char *resolve_ref(const char *path, unsigned char *sha1, int, int *
extern int dwim_ref(const char *str, int len, unsigned char *sha1, char **ref);
extern int dwim_log(const char *str, int len, unsigned char *sha1, char **ref);
extern int interpret_branch_name(const char *str, struct strbuf *);
+extern int get_sha1_mb(const char *str, unsigned char *sha1);
extern int refname_match(const char *abbrev_name, const char *full_name, const char **rules);
extern const char *ref_rev_parse_rules[];
diff --git a/sha1_name.c b/sha1_name.c
index 44bb62d..d5a240c 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -794,6 +794,48 @@ release_return:
return retval;
}
+int get_sha1_mb(const char *name, unsigned char *sha1)
+{
+ struct commit *one, *two;
+ struct commit_list *mbs;
+ unsigned char sha1_tmp[20];
+ const char *dots;
+ int st;
+
+ dots = strstr(name, "...");
+ if (!dots)
+ return get_sha1(name, sha1);
+ if (dots == name)
+ st = get_sha1("HEAD", sha1_tmp);
+ else {
+ struct strbuf sb;
+ strbuf_init(&sb, dots - name);
+ strbuf_add(&sb, name, dots - name);
+ st = get_sha1(sb.buf, sha1_tmp);
+ strbuf_release(&sb);
+ }
+ if (st)
+ return st;
+ one = lookup_commit_reference_gently(sha1_tmp, 0);
+ if (!one)
+ return -1;
+
+ if (get_sha1(dots[3] ? (dots + 3) : "HEAD", sha1_tmp))
+ return -1;
+ two = lookup_commit_reference_gently(sha1_tmp, 0);
+ if (!two)
+ return -1;
+ mbs = get_merge_bases(one, two, 1);
+ if (!mbs || mbs->next)
+ st = -1;
+ else {
+ st = 0;
+ hashcpy(sha1, mbs->item->object.sha1);
+ }
+ free_commit_list(mbs);
+ return st;
+}
+
/*
* This is like "get_sha1_basic()", except it allows "sha1 expressions",
* notably "xyz^" for "parent of xyz"
diff --git a/t/t2012-checkout-last.sh b/t/t2012-checkout-last.sh
index 87b30a2..b44de9d 100755
--- a/t/t2012-checkout-last.sh
+++ b/t/t2012-checkout-last.sh
@@ -1,6 +1,6 @@
#!/bin/sh
-test_description='checkout can switch to last branch'
+test_description='checkout can switch to last branch and merge base'
. ./test-lib.sh
@@ -91,4 +91,29 @@ test_expect_success 'switch to twelfth from the last' '
test "z$(git symbolic-ref HEAD)" = "zrefs/heads/branch13"
'
+test_expect_success 'merge base test setup' '
+ git checkout -b another other &&
+ echo "hello again" >>world &&
+ git add world &&
+ git commit -m third
+'
+
+test_expect_success 'another...master' '
+ git checkout another &&
+ git checkout another...master &&
+ test "z$(git rev-parse --verify HEAD)" = "z$(git rev-parse --verify master^)"
+'
+
+test_expect_success '...master' '
+ git checkout another &&
+ git checkout ...master &&
+ test "z$(git rev-parse --verify HEAD)" = "z$(git rev-parse --verify master^)"
+'
+
+test_expect_success 'master...' '
+ git checkout another &&
+ git checkout master... &&
+ test "z$(git rev-parse --verify HEAD)" = "z$(git rev-parse --verify master^)"
+'
+
test_done
--
1.6.5.3.342.g14bb9
^ permalink raw reply related
* Re: [RFC/PATCHv8 00/10] git notes
From: Johannes Schindelin @ 2009-11-20 10:36 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, Johan Herland, git, spearce
In-Reply-To: <20091120192800.6117@nanako3.lavabit.com>
Hi,
On Fri, 20 Nov 2009, Nanako Shiraishi wrote:
> Quoting Junio C Hamano <gitster@pobox.com>
>
> > So here is what I did tonight.
> >
> > Step 0. Apply as you specified on top of 'next'
> >
> > $ git checkout next^0
> > $ git am -s your-10-patches
> > $ M=$(git describe)
> >
> > Step 1. Rebase back to the bottom of the old series
> >
> > $ git checkout next...jh/notes
>
> What do three-dots mean in this command?
Maybe it means "go back to the bottom of the old series"? ;-) IIUC it is
the equivalent of
$ git checkout $(git merge-base next jh/notes)
Hth,
Dscho
^ permalink raw reply
* Re: [RFC/PATCHv8 00/10] git notes
From: Nanako Shiraishi @ 2009-11-20 10:28 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johan Herland, git, spearce
In-Reply-To: <7vk4xl5y3z.fsf@alter.siamese.dyndns.org>
Quoting Junio C Hamano <gitster@pobox.com>
> So here is what I did tonight.
>
> Step 0. Apply as you specified on top of 'next'
>
> $ git checkout next^0
> $ git am -s your-10-patches
> $ M=$(git describe)
>
> Step 1. Rebase back to the bottom of the old series
>
> $ git checkout next...jh/notes
What do three-dots mean in this command?
> $ git rebase --onto HEAD next $M
> $ N=$(git describe)
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: Ambiguous ref names
From: Junio C Hamano @ 2009-11-20 10:26 UTC (permalink / raw)
To: Jeenu V; +Cc: git
In-Reply-To: <5195c8760911200218v5b75d690hbaaf00b44c8df6af@mail.gmail.com>
Jeenu V <jeenuv@gmail.com> writes:
> If I've two branches a.b.c and a.b.c.d, why does 'git checkout'
> complains about ambiguous ref names?
Because it doesn't???
: demo; git init
Initialized empty Git repository in /var/tmp/gomi/twelve/.git/
: demo/master; >f
: demo/master; git add f
: demo/master; git commit -a -m 'initial'
[master (root-commit) cb1d5f2] initial
0 files changed, 0 insertions(+), 0 deletions(-)
create mode 100644 f
: demo/master; git branch a.b.c
: demo/master; git branch a.b.c.d
: demo/master; git checkout a.b.c
Switched to branch 'a.b.c'
It could be that you have a tag and a branch that are both named a.b.c,
though.
^ permalink raw reply
* Ambiguous ref names
From: Jeenu V @ 2009-11-20 10:18 UTC (permalink / raw)
To: git
Hi,
I'm re-posting this from the git-users Google Groups:
If I've two branches a.b.c and a.b.c.d, why does 'git checkout'
complains about ambiguous ref names? For example, if I'm in a.b.c.d,
896 $ git checkout a.b.c
warning: refname 'a.b.c' is ambiguous.
Switched to branch "a.b.c"
Is this some kind of a side effect of commit abbreviation? If so is
this kind of branch naming considered unsafe? Is there a way to make
git accept ref names verbatim, even if there's potential operation
that'd fail because of ambiguity?
--
:J
^ permalink raw reply
* Re: [RFC/PATCHv8 00/10] git notes
From: Johan Herland @ 2009-11-20 10:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce
In-Reply-To: <7vk4xl5y3z.fsf@alter.siamese.dyndns.org>
On Friday 20 November 2009, Junio C Hamano wrote:
> Johan Herland <johan@herland.net> writes:
> > Here is the 8th iteration of the git-notes series.
>
> Thanks.
>
> While I try my best not to break other people's patches while
> applying, I prefer to see a re-rolled series based on the same commit
> while replacing an existing series, unless the re-roll truly depends
> on the newer base, so that people can more easily see what got
> updated.
Ah, I see. I was thinking I should do the rebase to resolve any
conflicts before sending it to you, but I now see that - in the case
where there are no conflicts - the non-rebased version is actually
preferable. I will try to keep that in mind in the future.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: [RFC PATCH] {checkout,reset} -p: make patch direction configurable
From: Štěpán Němec @ 2009-11-20 10:08 UTC (permalink / raw)
To: Thomas Rast; +Cc: git, Junio C Hamano, Jeff King
In-Reply-To: <527e9296b638eb4c9993b3fb0d1c6f51b64f4c2c.1258667920.git.trast@student.ethz.ch>
Hello,
I bet it would get caught in the review process anyway, but just in
case -- a small typo:
> +With 'forward', diffs are taken forward and applied in reverse, i.e.,
> +if you added a block of code you see an addition patch and are asked
> +if you want to remove it. 'reverse' instead shows a removal patch
> +and asks if you to apply it. 'mixed' is the same as 'forward' when
Should be 'asks if you /want/ to apply it.'
Štěpán
^ permalink raw reply
* Re: [RFC] teamGIT bonjour support
From: Björn Steinbrink @ 2009-11-20 9:49 UTC (permalink / raw)
To: Petr Baudis; +Cc: Abhijit Bhopatkar, git, teamgit
In-Reply-To: <20091120091209.GN17748@machine.or.cz>
On 2009.11.20 10:12:09 +0100, Petr Baudis wrote:
> On Fri, Nov 20, 2009 at 10:05:30AM +0100, Petr Baudis wrote:
> > Hi!
> >
> > On Fri, Aug 28, 2009 at 12:32:39PM +0530, Abhijit Bhopatkar wrote:
> > > I plan to do this on LAN using bonjour service discovery
> >
> > I wonder why so much emphasis for this? It seems like a nifty
> > convenience bit, but I don't think making this idea too central is any
> > good. What if you get a second office at the other end of the world?
> > What if part of your team is working on a deployment at customer site?
> > What if part of your team works from home over a VPN? What if your
> > team is collaborating over the internet on an open project? What if...?
> >
> > That said, it sounds like a great idea to have let's say a post-commit
> > hook that will start an upload job:
> >
> > extbranch="$(whoami)/$(git symbolic-ref HEAD | sed 's#refs/heads/##')"
>
> Thanks to sitaram, now I know that probably the best way is:
>
> extbranch="$(whoami)/$(git describe --contains --all HEAD)"
>
> (But now you *really* need to check if HEAD is a heads ref first or you
> will push out to something totally bogus.)
Hm, I'd go for:
$(whoami)/$(git rev-parse --symbolic-full-name HEAD | sed s,refs/heads/,,)
gives the shortname of the checked out branch head, or HEAD when you're
on a detached HEAD.
Bjoern ;-)
^ permalink raw reply
* Re: [RFC/PATCHv8 00/10] git notes
From: Junio C Hamano @ 2009-11-20 9:44 UTC (permalink / raw)
To: Johan Herland; +Cc: git, spearce
In-Reply-To: <1258681154-2167-1-git-send-email-johan@herland.net>
Johan Herland <johan@herland.net> writes:
> Here is the 8th iteration of the git-notes series. Changes in this
> iteration are as follows:
>
> Changes to existing patches:
> - Rebased onto current 'next', dropping the early part of this series
> which has now been merged to 'next'.
> - Patch 8 (was patch 22): Major rewrite of fast-import's notes handling
> code based on comments from Shawn.
>
> New patches:
> - Patch 9: Rename t9301 to t9350, to make room for more fast-import tests
> - Patch 10: More fast-import tests
>
> TODO:
> - Builtin-ify git-notes shell script to take advantage of notes API
> - Garbage collect notes whose referenced object is unreachable (gc_notes())
> - Handle note objects that are not blobs, but trees
Thanks.
While I try my best not to break other people's patches while applying, I
prefer to see a re-rolled series based on the same commit while replacing
an existing series, unless the re-roll truly depends on the newer base, so
that people can more easily see what got updated.
So here is what I did tonight.
Step 0. Apply as you specified on top of 'next'
$ git checkout next^0
$ git am -s your-10-patches
$ M=$(git describe)
Step 1. Rebase back to the bottom of the old series
$ git checkout next...jh/notes
$ git rebase --onto HEAD next $M
$ N=$(git describe)
Step 2. Compare old and new series
$ git show-branch jh/notes HEAD
$ for i in 7 6 5 4 3 2 1 0
do
git diff jh/notes~$i HEAD~$(( $i + 2 ))
done
$ make -j test
Step 3. Make sure the result is what you intended to feed me.
$ git merge next
$ git diff $M
Step 4. Replace the tip of jh/notes
$ git branch -f jh/notes $N
^ permalink raw reply
* Re: [PATCH v4] git remote: Separate usage strings for subcommands
From: Junio C Hamano @ 2009-11-20 9:36 UTC (permalink / raw)
To: Tim Henigan; +Cc: Nanako Shiraishi, jrnieder, git
In-Reply-To: <32c343770911191058x7be7d34ascc3564064b880213@mail.gmail.com>
Tim Henigan <tim.henigan@gmail.com> writes:
> Using the 'add' subcommand as an example, the desired output is:
>
> Output of 'git remote -h':
> "git remote [-v | --verbose]"
> "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>"
> etc.
>
> Output of 'git remote add -h':
> "git remote add [<options>...] <name> <url>"
> followed by the detailed description given by 'parse_options()'.
>
> Text in 'man git-remote':
> "git remote add [-t <branch>] [-m <master>] [-f] [--mirror] <name> <url>"
> with the options explained in detail later in the file.
>
> Thanks for your patience,
I think the above looks good; thank _you_ for your patience.
I often wonder if we want to add to the parse-options library a function
that takes a "const struct option *" and some other unspecified hints, and
fills a strbuf with a one-line description, e.g.
"[-t <branch>] [-m <master>] [-f] [--mirror]"
I expect we would eventually want to handle something like (this example
is from "git push"):
"[--all | --mirror | --tags] [-n | --dry-run]"
and walking elements in a "struct option" one by one wouldn't give us
enough information to group all/mirror/tags in "one of these" brackets,
and that is what I mean by "some other unspecified hints". Obviously we
could do the "[-n|--dry-run]" with existing information.
A helper function like that may make things a bit easier. parse_options()
may need to take a custom callback function of some sort so that you can
override what parse_options_usage() does when responding to "remote -h"
and generate the list of subcommands and their options on the fly, though.
But that is all outside the scope of this particular patch.
^ permalink raw reply
* Re: [RFC] teamGIT bonjour support
From: Petr Baudis @ 2009-11-20 9:12 UTC (permalink / raw)
To: Abhijit Bhopatkar; +Cc: git, teamgit
In-Reply-To: <20091120090529.GM17748@machine.or.cz>
On Fri, Nov 20, 2009 at 10:05:30AM +0100, Petr Baudis wrote:
> Hi!
>
> On Fri, Aug 28, 2009 at 12:32:39PM +0530, Abhijit Bhopatkar wrote:
> > I plan to do this on LAN using bonjour service discovery
>
> I wonder why so much emphasis for this? It seems like a nifty
> convenience bit, but I don't think making this idea too central is any
> good. What if you get a second office at the other end of the world?
> What if part of your team is working on a deployment at customer site?
> What if part of your team works from home over a VPN? What if your
> team is collaborating over the internet on an open project? What if...?
>
> That said, it sounds like a great idea to have let's say a post-commit
> hook that will start an upload job:
>
> extbranch="$(whoami)/$(git symbolic-ref HEAD | sed 's#refs/heads/##')"
Thanks to sitaram, now I know that probably the best way is:
extbranch="$(whoami)/$(git describe --contains --all HEAD)"
(But now you *really* need to check if HEAD is a heads ref first or you
will push out to something totally bogus.)
P.S.: Heh, I would never guess what that git describe command already
does, talk about intuitiveness. ;-) (Of course, when you know exactly
what the switches do, it totally makes sense.)
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: [RFC] teamGIT bonjour support
From: Petr Baudis @ 2009-11-20 9:05 UTC (permalink / raw)
To: Abhijit Bhopatkar; +Cc: git, teamgit
In-Reply-To: <2fcfa6df0908280002y221a22e6md27db56865472144@mail.gmail.com>
Hi!
On Fri, Aug 28, 2009 at 12:32:39PM +0530, Abhijit Bhopatkar wrote:
> I plan to do this on LAN using bonjour service discovery
I wonder why so much emphasis for this? It seems like a nifty
convenience bit, but I don't think making this idea too central is any
good. What if you get a second office at the other end of the world?
What if part of your team is working on a deployment at customer site?
What if part of your team works from home over a VPN? What if your
team is collaborating over the internet on an open project? What if...?
That said, it sounds like a great idea to have let's say a post-commit
hook that will start an upload job:
extbranch="$(whoami)/$(git symbolic-ref HEAD | sed 's#refs/heads/##')"
pushurl="$(melting_pot)"
git push --force "$pushurl" "HEAD:$extbranch" >/dev/null &
(untested, +corner cases). On the server side, cronjob or post-update
hook can do the integration testing. The complete setup should be
a matter of few-minutes hack.
Now, it seems totally irrelevant if melting_pot is
melting_pot() { git config teamgit.meltingpot }
or extra code that tries/caches some local discovery first.
P.S.: It's not clear if you want the information sharing with commit
granularity or less - in that case, things might get rather tricky e.g.
if you add new files and don't git add them until right before you
commit, and the work tree state might be total mess anyway.
P.P.S.: It's not clear if you strive after complete de-centralization of
the service, with no central melting pot. That would seem fancy, but
I think rather useless and hard in practice to arrange your reports
that you want, etc. It's not clear again then if the integration testing
should happen on single machine they all vote on (samba-like), or if
all machines should do integration-testing, and whether of all branches
or only some of them, and how to recognize the interesting branches, and
things are getting very hairy already... Your requirements are too
ambiguous.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: Default history simplification
From: Jan Krüger @ 2009-11-20 8:55 UTC (permalink / raw)
To: Tommy Wang; +Cc: git
In-Reply-To: <ae09c2a40911191530y626dd035q90de0212e0b4b6d8@mail.gmail.com>
Hi,
Tommy Wang <subscription@august8.net> wrote:
> [...] I would love to simply use the rev-list built-in to
> do my work for me; but I fear that I may have much too many path
> limiters than the linux command-line can handle (which if I'm correct,
> can only take so many arguments).
On my system, "only so many arguments" means about two megabytes worth
of command line. On several operating systems, "getconf ARG_MAX" can
tell you the approximate limit (which I think includes the space for
environment variables).
I don't really have any comments about the other things you said.
Jan
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Intland Software @ 2009-11-20 8:24 UTC (permalink / raw)
To: Petr Baudis; +Cc: Sitaram Chamarty, git
In-Reply-To: <20091120074702.GW12890@machine.or.cz>
Petr Baudis wrote:
> Looks like this suddenly is a very popular area. High competition is good!
Absolutely agreed!
---
Intland
^ permalink raw reply
* Re: [PATCH] submodule.c: Squelch a "use before assignment" warning
From: Junio C Hamano @ 2009-11-20 8:05 UTC (permalink / raw)
To: David Aguilar; +Cc: gitster, git
In-Reply-To: <1258680785-42235-1-git-send-email-davvid@gmail.com>
David Aguilar <davvid@gmail.com> writes:
> i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5493) compiler
> (and probably others) mistakenly thinks variable 'right' is used
> before assigned. Work it around by giving it a fake initialization.
We see the same "fake initialization" of 'left' on the same line. By
initializing it to NULL, you are hinting that initializing 'right' to
NULL actually means something.
> diff --git a/submodule.c b/submodule.c
> index 461faf0..0145a62 100644
> --- a/submodule.c
> +++ b/submodule.c
> @@ -38,7 +38,7 @@ void show_submodule_summary(FILE *f, const char *path,
> const char *del, const char *add, const char *reset)
> {
> struct rev_info rev;
> - struct commit *commit, *left = left, *right;
> + struct commit *commit, *left = left, *right = NULL;
^ permalink raw reply
* Re: [PATCH 2/2] t/lib-http.sh: Enable httpd tests by default.
From: Junio C Hamano @ 2009-11-20 8:03 UTC (permalink / raw)
To: Tarmigan Casebolt; +Cc: git, peff, jaysoffian, drizzd, gitster, spearce
In-Reply-To: <1258680123-28684-2-git-send-email-tarmigan+git@gmail.com>
Tarmigan Casebolt <tarmigan+git@gmail.com> writes:
> With smart http, git over http is likely to become much more common.
> To increase testing of smart http, enable the http tests by default.
Sorry, but no test that listens to network ports should be enabled by
default; otherwise it will break automated, unattended tests people have
already set up randomly, depending on when the port happens to be
available for use by the tests.
^ permalink raw reply
* Re: [PATCH] gitk: Use git-difftool for external diffs
From: Junio C Hamano @ 2009-11-20 7:53 UTC (permalink / raw)
To: Paul Mackerras; +Cc: David Aguilar, peff, sam, git
In-Reply-To: <19205.50406.91209.309984@cargo.ozlabs.ibm.com>
Paul Mackerras <paulus@samba.org> writes:
> I have no problem with using git difftool if the underlying git is new
> enough, I just don't want gitk to explode when it isn't.
I somehow doubt there are many users who use pre 1.6.3 git but keep their
gitk separately updated to very recent version, so personally I wouldn't
worry too much about this.
> Also, I don't think we should remove the ability for the user to
> choose which external diff tool to use.
This is a larger concern. Does "difftool" allow use of an arbitrary tool
like how gitk does (I have a suspicion that it is not as flexible)?
^ permalink raw reply
* Re: [PATCH] git-count-objects: Fix a disk-space under-estimate on Cygwin
From: Junio C Hamano @ 2009-11-20 7:49 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <7vd43d8yva.fsf@alter.siamese.dyndns.org>
When estimating the on-disk footprint of a file, we either used st_blocks
that is counted in 512-byte blocks (traditional unix behaviour), or on
platforms that do not have such st_blocks field in struct stat, simply the
file size itself. Building with NO_ST_BLOCKS_IN_STRUCT_STAT will choose
the latter implementaion.
POSIX.1 says in its <sys/stat.h> description on this issue:
The unit for the st_blocks member of the stat structure is not
defined within POSIX.1-2008. In some implementations it is 512
bytes. It may differ on a file system basis. There is no
correlation between values of the st_blocks and st_blksize,
and the f_bsize (from <sys/statvfs.h>) structure members.
Even though the above explicitly states st_blksize does not have any
correlation, at least on one system (Cygwin on NTFS), the st_blocks field
seems to count in blocks of st_blksize bytes. A new Makefile variable
ST_BLOCKS_COUNTS_IN_BLKSIZE chooses to use this for the on-disk footprint.
---
Not signed-off yet, but this might be a workable alternative. Testing on
wider platforms (especially not on "Linux with ext?") might find this
alternative useful. I dunno.
Makefile | 8 +++++++-
git-compat-util.h | 4 +++-
2 files changed, 10 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 79195c8..5f2c5de 100644
--- a/Makefile
+++ b/Makefile
@@ -148,6 +148,9 @@ all::
# Define USE_STDEV below if you want git to care about the underlying device
# change being considered an inode change from the update-index perspective.
#
+# Define ST_BLOCKS_COUNTS_IN_ST_BLKSIZE if your platform has st_blocks
+# field that counts the on-disk footprint in st_blksize-byte blocks.
+#
# Define NO_ST_BLOCKS_IN_STRUCT_STAT if your platform does not have st_blocks
# field that counts the on-disk footprint in 512-byte blocks.
#
@@ -776,7 +779,7 @@ ifeq ($(uname_O),Cygwin)
NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes
NO_TRUSTABLE_FILEMODE = UnfortunatelyYes
OLD_ICONV = UnfortunatelyYes
- NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
+ ST_BLOCKS_COUNTS_IN_ST_BLKSIZE = YesPlease
# There are conflicting reports about this.
# On some boxes NO_MMAP is needed, and not so elsewhere.
# Try commenting this out if you suspect MMAP is more efficient
@@ -1126,6 +1129,9 @@ endif
ifdef NO_D_INO_IN_DIRENT
BASIC_CFLAGS += -DNO_D_INO_IN_DIRENT
endif
+ifdef ST_BLOCKS_COUNTS_IN_ST_BLKSIZE
+ BASIC_CFLAGS += -DST_BLOCKS_COUNTS_IN_ST_BLKSIZE
+endif
ifdef NO_ST_BLOCKS_IN_STRUCT_STAT
BASIC_CFLAGS += -DNO_ST_BLOCKS_IN_STRUCT_STAT
endif
diff --git a/git-compat-util.h b/git-compat-util.h
index ef60803..bba9c9e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -240,7 +240,9 @@ extern int git_munmap(void *start, size_t length);
#endif /* NO_MMAP */
-#ifdef NO_ST_BLOCKS_IN_STRUCT_STAT
+#ifdef ST_BLOCKS_COUNTS_IN_ST_BLKSIZE
+#define on_disk_bytes(st) ((st).st_blocks * (st).st_blksize)
+#elif defined(NO_ST_BLOCKS_IN_STRUCT_STAT) && NO_ST_BLOCKS_IN_STRUCT_STAT
#define on_disk_bytes(st) ((st).st_size)
#else
#define on_disk_bytes(st) ((st).st_blocks * 512)
^ permalink raw reply related
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Petr Baudis @ 2009-11-20 7:47 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Intland Software, git
In-Reply-To: <2e24e5b90911192056t706071ble163a53741017ef@mail.gmail.com>
Hi!
On Fri, Nov 20, 2009 at 10:26:32AM +0530, Sitaram Chamarty wrote:
> On Thu, Nov 19, 2009 at 7:20 PM, Intland Software <marketing@intland.com> wrote:
> > * MR against Gitolite
> > Pretty much the same applies here as well.
>
> Conceptually, gitolite can do the roles stuff you mentioned,
> if I understood it correctly. Of course, gitolite's access
> config is in plain text.
>
> The web-based control, issue tracking, etc., are all on a
> different plane from what gitosis/gitolite aim to be. So
> much so that I might even disagree with Pasky on the need to
> mention these two products in your website.
I brought Gitosis/Gitolite up because I got the impression that MR was
marketed primarily as a Git ACL tool, the other things being sort of
mirror; maybe my impession was wrong, but I still think the comparison
in ACL capabilities is useful.
> You should stick to gitorious, github, and -- here's a new
> one for you -- indefero.
Hmm, I didn't even know about this one, thanks for the pointer. Looks
like this suddenly is a very popular area. High competition is good!
(BTW, if you don't care about wikis and issue tracking, but you do care
about simplicity and light-weightness, you should best stick to Girocco!
;-)
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: [PATCH 2/2] diffcore-break: save cnt_data for other phases
From: Junio C Hamano @ 2009-11-20 7:32 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091119152234.GA6877@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> I don't know if it is worth refactoring though.
I would rather not touch it.
> Also, I don't see where we ever actually free the cnt_data. After we run
> the whole O(n^2) loop, we should be able to drop cnt_data entirely. I
> think in practice it doesn't matter all that much, since it isn't that
> big, and afterwards we just generate the patch and exit (unless we are
> doing diffcore-break, too, which will actually free all of the data).
Originally, each phase of the diffcore pipeline was designed to be
independent from other phases, and keeping things in core was done as an
optimization for smallish trees so that later phases in the diffcore
pipeline can reuse prepopulated data. If this were year 2006, I would
have said that keeping it in core would be better because we could add new
phases after it later, even though there is nobody who uses cnt_data after
diffcore-rename in the diffcore pipeline right now,
But it seems that our performance is more than adequate without such
keeping-things-around for smallish trees anyway, and it is wiser to
optimize for heavier workload. More importantly, nobody seems to be
planning new phases in the pipeline, so I agree it is a good idea to drop
cnt_data once the rename detection phase is done with it.
^ permalink raw reply
* Re: [PATCH] git-count-objects: Fix a disk-space under-estimate on Cygwin
From: Junio C Hamano @ 2009-11-20 7:00 UTC (permalink / raw)
To: Ramsay Jones; +Cc: GIT Mailing-list
In-Reply-To: <4B059280.40902@ramsay1.demon.co.uk>
Ramsay Jones <ramsay@ramsay1.demon.co.uk> writes:
> Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
> ---
Could you write a concise summary in the commit log message to explain why
it is a correct fix? Your detailed analysis after three dash lines was an
amusing read, but people who will be reading "git log" output 6 months
down the road won't have an access to it. Something like...
Cygwin has st_blocks in struct stat, but at least on NTFS, the field
counts in blocks of st_blksize bytes, not in 512-byte blocks.
The Makefile already explains what NO_ST_BLOCKS_IN_STRUCT_STAT is about:
# Define NO_ST_BLOCKS_IN_STRUCT_STAT if your platform does not have st_blocks
# field that counts the on-disk footprint in 512-byte blocks.
so the above explanation should be enough.
Note that this is not any standard compliance. POSIX cops out like this
in the <sys/stat.h> description:
The unit for the st_blocks member of the stat structure is not defined
within POSIX.1-2008. In some implementations it is 512 bytes. It may
differ on a file system basis. There is no correlation between values
of the st_blocks and st_blksize, and the f_bsize (from
<sys/statvfs.h>) structure members.
IOW, a system like Cygwin that does not use 512-byte is not in violation.
> diff --git a/Makefile b/Makefile
> index 5d5976f..5624563 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -783,6 +783,10 @@ ifeq ($(uname_O),Cygwin)
> NO_FAST_WORKING_DIRECTORY = UnfortunatelyYes
> NO_TRUSTABLE_FILEMODE = UnfortunatelyYes
> OLD_ICONV = UnfortunatelyYes
> + # The st_blocks field is not in units of 512 bytes, as the code
> + # expects, which leads to an under-estimate of the disk space used.
> + # In order to use an alternate algorithm, we claim to lack st_blocks.
> + NO_ST_BLOCKS_IN_STRUCT_STAT = YesPlease
This comment is redundant, as the explanation of the Makefile variable
already said the same thing.
Also it is somewhat wrong to say "claim to lack". The Makefile variable
merely means "do not use this field". The reason may be that the platform
lacks it, or it may have it but it does not count in 512-byte blocks. It
does not matter---either way the field is not usable.
^ permalink raw reply
* Re: Hey - A Conceptual Simplication....
From: Junio C Hamano @ 2009-11-20 6:33 UTC (permalink / raw)
To: Dmitry Potapov; +Cc: George Dennie, 'Jan Krüger', git
In-Reply-To: <20091120013545.GA22556@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov@gmail.com> writes:
> It is more difficult to make this mistake with Git than many others
> VCSes, because Git shows the list of files that are changed but not
> committed as well as the list of untracked files when you try to commit
> something.
Not really in practice. Too many people carry their existing practice of
using -m to write a useless single liner commit log message that they
acquired while using their previous SCM. Arguably, useless log messages
are less of a problem on systems like CVS/SVN because they do not do
useful log summarization such as "log -- paths..." or "shortlog", so they
can be excused for learning the practice in the first place, though.
That incidentally is exactly why earlier we (mostly me and Linus)
recommended people not to teach "commit -m" to new people, but of course
nobody listened ;-).
^ permalink raw reply
* Re: Hey - A Conceptual Simplication....
From: Junio C Hamano @ 2009-11-20 6:27 UTC (permalink / raw)
To: Jakub Narebski
Cc: George Dennie, git, B.Steinbrink, 'Jason Sewall',
'Jan Krüger', torvalds
In-Reply-To: <200911200149.19528.jnareb@gmail.com>
Jakub Narebski <jnareb@gmail.com> writes:
> If you didn't find sufficient description of underlying concepts behind
> git in "Git User's Manual" (distributed with Git), "Git Community Book"
> or "Pro Git", take a look at the following documents:
>
> * "Git for Computer Scientists"
> * "Git From Bottom's Up"
> * "The Git Parable"
> ...
> It is documented, see referenced mentioned above.
I actually would want ourselves step back a bit and make sure that anybody
who is completely new to git won't get confused with the concepts after
s/he reads our "Git User's Manual" and nothing else. Listing five or six
documents and "you'll find information somewhere among these" *might* be
the best thing we could do at this very second, but we should strive to do
better than that.
^ permalink raw reply
* Re: [ANNOUNCE] codeBeamer MR - Easy ACL for Git
From: Sitaram Chamarty @ 2009-11-20 4:56 UTC (permalink / raw)
To: Intland Software; +Cc: Petr Baudis, git
In-Reply-To: <4B054D0A.5030802@intland.com>
On Thu, Nov 19, 2009 at 7:20 PM, Intland Software <marketing@intland.com> wrote:
> Petr Baudis wrote:
>>
>> I think a lot of people wonder now, how does this compare to existing
>> solutions; from your announcement I thought it's something like
>> Gitosis/Gitolite, but in fact it seems more similar to Gitorious or
>> GitHub (if it was publicly available, of course); perhaps it would be
>
> All right, some quick comparisons with codeBeamer Managed Repository (MR).
>
> * MR against Gitosis
I think you meant "versus" :-)
> In terms of access control, MR has the concept of "role", and it makes our
> security model more fine grained. Permissions can be set by role. One user
> account can have multiple roles. Roles are project-dependent. When you add a
> group to a project, you can assign multiple roles to the group (which is
> equivalent with assigning those roles to each group member one by one).
> On the other hand, MR has a much broader scope than Gitosis. MR helps you to
> manage your repos, to track your tasks/bugs/issues, to follow commit
> activities, to browse repos in the web, can be extended using its APIs, etc.
> (And you don't have to install and maintain Git extensions for this.)
> * MR against Gitolite
> Pretty much the same applies here as well.
Conceptually, gitolite can do the roles stuff you mentioned,
if I understood it correctly. Of course, gitolite's access
config is in plain text.
The web-based control, issue tracking, etc., are all on a
different plane from what gitosis/gitolite aim to be. So
much so that I might even disagree with Pasky on the need to
mention these two products in your website. Here's one
perspective (in round figures):
gitolite: 1600 lines of shell+perl, 1600 lines of doc
gitosis: 3300 lines of python
MR: 150 MB binary download
I don't honestly see any way to even *begin* to compare :-)
You should stick to gitorious, github, and -- here's a new
one for you -- indefero.
--
Sitaram
^ permalink raw reply
* Re: [spf:guess] Re: git-svn not fetching all revisions
From: Sam Vilain @ 2009-11-20 4:12 UTC (permalink / raw)
To: Marcus Better; +Cc: git
In-Reply-To: <4B0534FF.5040001@better.se>
Marcus Better wrote:
> Ok, that works, but how can I now sync with the svn repository with git
> svn rebase/dcommit? I think the filter-branch rewriting confuses git-svn.
>
A quick hint: git-svn only relies on the last piece of metadata it can
see in 'git log'; so make sure that one looks right and you should be
fine...
Sam
^ 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