* git vs hg commit counts?
From: Joe Perches @ 2009-10-27 0:08 UTC (permalink / raw)
To: LKML; +Cc: git, mercurial, Marti Raudsepp
I'm comparing linux-kernel git vs hg repositories.
While testing some changes to scripts/get_maintainer.pl,
I noticed that git and hg have different commit counts
for the same files.
For instance:
$ git log --since=1-year-ago -- MAINTAINERS | \
grep -P "^commit [0-9a-f]{40,40}$" | wc -l
514
$ hg log --template="commit {node}\n" --date -365 -- MAINTAINERS | \
grep -P "^commit [0-9a-f]{40,40}$" | wc -l
601
Anyone have any understanding why?
^ permalink raw reply
* Re: gti push interface inconsistency
From: Junio C Hamano @ 2009-10-27 0:08 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910261523s51ac22b5y624ec3502e8fed67@mail.gmail.com>
Eugene Sajine <euguess@gmail.com> writes:
> I have a question:
>
> Why I can't do
>
> $ git push my_tag
>
> It will fail because the remote is not specified, even if there is
> only one origin remote
Probably because git is not smart enough to understand the human language
to notice 't' 'a' 'g' is a tag and cannot be a remote name spelled
incorrectly, or git cannot read your mind and find out that you spelled
a name of the remote correctly but forgot to add the remote first.
^ permalink raw reply
* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Junio C Hamano @ 2009-10-26 23:59 UTC (permalink / raw)
To: Stephen Boyd
Cc: Shawn O. Pearce, Junio C Hamano, git, Clemens Buchacher,
Sverre Rabbelier
In-Reply-To: <1256589116-6998-3-git-send-email-bebarino@gmail.com>
Stephen Boyd <bebarino@gmail.com> writes:
> Some users don't want to compile their completion, even when the build
> generated completion is 10x faster to load. For example, in my bashrc I
> source the completion script directly so I can stay up to date with the
> latest completion by merely pulling changes.
>
> Do this by generating the lists dynamically when the merge strategy and
> command lists still have their initial values (__GIT_MERGE_STRATEGYLIST,
> __GIT_ALL_COMMANDLIST).
>
> Signed-off-by: Stephen Boyd <bebarino@gmail.com>
> ---
>
> This duplicates code, but I don't know of a way to re-use the dynamic
> code without sourcing a bash script and possibly breaking someone's build.
If we are going to do this, wouldn't it make more sense to revert the
rename of the script, so that people can keep relying on the name of the
script being "git-completion.bash", _but_ make it produce a pre-compiled
form to a separate file when invoked in some particular way?
Then at the runtime:
(0) If the script notices that it has already learned the command list
it uses it; otherwise,
(1) If the script notices that there is a file that contains the command
list, it sources it; otherwise,
(2) The script lazily builds the command list for its own use.
And at the buildtime, Makefile can run the script in "generation mode",
and install the output to where (1) above expects to see.
^ permalink raw reply
* Re: [PATCH] gitk: Add Japanese translation
From: Junio C Hamano @ 2009-10-26 23:59 UTC (permalink / raw)
To: Mizar; +Cc: git
In-Reply-To: <d092a4360910260649l9a13e5ep9387b4f8feb9a22c@mail.gmail.com>
Mizar <mizar.jp@gmail.com> writes:
> I tried to Japanese translation of gitk. Attached to its translation.
> Some messages are not translated yet.
> And, you may find some strange translations.
> People have a better idea of Japanese translation, please let us know.
Wow, thanks.
Having an empty msgstr "" for yet-to-be-translated entries is slightly
misleading. People who work on PO files can spot them, but those who try
your wip translation files cannot spot them in the UI.
I am not sure if I am happy with the word used as the translation of
"reference".
Comments on just a few items I noticed (I didn't read everything that
deeply, though).
> +#: gitk:2099 gitk:2101
> +msgid "Exact"
> +msgstr "A-Z/a-zを区別"
git-gui seems to say "大文字小文字を区別" for this.
> +
> +#: gitk:2101 gitk:4447 gitk:6248
> +msgid "IgnCase"
> +msgstr "A-Z/a-zを区別しない"
Similar...
> +#: gitk:2397
> +msgid "Blame parent commit"
> +msgstr ""
Perhaps 「親コミットから blame をかける」
> +#: gitk:2404
> +msgid "Show origin of this line"
> +msgstr ""
Perhaps「この行の出自を表示する」
> +#: gitk:2405
> +msgid "Run git gui blame on this line"
> +msgstr ""
Perhaps「この行に git gui で blame をかける」
> +#: gitk:11137
> +msgid "Cannot find a git repository here."
> +msgstr "ここでgitリポジトリを見つけられません。"
「ここにはリポジトリがありません」。
> +#: gitk:11285
> +msgid "Command line"
> +msgstr "コマンドライン"
「コマンド行」would be equally common and shorter.
^ permalink raw reply
* Re: git push interface inconsistency
From: Eugene Sajine @ 2009-10-26 23:39 UTC (permalink / raw)
To: Avery Pennarun; +Cc: git
In-Reply-To: <32541b130910261531o36b8ce7eh6bddf26a2ae15663@mail.gmail.com>
Got it.
Thanks!
On Mon, Oct 26, 2009 at 6:31 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> On Mon, Oct 26, 2009 at 6:25 PM, Eugene Sajine <euguess@gmail.com> wrote:
>> I have a question:
>>
>> Why I can't do
>>
>> $ git push my_tag
>>
>> It will fail because the remote is not specified, even if there is
>> only one origin remote
>>
>> but can do
>>
>> $ git push --tags
>>
>> and it will push tags to origin...
>
> Because 'my_tag' is interpreted as the name or URL of the remote, not
> as a branch name. You can do "git push origin" and it will guess the
> branch name(s) to push, but because of that, the one-parameter push
> can't *also* be used to guess the remote name.
>
> In contrast, --tags is a flag, so it's actually the zero-parameter
> version of push, which assumes 'origin' and then guesses the branch
> name (and --tags changes the guessed result).
>
> Hope that helps.
>
> Have fun,
>
> Avery
>
^ permalink raw reply
* Re: [PATCH] push: support remote branches in guess_ref DWIM
From: Junio C Hamano @ 2009-10-26 23:31 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091026213353.GA27871@sigio.peff.net>
Jeff King <peff@peff.net> writes:
> When we get an unqualified dest refspec like "foo", we try
> to guess its full ref path (like "refs/heads/foo") based on
> the source ref. Commit f8aae12 mapped local heads to remote
> heads, and local tags to remote tags.
>
> This commit maps local tracking branches under
> "refs/remotes" to remote branch heads, so
>
> git push origin origin/branch:renamed-branch
>
> pushes to refs/heads/renamed-branch.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> This came from a discussion on IRC. I don't see any reason not to do
> this; would people really expect it to push into refs/remotes/ on the
> other side (right now, it complains and dies)?
As _our_ origin can never be _their_ origin if we are clone of them, I do
not think anybody sane would expect it to push into refs/remotes/origin/
to begin with.
But "not in refs/remotes/" does not automatically mean "the only sensible
place is refs/heads", does it? "We do not know what kind of mistake the
user is trying to make" could be more plausible answer, and in that case,
"complain and die" may be a more valid course of action.
For example,
git push origin origin/master:refs/heads/master
is most likely to be a mistake. The only situation something similar to
this makes sense is where you pushed out a bogus commit earlier and are
trying to correct it perhaps with
git push origin +origin/master@{1}:refs/heads/master
but you need to force it and go back in the reflog.
I know you are doing this DWIM only when $dst does not exist over there,
and the "pushing old master back to master" above is a different scenario,
but if "git push origin origin/master:master" shouldn't update their local
master, "git push origin origin/master:naster" shouldn't update their
local naster, in order to avoid confusion arising from inconsistency, no?
Another possibility is to see the type (not refname) of $src and push all
commits to refs/heads/$dst and everything else (most likely tags) to
refs/tags/$dst, to simplify the rule to make it easier to explain and
remember, but there are lightweight tags that make this idea unworkable.
> A related issue (which exists even without this patch) is that doing
> this:
>
> master:remotes/incoming/master
>
> will create "refs/heads/remotes/incoming/master". Perhaps we should DWYM
> a little more and recognize "heads", "remotes", and "tags" as special.
Yes, it is an independent issue; I think correcting this DWIM (or at least
"warning" if not refusing to create remotes/ under refs/heads/) might be a
good idea.
^ permalink raw reply
* [PATCH v2 3/2] remote: fix poential ref_map list corruption in ref_remove_duplicates
From: Julian Phillips @ 2009-10-26 23:12 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, git
In-Reply-To: <20091025212813.48498.51868.julian@quantumfyre.co.uk>
The prev pointer was not being updated when the peer_ref member
pointer was NULL, which means that that any items in the list with a
NULL peer_ref immediately preceeding a duplicate would be dropped
without being freed.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk>
---
Having fixed the access after free bug, I realised that there was
still a problem. This one didn't show up in the tests - due to the
rather specific circumstances required, but may occur in real use.
remote.c | 3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/remote.c b/remote.c
index 1380b20..4f9f0cc 100644
--- a/remote.c
+++ b/remote.c
@@ -738,7 +738,7 @@ void ref_remove_duplicates(struct ref *ref_map)
struct string_list refs = { NULL, 0, 0, 0 };
struct string_list_item *item = NULL;
struct ref *prev = NULL, *next = NULL;
- for (; ref_map; ref_map = next) {
+ for (; ref_map; prev = ref_map, ref_map = next) {
next = ref_map->next;
if (!ref_map->peer_ref)
continue;
@@ -758,7 +758,6 @@ void ref_remove_duplicates(struct ref *ref_map)
item = string_list_insert(ref_map->peer_ref->name, &refs);
item->util = ref_map;
- prev = ref_map;
}
string_list_clear(&refs, 0);
}
--
1.6.5.rc2
^ permalink raw reply related
* Re: git push interface inconsistency
From: Avery Pennarun @ 2009-10-26 22:31 UTC (permalink / raw)
To: Eugene Sajine; +Cc: git
In-Reply-To: <76c5b8580910261525y5397b54eyf9c3d58c0fe19fce@mail.gmail.com>
On Mon, Oct 26, 2009 at 6:25 PM, Eugene Sajine <euguess@gmail.com> wrote:
> I have a question:
>
> Why I can't do
>
> $ git push my_tag
>
> It will fail because the remote is not specified, even if there is
> only one origin remote
>
> but can do
>
> $ git push --tags
>
> and it will push tags to origin...
Because 'my_tag' is interpreted as the name or URL of the remote, not
as a branch name. You can do "git push origin" and it will guess the
branch name(s) to push, but because of that, the one-parameter push
can't *also* be used to guess the remote name.
In contrast, --tags is a flag, so it's actually the zero-parameter
version of push, which assumes 'origin' and then guesses the branch
name (and --tags changes the guessed result).
Hope that helps.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Avery Pennarun @ 2009-10-26 22:28 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, David Roundy, Junio C Hamano,
Nanako Shiraishi, Alex Riesen, git, Jay Soffian
In-Reply-To: <20091026221424.GA28184@sigio.peff.net>
On Mon, Oct 26, 2009 at 6:14 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 26, 2009 at 06:01:29PM -0400, Avery Pennarun wrote:
>> > It's git-update-ref.
>>
>> That would be similar to git commit, not git checkout, right? Oh
>> wait, I see the confusion: git checkout does two things. It switches
>> branches, and it checks out files from the index into the work tree.
>> I meant the latter meaning.
>
> Er, sorry, yes. It should be "git symbolic-ref", of course, to change
> HEAD, and then probably read-tree and checkout-index. I was just not
> thinking when I wrote the other message (hopefully I am doing so now).
Wow, I've browsed through the git manpages repeatedly and never found
checkout-index. It was exactly the missing building block I was
looking for. Thanks!
>> > Consider "git commit", for example. Does anyone
>> > actually script around "write-tree" and "commit-tree" these days, or do
>> > they just script around "git commit"?
>>
>> Oh, I use those all the time. They're awesome! It allows you to
>> create commits without having a working tree, which lets me do very
>> interesting tricks. git-subtree uses this heavily.
>>
>> I'm probably a weirdo, though.
>
> OK, I should have phrased my statement differently (see, I told you I
> wasn't thinking). Yes, there are reasons to script around low-level
> building blocks, when you don't want the assumptions associated with the
> higher level. But I'm sure there are tons of scripts that munge some
> files in a worktree, followed by "git add -A; git commit -m 'automagic
> update'". And in that case, nobody would script around "commit-tree"
> because it's a lot more work.
Unfortunately this is pretty tricky to get perfect; perhaps there's no
way to do it.
In git-subtree, for example, I *mostly* use write-tree and
commit-tree, but when I do the final merge operation (to take the
synthetic history and merge it into your "real" history) I use commit.
This is because I wanted the default merge handling, commit message,
etc for that part. Unfortunately, it's possible that this dragged in
a bunch of stuff I *didn't* want. It also makes git-subtree, which
otherwise could be used as plumbing, effectively into a porcelain.
I don't really know what to do about that. You could introduce an
abstraction level somewhere between commit-tree and commit, but surely
someone would eventually find a case where that abstraction level is
still not right. To bring this around to the original topic of this
thread, such an extra level of abstraction is equivalent to the
suggested --plumbing (or whatever) option, whether it's presented as
an option or a separate command.
Have fun,
Avery
^ permalink raw reply
* git push interface inconsistency
From: Eugene Sajine @ 2009-10-26 22:25 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
Hi,
I have a question:
Why I can't do
$ git push my_tag
It will fail because the remote is not specified, even if there is
only one origin remote
but can do
$ git push --tags
and it will push tags to origin...
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH ef/msys-imap] mingw: use BLK_SHA1 again
From: Johannes Schindelin @ 2009-10-26 22:26 UTC (permalink / raw)
To: Johannes Sixt
Cc: msysgit, git, Erik Faye-Lund, Junio C Hamano, Marius Storm-Olsen
In-Reply-To: <200910222026.29885.j6t@kdbg.org>
Hi,
On Thu, 22 Oct 2009, Johannes Sixt wrote:
> Since NO_OPENSSL is no longer defined on Windows, BLK_SHA1 is not defined
> anymore implicitly. Define it explicitly.
>
> As a nice side-effect, we no longer link against libcrypto.dll, which has
> non-trivial startup costs because it depends on 6 otherwise unneeded
> DLLs.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> On Donnerstag, 22. Oktober 2009, Johannes Sixt wrote:
> > ... and I have one more patch to be applied on top of the series.
>
> Here it is. I haven't tested the MSVC aspect of the patch. I would
> appreciate feedback in this regard.
For better visibility, I pushed it to the work/msys-imap branch in
4msysgit.git (but I could not even compile-test it today, due to lack of
access to a Windows machine).
If nobody complains by the end of the week, I will merge it into
4msysgit.git's 'devel' branch (I can only compile-test by then).
Ciao,
Dscho
^ permalink raw reply
* gti push interface inconsistency
From: Eugene Sajine @ 2009-10-26 22:23 UTC (permalink / raw)
To: git
Hi,
I have a question:
Why I can't do
$ git push my_tag
It will fail because the remote is not specified, even if there is
only one origin remote
but can do
$ git push --tags
and it will push tags to origin...
Thanks,
Eugene
^ permalink raw reply
* Re: [PATCH] Proof-of-concept patch to remember what the detached HEAD was
From: Johannes Schindelin @ 2009-10-26 22:22 UTC (permalink / raw)
To: Sean Estabrooks
Cc: Nicolas Pitre, Jeff King, Junio C Hamano, Daniel Barkalow,
Jay Soffian, git
In-Reply-To: <BLU0-SMTP840FB343954FC20ACA699CAEC30@phx.gbl>
Hi,
On Sat, 17 Oct 2009, Sean Estabrooks wrote:
> On Fri, 16 Oct 2009 04:07:23 +0200 (CEST)
> Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> > Just recently, I had a user request (a very valid one, mind you) where
> > the user does not want to provide a commit message, and wants to just
> > commit all the current changes. In that particular case, it is very
> > sensible to ask for these things. It is something utterly simple to
> > ask for. Yet, it is utterly hard with Git, especially if I have to
> > explain it.
>
> Hey Johannes,
>
> It's actually easy, but maybe hard to find:
>
> $ git commit --cleanup=verbatim -m ""
Of course that leaves out the main part. But it is simple once you
know it (I did not): git add -A (we even went out of our way _not_ to name
the long option --addremove, but --all -- it does not seem to be an
expressive-enough option name to me, but what does my impression
matter...)
So I retract my claim that it is utterly hard to do with Git (but not the
rest).
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Jeff King @ 2009-10-26 22:14 UTC (permalink / raw)
To: Avery Pennarun
Cc: Johannes Schindelin, David Roundy, Junio C Hamano,
Nanako Shiraishi, Alex Riesen, git, Jay Soffian
In-Reply-To: <32541b130910261501n32046cc5s12283a8e3981d04e@mail.gmail.com>
On Mon, Oct 26, 2009 at 06:01:29PM -0400, Avery Pennarun wrote:
> > It's git-update-ref.
>
> That would be similar to git commit, not git checkout, right? Oh
> wait, I see the confusion: git checkout does two things. It switches
> branches, and it checks out files from the index into the work tree.
> I meant the latter meaning.
Er, sorry, yes. It should be "git symbolic-ref", of course, to change
HEAD, and then probably read-tree and checkout-index. I was just not
thinking when I wrote the other message (hopefully I am doing so now).
> > Consider "git commit", for example. Does anyone
> > actually script around "write-tree" and "commit-tree" these days, or do
> > they just script around "git commit"?
>
> Oh, I use those all the time. They're awesome! It allows you to
> create commits without having a working tree, which lets me do very
> interesting tricks. git-subtree uses this heavily.
>
> I'm probably a weirdo, though.
OK, I should have phrased my statement differently (see, I told you I
wasn't thinking). Yes, there are reasons to script around low-level
building blocks, when you don't want the assumptions associated with the
higher level. But I'm sure there are tons of scripts that munge some
files in a worktree, followed by "git add -A; git commit -m 'automagic
update'". And in that case, nobody would script around "commit-tree"
because it's a lot more work.
-Peff
^ permalink raw reply
* git update --prune issue
From: Jeffrey Middleton @ 2009-10-26 22:08 UTC (permalink / raw)
To: git
I have an unreliable problem when using "git remote update --prune".
git claims that many refs from a particular remote do not point to a
valid object, but only after finishing another update. I've included
a shortened version of the output from one particular instance of the
issue. Note that the errors are printed for every subsequent remote
as well. However, after the update is completed, everything is fine.
It seems to only happen when there are non-fast-forward changes (new
branch, forced update, pruned branch). The issue only happens with
this particular remote, which I've tried removing and recreating, and
is the same type of remote as all my others (another user's
NFS-mounted home directory). However, my remotes are all individual
developers, and this developer is the only one who ever rebases her
working branches. (recloning the repo from origin and setting up my
config and remotes all over again has also had no effect)
Unfortunately, I have been unable to reproduce the problem in any test
repos - for example, though a forced update and a pruned branch in the
problematic remote along with an update in another remote seems to
fairly reliably produce the problem in this repo, recreating that
situation in another repo doesn't cause any problems. Sorry for the
incomplete bug report, but perhaps this will be enough to go on!
Thanks,
Jeffrey
I've seen the issue in previous versions built from git.git master, as
well as v1.6.3.3, but for this particular one:
$ git --version
git version 1.6.5.1.61.ge79999
$ git remote update --prune
Updating origin
remote: Counting objects: 42, done.
remote: Compressing objects: 100% (9/9), done.
remote: Total 15 (delta 9), reused 12 (delta 6)
Unpacking objects: 100% (15/15), done.
From /users/cxtfcm/CxTF_DB
88b8613..d40f26d 2009.Q4 -> origin/2009.Q4
d40f26d..56305b8 dev -> origin/dev
Updating steph
remote: Counting objects: 299, done.
remote: Compressing objects: 100% (241/241), done.
remote: Total 276 (delta 186), reused 19 (delta 6)
Receiving objects: 100% (276/276), 41.09 KiB | 10 KiB/s, done.
Resolving deltas: 100% (186/186), completed with 17 local objects.
From /users/sdewet/CxTF_DEV/CxTF_DB
+ c2439dd...69cb5c3 beta_gc_dev -> steph/beta_gc_dev (forced update)
+ fb25173...f0e4963 beta_veh_dev -> steph/beta_veh_dev (forced update)
* [new branch] beta_veh_dev_old -> steph/beta_veh_dev_old
Pruning steph
URL: /users/sdewet/CxTF_DEV/CxTF_DB/
* [pruned] steph/beta_gc_dev_old
Updating kevin
error: refs/remotes/steph/beta_gc_dev does not point to a valid object!
error: refs/remotes/steph/beta_veh_dev does not point to a valid object!
Updating jose
error: refs/remotes/steph/beta_gc_dev does not point to a valid object!
error: refs/remotes/steph/beta_veh_dev does not point to a valid object!
### many more remotes with the same errors ###
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Avery Pennarun @ 2009-10-26 22:01 UTC (permalink / raw)
To: Jeff King
Cc: Johannes Schindelin, David Roundy, Junio C Hamano,
Nanako Shiraishi, Alex Riesen, git, Jay Soffian
In-Reply-To: <20091026212628.GC27744@sigio.peff.net>
On Mon, Oct 26, 2009 at 5:26 PM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 26, 2009 at 04:40:41PM -0400, Avery Pennarun wrote:
>> I don't think there's actually a plumbing alternative to git-checkout,
>> however. My git-subtree script (and another script at work) have
>> already had some bugs because of this (specifically, the differing
>> behaviour of git-checkout with and without a path specified). Is
>> there something else I should be using in my scripts to be maximally
>> safe?
>
> It's git-update-ref.
That would be similar to git commit, not git checkout, right? Oh
wait, I see the confusion: git checkout does two things. It switches
branches, and it checks out files from the index into the work tree.
I meant the latter meaning.
> Consider "git commit", for example. Does anyone
> actually script around "write-tree" and "commit-tree" these days, or do
> they just script around "git commit"?
Oh, I use those all the time. They're awesome! It allows you to
create commits without having a working tree, which lets me do very
interesting tricks. git-subtree uses this heavily.
I'm probably a weirdo, though.
Have fun,
Avery
^ permalink raw reply
* [PATCH] push: support remote branches in guess_ref DWIM
From: Jeff King @ 2009-10-26 21:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
When we get an unqualified dest refspec like "foo", we try
to guess its full ref path (like "refs/heads/foo") based on
the source ref. Commit f8aae12 mapped local heads to remote
heads, and local tags to remote tags.
This commit maps local tracking branches under
"refs/remotes" to remote branch heads, so
git push origin origin/branch:renamed-branch
pushes to refs/heads/renamed-branch.
Signed-off-by: Jeff King <peff@peff.net>
---
This came from a discussion on IRC. I don't see any reason not to do
this; would people really expect it to push into refs/remotes/ on the
other side (right now, it complains and dies)?
A related issue (which exists even without this patch) is that doing
this:
master:remotes/incoming/master
will create "refs/heads/remotes/incoming/master". Perhaps we should DWYM
a little more and recognize "heads", "remotes", and "tags" as special.
remote.c | 2 +-
t/t5516-fetch-push.sh | 9 +++++++++
2 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/remote.c b/remote.c
index 73d33f2..1a7c81e 100644
--- a/remote.c
+++ b/remote.c
@@ -998,7 +998,7 @@ static char *guess_ref(const char *name, struct ref *peer)
if (!r)
return NULL;
- if (!prefixcmp(r, "refs/heads/"))
+ if (!prefixcmp(r, "refs/heads/") || !prefixcmp(r, "refs/remotes/"))
strbuf_addstr(&buf, "refs/heads/");
else if (!prefixcmp(r, "refs/tags/"))
strbuf_addstr(&buf, "refs/tags/");
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 6889a53..692c773 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -383,6 +383,15 @@ test_expect_success 'push tag with non-existant, incomplete dest' '
'
+test_expect_success 'push remote branch with non-existant, incomplete dest' '
+
+ mk_test &&
+ git update-ref refs/remotes/foo/bar master &&
+ git push testrepo foo/bar:branch &&
+ check_push_result $the_commit heads/branch
+
+'
+
test_expect_success 'push sha1 with non-existant, incomplete dest' '
mk_test &&
--
1.6.5.1.201.g7feba
^ permalink raw reply related
* Re: [PATCH 3/3] git checkout --nodwim
From: Jeff King @ 2009-10-26 21:26 UTC (permalink / raw)
To: Avery Pennarun
Cc: Johannes Schindelin, David Roundy, Junio C Hamano,
Nanako Shiraishi, Alex Riesen, git, Jay Soffian
In-Reply-To: <32541b130910261340g1988caednc17f3d159ec00d26@mail.gmail.com>
On Mon, Oct 26, 2009 at 04:40:41PM -0400, Avery Pennarun wrote:
> I don't think there's actually a plumbing alternative to git-checkout,
> however. My git-subtree script (and another script at work) have
> already had some bugs because of this (specifically, the differing
> behaviour of git-checkout with and without a path specified). Is
> there something else I should be using in my scripts to be maximally
> safe?
It's git-update-ref. Which highlights one problem with the
porcelain/plumbing distinction. Our plumbing building blocks work at a
very low level, but often when scripting you want to use higher level
building blocks. So porcelain gets used in scripts, and gets an
ambiguous state. Consider "git commit", for example. Does anyone
actually script around "write-tree" and "commit-tree" these days, or do
they just script around "git commit"?
-Peff
^ permalink raw reply
* Re: git rebase -i <first_commit_in_repository>
From: Johannes Schindelin @ 2009-10-26 21:11 UTC (permalink / raw)
To: eschvoca; +Cc: kusmabite, git
In-Reply-To: <2b05065b0910261108g4a8448c8x295606a8d33612f5@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 660 bytes --]
Hi,
On Mon, 26 Oct 2009, eschvoca wrote:
> On Mon, Oct 26, 2009 at 1:25 PM, Erik Faye-Lund
> <kusmabite@googlemail.com> wrote:
> > On Mon, Oct 26, 2009 at 6:14 PM, eschvoca <eschvoca@gmail.com> wrote:
> >> Hi,
> >>
> >> Is there a way to rewrite history, including the first commit. It
> >> seems that the first commit can not be modified with a rebase.
> >
> > This question is answered in the FAQ:
> > http://git.or.cz/gitwiki/GitFaq#HowdoIedittherootcommit.3F
>
> Thanks Eric. Hopefully someone will enhance rebase to handle the root
> commit.
If you cannot do it yourself, you can always offer to bribe^Wpay somebody
to do it for you.
Ciao,
Dscho
^ permalink raw reply
* Re: git rebase -i <first_commit_in_repository>
From: Allan Caffee @ 2009-10-26 20:47 UTC (permalink / raw)
To: Dirk Süsserott; +Cc: eschvoca, kusmabite, git
In-Reply-To: <4AE60669.9080402@dirk.my1.cc>
2009/10/26 Dirk Süsserott <newsletter@dirk.my1.cc>:
> Am 26.10.2009 19:08 schrieb eschvoca:
> Hi,
>
> probably my approach could help you in the future: When I create a new repo
> (git init) I firstly create an initial commit with nothing else than an
> initial commit, i.e.:
>
> $ git init
> $ echo "initial" > initial.commit
> $ git add initial.commit
> $ git commit -m "Initial commit"
I don't think this is actually necessary. You should just be able to do:
$ git init
$ git commit --allow-empty -m "Initial commit (empty)"
--
Allan
^ permalink raw reply
* Re: [PATCH 3/3] git checkout --nodwim
From: Avery Pennarun @ 2009-10-26 20:40 UTC (permalink / raw)
To: Johannes Schindelin
Cc: David Roundy, Junio C Hamano, Nanako Shiraishi, Alex Riesen, git,
Jay Soffian
In-Reply-To: <alpine.DEB.1.00.0910262111340.4985@pacific.mpi-cbg.de>
On Mon, Oct 26, 2009 at 4:12 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> On Sat, 24 Oct 2009, David Roundy wrote:
>> Perhaps a universal --plumbing flag would be handy?
>
> No. Older Git versions do not know about it, so you cannot Just Modify
> Your Scripts. So the benefit of --plumbing is dubitable.
>
> FWIW the same goes for --no-porcelain.
I suppose that, three years down the road, the existence of such an
option would be useful. Until then, any change at all to any
command's interface seems to have the same problem as you describe.
That said, as a person who maintains a bunch of git-wrapping scripts
at work, it seems more straightforward to me to continue the
separation between plumbing vs. porcelain commands, rather than giving
each command two subtly incompatible modes. It's much easier for me
to remember "don't use git checkout" than to remember "when you call
git checkout, make sure to use --plumbing, even though *today* it
works just fine without it."
I don't think there's actually a plumbing alternative to git-checkout,
however. My git-subtree script (and another script at work) have
already had some bugs because of this (specifically, the differing
behaviour of git-checkout with and without a path specified). Is
there something else I should be using in my scripts to be maximally
safe?
Have fun,
Avery
^ permalink raw reply
* [PATCH/RFC 2/2] completion: allow use without compiling
From: Stephen Boyd @ 2009-10-26 20:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git, Clemens Buchacher, Sverre Rabbelier
In-Reply-To: <1256589116-6998-1-git-send-email-bebarino@gmail.com>
Some users don't want to compile their completion, even when the build
generated completion is 10x faster to load. For example, in my bashrc I
source the completion script directly so I can stay up to date with the
latest completion by merely pulling changes.
Do this by generating the lists dynamically when the merge strategy and
command lists still have their initial values (__GIT_MERGE_STRATEGYLIST,
__GIT_ALL_COMMANDLIST).
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
This duplicates code, but I don't know of a way to re-use the dynamic
code without sourcing a bash script and possibly breaking someone's build.
contrib/completion/git-completion.bash.in | 132 +++++++++++++++++++++++++++--
1 files changed, 123 insertions(+), 9 deletions(-)
diff --git a/contrib/completion/git-completion.bash.in b/contrib/completion/git-completion.bash.in
index d873b98..37d204c 100644
--- a/contrib/completion/git-completion.bash.in
+++ b/contrib/completion/git-completion.bash.in
@@ -60,15 +60,6 @@ __git_merge_strategylist=__GIT_MERGE_STRATEGYLIST
__git_all_commandlist=__GIT_ALL_COMMANDLIST
__git_porcelain_commandlist=__GIT_PORCELAIN_COMMANDLIST
-# remind folks that git-completion.bash.in can't be sourced
-case "$__git_merge_strategylist" in
-__GIT*)
- echo "E: git-completion.bash.in can't be sourced"
- return 1 ;;
-esac
-
-
-
case "$COMP_WORDBREAKS" in
*:*) : great ;;
*) COMP_WORDBREAKS="$COMP_WORDBREAKS:"
@@ -333,6 +324,22 @@ __git_remotes ()
done
}
+__git_merge_strategies ()
+{
+ if ["$__git_merge_strategylist" != "__GIT_MERGE_STRATEGYLIST"]; then
+ echo "$__git_merge_strategylist"
+ return
+ fi
+ git merge -s help 2>&1 |
+ sed -n -e '/[Aa]vailable strategies are: /,/^$/{
+ s/\.$//
+ s/.*://
+ s/^[ ]*//
+ s/[ ]*$//
+ p
+ }'
+}
+__git_merge_strategylist="$(__git_merge_strategies 2>/dev/null)"
__git_complete_file ()
{
@@ -481,6 +488,113 @@ __git_complete_strategy ()
return 1
}
+__git_all_commands ()
+{
+ if ["$__git_all_commandlist" != "__GIT_ALL_COMMANDLIST"]; then
+ echo "$__git_all_commandlist"
+ return
+ fi
+ local i
+ for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
+ do
+ case $i in
+ *--*) : helper pattern;;
+ *) echo $i;;
+ esac
+ done
+}
+__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
+
+__git_porcelain_commands ()
+{
+ if ["$__git_porcelain_commandlist" != "__GIT_PORCELAIN_COMMANDLIST"]; then
+ echo "$__git_porcelain_commandlist"
+ return
+ fi
+ local i
+ for i in "help" $(__git_all_commands)
+ do
+ case $i in
+ *--*) : helper pattern;;
+ applymbox) : ask gittus;;
+ applypatch) : ask gittus;;
+ archimport) : import;;
+ cat-file) : plumbing;;
+ check-attr) : plumbing;;
+ check-ref-format) : plumbing;;
+ checkout-index) : plumbing;;
+ commit-tree) : plumbing;;
+ count-objects) : infrequent;;
+ cvsexportcommit) : export;;
+ cvsimport) : import;;
+ cvsserver) : daemon;;
+ daemon) : daemon;;
+ diff-files) : plumbing;;
+ diff-index) : plumbing;;
+ diff-tree) : plumbing;;
+ fast-import) : import;;
+ fast-export) : export;;
+ fsck-objects) : plumbing;;
+ fetch-pack) : plumbing;;
+ fmt-merge-msg) : plumbing;;
+ for-each-ref) : plumbing;;
+ hash-object) : plumbing;;
+ http-*) : transport;;
+ index-pack) : plumbing;;
+ init-db) : deprecated;;
+ local-fetch) : plumbing;;
+ lost-found) : infrequent;;
+ ls-files) : plumbing;;
+ ls-remote) : plumbing;;
+ ls-tree) : plumbing;;
+ mailinfo) : plumbing;;
+ mailsplit) : plumbing;;
+ merge-*) : plumbing;;
+ mktree) : plumbing;;
+ mktag) : plumbing;;
+ pack-objects) : plumbing;;
+ pack-redundant) : plumbing;;
+ pack-refs) : plumbing;;
+ parse-remote) : plumbing;;
+ patch-id) : plumbing;;
+ peek-remote) : plumbing;;
+ prune) : plumbing;;
+ prune-packed) : plumbing;;
+ quiltimport) : import;;
+ read-tree) : plumbing;;
+ receive-pack) : plumbing;;
+ reflog) : plumbing;;
+ repo-config) : deprecated;;
+ rerere) : plumbing;;
+ rev-list) : plumbing;;
+ rev-parse) : plumbing;;
+ runstatus) : plumbing;;
+ sh-setup) : internal;;
+ shell) : daemon;;
+ show-ref) : plumbing;;
+ send-pack) : plumbing;;
+ show-index) : plumbing;;
+ ssh-*) : transport;;
+ stripspace) : plumbing;;
+ symbolic-ref) : plumbing;;
+ tar-tree) : deprecated;;
+ unpack-file) : plumbing;;
+ unpack-objects) : plumbing;;
+ update-index) : plumbing;;
+ update-ref) : plumbing;;
+ update-server-info) : daemon;;
+ upload-archive) : plumbing;;
+ upload-pack) : plumbing;;
+ write-tree) : plumbing;;
+ var) : infrequent;;
+ verify-pack) : infrequent;;
+ verify-tag) : plumbing;;
+ *) echo $i;;
+ esac
+ done
+}
+__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
+
__git_aliases ()
{
local i IFS=$'\n'
--
1.6.5.2.181.gd6f41
^ permalink raw reply related
* [PATCH 1/2] completion: ignore custom merge strategies when pre-generating
From: Stephen Boyd @ 2009-10-26 20:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <1256589116-6998-1-git-send-email-bebarino@gmail.com>
Since the Makefile adds the build directory to PATH, we get the merge
strategies twice. Ignore custom merge strategies which are just the
builtin merge strategies (octopus.sh, ours.sh, etc.) anyway.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
---
contrib/completion/git-completion.bash.generate | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash.generate b/contrib/completion/git-completion.bash.generate
index 6487fd5..b66254a 100755
--- a/contrib/completion/git-completion.bash.generate
+++ b/contrib/completion/git-completion.bash.generate
@@ -9,6 +9,7 @@ __git_merge_strategies ()
{
git merge -s help 2>&1 |
sed -n -e '/[Aa]vailable strategies are: /,/^$/{
+ /^[Aa]vailable custom strategies are: / d
s/\.$//
s/.*://
s/^[ ]*//
--
1.6.5.2.181.gd6f41
^ permalink raw reply related
* [PATCH 0/2] pre-generated completion fix and RFC
From: Stephen Boyd @ 2009-10-26 20:31 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
I should have looked at the actual generated completion before hastily
sending my last fix. Looks like we get the merge strategies twice in the
merge strategy list.
The second patch is a quick hack to have completion lazily load again
while still allowing pre-generated completion.
These are on top of next.
Stephen Boyd (2):
completion: ignore custom merge strategies when pre-generating
completion: allow use without compiling
contrib/completion/git-completion.bash.generate | 1 +
contrib/completion/git-completion.bash.in | 132 +++++++++++++++++++++--
2 files changed, 124 insertions(+), 9 deletions(-)
^ permalink raw reply
* Re: git rebase -i <first_commit_in_repository>
From: Dirk Süsserott @ 2009-10-26 20:28 UTC (permalink / raw)
To: eschvoca; +Cc: kusmabite, git
In-Reply-To: <2b05065b0910261108g4a8448c8x295606a8d33612f5@mail.gmail.com>
Am 26.10.2009 19:08 schrieb eschvoca:
> On Mon, Oct 26, 2009 at 1:25 PM, Erik Faye-Lund
> <kusmabite@googlemail.com> wrote:
>> On Mon, Oct 26, 2009 at 6:14 PM, eschvoca <eschvoca@gmail.com> wrote:
>>> Hi,
>>>
>>> Is there a way to rewrite history, including the first commit. It
>>> seems that the first commit can not be modified with a rebase.
>> This question is answered in the FAQ:
>> http://git.or.cz/gitwiki/GitFaq#HowdoIedittherootcommit.3F
>>
>
> Thanks Eric. Hopefully someone will enhance rebase to handle the root commit.
Hi,
probably my approach could help you in the future: When I create a new
repo (git init) I firstly create an initial commit with nothing else
than an initial commit, i.e.:
$ git init
$ echo "initial" > initial.commit
$ git add initial.commit
$ git commit -m "Initial commit"
and then secondly
$ git add .
$ git commit -m "*REAL* initial commit"
Afterwards I have a repo with an initial commit that only contains one
file (initial.commit) and the "real" initial commits thereafter. Maybe
that's a solution for you.
Cheers,
Dirk
^ 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