* 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
* Re: [PATCH 3/3] git checkout --nodwim
From: Johannes Schindelin @ 2009-10-26 20:12 UTC (permalink / raw)
To: David Roundy
Cc: Junio C Hamano, Nanako Shiraishi, Avery Pennarun, Alex Riesen,
git, Jay Soffian
In-Reply-To: <117f2cc80910240759oa9f57e7h67f06816d37e328c@mail.gmail.com>
Hi,
On Sat, 24 Oct 2009, David Roundy wrote:
> On Sat, Oct 24, 2009 at 2:35 AM, Junio C Hamano <gitster@pobox.com> wrote:
> >> My take on it:
> >>
> >> 1) --no-porcelain
> >>
> >> 2) we all are bike-shedding, not being constructive at all
> >
> > You are right about (2), regarding the option name. I've queued one that
> > uses --no-guess.
>
> 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.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] git-gui: (un)stage a range of changes at once
From: Jeff Epler @ 2009-10-26 19:39 UTC (permalink / raw)
To: git
In-Reply-To: <1256160023-29629-1-git-send-email-jepler@unpythonic.net>
I've found another problem, which I'll work on as soon as I find a
chance.
When staging multiple "+" lines preceded by a "-" line that must be
turned into context, the converted "-" line must come after *all* the
"+" lines, not just the first one.
Jeff
^ permalink raw reply
* Re: git-svn changing file:// to svn+ssh://
From: Avery Pennarun @ 2009-10-26 19:18 UTC (permalink / raw)
To: pascal; +Cc: git list
In-Reply-To: <4AE5EF55.2070902@obry.net>
On Mon, Oct 26, 2009 at 2:49 PM, Pascal Obry <pascal@obry.net> wrote:
> On a large project it is failing. Here is what I have done:
>
> I have cloned the repository using:
>
> $ git svn clone --prefix=svn/ file:///path/repo \
> --revision=15314:HEAD --trunk=trunk/project \
> --tags=tags/project --branches=branches/project \
> --branches="branches/global/*/project" project
>
> Not simple, ok but working :)
>
> Now I have converted the file:// to svn+ssh:// using:
I'm not sure about the actual bug you're experiencing, but you could
have done this more simply using the --rewrite-root option to git-svn.
It might still save you time to just do that from scratch.
If you really want to debug it, you might want to run it through
'strace' and see if it's having any trouble creating those files.
Have fun,
Avery
^ permalink raw reply
* git-svn changing file:// to svn+ssh://
From: Pascal Obry @ 2009-10-26 18:49 UTC (permalink / raw)
To: git list
I'm working on preparing Git SVN mirrors.
I had tested my procedure on a small project and it was working fine.
On a large project it is failing. Here is what I have done:
I have cloned the repository using:
$ git svn clone --prefix=svn/ file:///path/repo \
--revision=15314:HEAD --trunk=trunk/project \
--tags=tags/project --branches=branches/project \
--branches="branches/global/*/project" project
Not simple, ok but working :)
Now I have converted the file:// to svn+ssh:// using:
$ git gc
$ git filter-branch --msg-filter \
'sed "s,git-svn-id: file:///path/repo,git-svn-id:
svn+ssh://server/repo,g"' \
$(cat .git/packed-refs | awk '// {print $2}' | grep -v 'pack-refs')
$ rm -fr .git/svn
I have edited .git/config to change the url string too.
Up to there, no problem. But when trying to rebase and reconstruct all
rev_map files with:
$ git svn rebase
I get the following lines again and again:
Rebuilding
.git/svn/svn/trunk/.rev_map.f8352e7e-cb20-0410-8ce7-b5d9e71c585c ...
Done rebuilding
.git/svn/svn/trunk/.rev_map.f8352e7e-cb20-0410-8ce7-b5d9e71c585c
Rebuilding
.git/svn/svn/trunk/.rev_map.f8352e7e-cb20-0410-8ce7-b5d9e71c585c ...
Done rebuilding
.git/svn/svn/trunk/.rev_map.f8352e7e-cb20-0410-8ce7-b5d9e71c585c
...
The file
.git/svn/svn/trunk/.rev_map.f8352e7e-cb20-0410-8ce7-b5d9e71c585c is in
fact not created.
What could be wrong?
How should I proceed to debug this?
Any help appreciated.
Last note I've tried all this with Git 1.6.4 and 1.6.5.
Thanks,
Pascal.
--
--|------------------------------------------------------
--| Pascal Obry Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--| http://www.obry.net - http://v2p.fr.eu.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver keys.gnupg.net --recv-key F949BD3B
^ permalink raw reply
* Re: [PATCH] git checkout --no-guess
From: Avery Pennarun @ 2009-10-26 18:25 UTC (permalink / raw)
To: Jay Soffian; +Cc: Git Mailing List
In-Reply-To: <76718490910261117i60a556ebv7405e945796a3610@mail.gmail.com>
On Mon, Oct 26, 2009 at 2:17 PM, Jay Soffian <jaysoffian@gmail.com> wrote:
> On Wed, Oct 21, 2009 at 3:51 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
>> Just curious. (And now wondering how many other wonderful options are
>> in there but undocumented...)
>
> * PARSE_OPT_HIDDEN: this option is skipped in the default usage, and
> * shown only in the full usage.
>
> Which translates to --help-all:
>
> --help-all
> Some git commands take options that are only used for
> plumbing or that are deprecated, and such options are hidden from the
> default usage. This option gives the full list of options.
>
> So git checkout --help-all should show it.
Thanks! I had no idea about --help-all.
Avery
^ permalink raw reply
* Re: [PATCH] git checkout --no-guess
From: Jay Soffian @ 2009-10-26 18:17 UTC (permalink / raw)
To: Avery Pennarun
Cc: Junio C Hamano, git, Nanako Shiraishi, Alex Riesen,
Johannes Schindelin
In-Reply-To: <32541b130910211551n13e0dd1bha6dcdc82d1d6b4cd@mail.gmail.com>
On Wed, Oct 21, 2009 at 3:51 PM, Avery Pennarun <apenwarr@gmail.com> wrote:
> On Wed, Oct 21, 2009 at 6:35 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> As this is strictly script-only option, do not even bother to document it,
>> and do bother to hide it from "git checkout -h".
>
> Is it a standard git policy to not document script-only options? As a
> person who writes scripts that use git, we will need to discover these
> options somehow...
>
> Just curious. (And now wondering how many other wonderful options are
> in there but undocumented...)
* PARSE_OPT_HIDDEN: this option is skipped in the default usage, and
* shown only in the full usage.
Which translates to --help-all:
--help-all
Some git commands take options that are only used for
plumbing or that are deprecated, and such options are hidden from the
default usage. This option gives the full list of options.
So git checkout --help-all should show it.
j.
^ permalink raw reply
* Re: git rebase -i <first_commit_in_repository>
From: eschvoca @ 2009-10-26 18:08 UTC (permalink / raw)
To: kusmabite; +Cc: git
In-Reply-To: <40aa078e0910261025l1ad7bf8ex27fd62072a317f9d@mail.gmail.com>
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.
^ permalink raw reply
* Re: git rebase -i <first_commit_in_repository>
From: Erik Faye-Lund @ 2009-10-26 17:25 UTC (permalink / raw)
To: eschvoca; +Cc: git
In-Reply-To: <2b05065b0910261014t4eb93952oc804bcd01b339a84@mail.gmail.com>
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
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: git rebase -i <first_commit_in_repository>
From: Mike Hommey @ 2009-10-26 17:24 UTC (permalink / raw)
To: eschvoca; +Cc: git
In-Reply-To: <2b05065b0910261014t4eb93952oc804bcd01b339a84@mail.gmail.com>
On Mon, Oct 26, 2009 at 01:14:47PM -0400, eschvoca 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.
Unfortunately, there is no way to do so, except by hand, by checking out
the first commit, amend it, and then rebase.
Mike
^ permalink raw reply
* git rebase -i <first_commit_in_repository>
From: eschvoca @ 2009-10-26 17:14 UTC (permalink / raw)
To: git
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.
Cheers.
^ 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