* Re: git hang with corrupted .pack
From: Shawn O. Pearce @ 2009-10-26 14:23 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Alex Riesen, Nicolas Pitre, Andy Isaacson, git
In-Reply-To: <7vr5sqq3vm.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Alex Riesen <raa.lkml@gmail.com> writes:
> > I seem to have problems with this change (on Cygwin). Sometimes
> > accessing an object in a pack fails in unpack_compressed_entry.
> > When it happens, both avail_in and avail_out of the stream are 0,
> > and the reported status is Z_BUF_ERROR.
...
> Subject: Fix incorrect error check while reading deflated pack data
Wow.
> The right fix for this loop is likely to be to increment the initial
> avail_out by one (we allocate one extra byte to terminate it with NUL
> anyway, so there is no risk to overrun the buffer), and break out if we
> see that avail_out has become zero, in order to detect that the stream
> wants to produce more than what we expect. After the loop, we have a
> check that exactly tests this condition:
>
> if ((st != Z_STREAM_END) || stream.total_out != size) {
> free(buffer);
> return NULL;
> }
>
> So here is a patch (without my previous botched attempts) to fix this
> issue. The first hunk reverts the corresponding hunk from b3118bd, and
> the second hunk is the same fix proposed earlier.
ACK. This looks right to me too. I forgot about that end-of-stream
marker on the input buffer, and my testing failed to have a stream
where the end-of-stream marker was in the next back window, so this
"fix" wasn't triggering.
*sigh* Thanks for digging into this and fixing it while I was away.
--
Shawn.
^ permalink raw reply
* Re: keeping track of where a patch begins
From: Jeff King @ 2009-10-26 14:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, E R, git
In-Reply-To: <7veiow4iqc.fsf@alter.siamese.dyndns.org>
On Wed, Oct 21, 2009 at 01:03:55PM -0700, Junio C Hamano wrote:
> (0) Define a way to identify the bottom of a branch. One way to do this
> is by an extra ref (e.g. refs/branchpoints/frotz). Then the commits
> between refs/branchpoints/frotz..refs/heads/frotz identifies the
> commits on the branch. None of the additional restrictions below
> applies when the branch does not have such bottom defined (i.e.
> created by the current git without this extension).
Hmm. This feels like redundant information to me. It has always been
git's strategy to record the history graph, and to use merge bases as
the "bottom" of branches, rather than keeping an artificial "started
here" commit. So I am trying to see the advantages of recording a static
bottom versus doing a merge-base calculation later. Some things I can
think of:
- a bottom implies a specific commit, whereas a merge-base is always
with respect to anothe tip. So to have a default "bottom" calculated
by merge-base, you need a default "upstream". Which we do have, but
of course it is subject to being rewound.
- your merge-base will move when you merge. But arguably, that is a
good thing. If you are talking about "git log" only looking at the
commits on this branch (as you do later in the quoted email), I
would expect to see only stuff that happened since upstream last
merged. Although to be honest, I am not sure such a limit is all
that useful. We already have "git log upstream..branch".
So I am not really clear on what you are trying to accomplish by
recording such a bottom. Your steps (0) through (3) seem to be leading
up to this use case:
> (4) Operations that browse histories, e.g. "log", "show-branch", while on
> a branch that records its bottom can be taught to pay attention to
> the bottom. For example, it is conceivable that
>
> $ git log
> $ git log -- Documentation/
>
> without an explicit branch name that fell back to the default HEAD
> while on branch "frotz" might be better run with an implicit bottom
> ^refs/branchpoint/frotz.
If that is all you want, can't we just default to something like:
$ git log $(git for-each-ref --format='%(upstream)' $(git symbolic-ref HEAD)))..
Of course it would be much easier to type as "git log @{upstream}.." :)
-Peff
^ permalink raw reply
* Re: [ANNOUNCE] Stacked Git 0.15
From: Catalin Marinas @ 2009-10-26 16:23 UTC (permalink / raw)
To: Karl Wiberg; +Cc: Jakub Narebski, Git Mailing List
In-Reply-To: <20091026134915.GA1565@diana.vm.bytemark.co.uk>
2009/10/26 Karl Wiberg <kha@treskal.com>:
> On 2009-10-26 10:32:07 +0000, Catalin Marinas wrote:
>> The problem was a bit more complicated than this. Some files are
>> generated by the Makefile rather than setup.py so using the latter
>> directly fails to build anything.
>>
>> So it's time for 0.15.1 this week with the fix below (in my
>> "proposed" branch). I cc'ed Karl as well in case he has time to have
>> a quick look.
>
> I don't have any objections, except ...
[...]
>> -test: build
>> +test:
>> cd t && $(MAKE) all
>
> ... don't we need to run "setup.py build" here in order to not change
> the behavior?
Good point. I updated the patch in the "proposed" branch.
Thanks.
--
Catalin
^ 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
* 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
* 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: 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: [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: [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
* 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: 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
* 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: [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: 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
* [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
* [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/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
* 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
* 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: 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: [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
* [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: 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
* 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: 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
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