* Re: [PATCH/RFC 2/2] completion: allow use without compiling
From: Clemens Buchacher @ 2009-10-27 0:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Stephen Boyd, Shawn O. Pearce, git, Sverre Rabbelier
In-Reply-To: <7vocntd7vt.fsf@alter.siamese.dyndns.org>
On Mon, Oct 26, 2009 at 04:59:18PM -0700, Junio C Hamano wrote:
> Stephen Boyd <bebarino@gmail.com> writes:
>
> > 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.
>
> (1) If the script notices that there is a file that contains the command
> list, it sources it; otherwise,
Or we substitute the command list in-place, so that we still have the entire
completion script in one file.
Clemens
^ permalink raw reply
* Re: git rebase -i <first_commit_in_repository>
From: eschvoca @ 2009-10-27 0:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: kusmabite, git
In-Reply-To: <alpine.DEB.1.00.0910262210480.4985@pacific.mpi-cbg.de>
Hi,
On Mon, Oct 26, 2009 at 5:11 PM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> 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
>
I can do the workaround myself but not the production ready patch.
Right now the only bribe I can offer is that it might be less work
writing the patch than supporting this corner case with answering
questions and writing a FAQ entry about it. It also would make the
awesome rebase -i even awesomer :) I know, a disappointing bribe but
from a thankful user.
Thanks
^ permalink raw reply
* Re: git vs hg commit counts?
From: Joe Perches @ 2009-10-27 0:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: LKML, git, mercurial, Marti Raudsepp
In-Reply-To: <7v8wexd6zq.fsf@alter.siamese.dyndns.org>
On Mon, 2009-10-26 at 17:18 -0700, Junio C Hamano wrote:
> > $ 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?
> We simplify a merge history by discarding one branch when the merge result
> matches one of the parents.
Thanks Junio.
> Does "hg" know how to do that as well?
I don't know.
I was hoping to get equivalent results though.
Anyone know how?
^ permalink raw reply
* Problems with git am
From: Alan @ 2009-10-27 0:12 UTC (permalink / raw)
To: git
I am encountering an interesting issue. I am not certain if I am doing
something wrong or I am encountering a bug or what.
I am using Git version 1.6.0.6 from Fedora 9. I am not using the current
version because it has changed how it errors out. (If git does not
understand the patch, instead of exiting with an error code that xargs
will fail on it exits with something non-fatal.)
I have a number of patches that I have been handed to apply to a git tree.
The patches have been generated by git, but have not been e-mailed. (They
may have been extracted from gitweb or some other source.)
The header of the patch looks like:
commit 62b266585bb5555d44a764c90d80f9c4bb8188c1
Author: Joe Example <joe@example.com>
Date: Wed Sep 19 10:03:47 2009 -0600
There is no e-mail line, but it has the information for e-mail address.
If I apply this patch it will error out with:
"Patch does not have a valid e-mail address."
If I use a current version of Git it errors out with a message "Cannot
determine patch format", but does not issue a fatal error code.
If I use git-apply on this patch, it applies it to the tree, but does not
commit it. (I need the comments and signoffs to remain intact.) I have to
cut-and-paste the commit information to keep it. (I am working on an
automated process to handle these patches and don' want to have to
reinvent git-am.)
Am i doing something wrong here?
My goal is to be able to take whatever patch I am handed and apply it to
the current tree. If it is a raw diff, I can handle that. What concerns
me are these patches that look like they are generated by git, but which
do not apply cleanly with git-am.
Is there some sort of instructions for applying patches that are dumped
out using "git-show" or some other mechanism?
I am not finding this process documented anywhere. (If it is, it is
pretty well hidden.)
Thanks!
^ permalink raw reply
* Re: git vs hg commit counts?
From: Junio C Hamano @ 2009-10-27 0:18 UTC (permalink / raw)
To: Joe Perches; +Cc: LKML, git, mercurial, Marti Raudsepp
In-Reply-To: <1256602127.29938.8.camel@Joe-Laptop.home>
Joe Perches <joe@perches.com> writes:
> 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?
We simplify a merge history by discarding one branch when the merge result
matches one of the parents. Does "hg" know how to do that as well?
^ permalink raw reply
* 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
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