* Re: [PATCH v4 00/13] New remote-hg helper
From: Jeff King @ 2012-10-29 21:26 UTC (permalink / raw)
To: Felipe Contreras
Cc: git, Junio C Hamano, Sverre Rabbelier, Johannes Schindelin,
Ilari Liusvaara, Daniel Barkalow, Michael J Gruber
In-Reply-To: <CAMP44s0RVe6i4DpNmaV_n7_5KO_aq2WxCPVafjsTukExRSR5Jw@mail.gmail.com>
On Mon, Oct 29, 2012 at 03:56:39PM +0100, Felipe Contreras wrote:
> >> I've ported the tests from hg-git and made sure that the output from remote-hg
> >> matches the output of hg-git. With these extensive tests I would consider this
> >> one ready for wide use. Not only do the tests pass, I've compared the generated
> >> repos of a few projects, and the SHA-1's are exactly the same :)
> >
> > Sounds cool. Unfortunately, the test script hangs for me, after starting
> > up xxdiff (!).
> >
> > pstree reveals that it is "hg" that starts it, but I didn't investigate
> > beyond that.
>
> Yeah, the test script is not ready for merging, it needs to check for
> python, hg, and hg-git.
>
> Do you have hg-git installed?
No. But it's important that it fail gracefully; I can't even take it in
pu if I can't run the test suite in a sane way.
I may try to figure it out later myself, but it's not a super high
priority for me.
-Peff
^ permalink raw reply
* Re: crash on git diff-tree -Ganything <tree> for new files with textconv filter
From: Peter Oberndorfer @ 2012-10-29 20:19 UTC (permalink / raw)
To: Jeff King; +Cc: git, Junio C Hamano
In-Reply-To: <20121029060524.GB4457@sigill.intra.peff.net>
On 2012-10-29 07:05, Jeff King wrote:
> On Sun, Oct 28, 2012 at 08:56:39PM +0100, Peter Oberndorfer wrote:
>
>>> The patch below should fix it. I added tests, but please try your
>>> real-world test case on it to double-check.
>> I tested your patch, but now it crashes for another reason :-)
> Well, that's progress, right? :)
Sure :-)
>
>> i have a file with exactly 12288(0x3000) bytes in the repository.
>> When the file is loaded, the data is placed luckily so the data end
>> falls at a page boundary.
>> Later diff_grep() calls regexec() which calls strlen() on the loaded buffer
>> and ends up reading beyond the actual data into the next page
>> which is not allocated and causes a pagefault.
>> Or it could possibly (randomly) match the regex on data that is not
>> actually part of a file...
> Yuck. For the most part, we treat blob content (and generally most
> object content) as a sized buffer. However, there are some spots which,
> either through laziness or because a code interface expects a string, we
> pass the value as a string. This works because the object-reading code
> puts an extra NUL at the end of our buffer to handle just such an
> instance. So we might prematurely end if the object contains embedded
> NULs, but we would never read past the end.
>
> The code to read the output of a textconv filter does not do this
> explicitly. I would think it would get it for free by virtue of reading
> into a strbuf, though. I'll try to investigate.
I could reproduce with my 0x3000 bytes file on linux. The buffer is not
read with a trailing null byte it is mapped by mmap in
diff_populate_filespec...
So i think we will not get away with expecting a trailing null :-/
For me the key to reproduce the problem was to have 2 commits.
Adding the file in the root commit it did not work. [1]
Greetings Peter
> -Peff
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
[1]
kumbayo@home:~/src$ mkdir git_mmap_crash2
kumbayo@home:~/src$ cd git_mmap_crash2
kumbayo@home:~/src/git_mmap_crash2$ git init
kumbayo@home:~/src/git_mmap_crash2$ echo blah>blah
kumbayo@home:~/src/git_mmap_crash2$ git add blah
kumbayo@home:~/src/git_mmap_crash2$ git commit -m blah
[master (Basis-Version) 3458422] blah
diff_populate_filespec -> xmmap for blah size:0x5 returned: 0xb7206000
1 file changed, 1 insertion(+)
create mode 100644 blah
kumbayo@home:~/src/git_mmap_crash2$ perl -e 'print "-" x 0x3000 '> asdf.txt
kumbayo@home:~/src/git_mmap_crash2$ git add asdf.txt
kumbayo@home:~/src/git_mmap_crash2$ git commit -m crashy
[master 5cf2c5f] crashy
diff_populate_filespec -> xmmap for asdf.txt size:0x3000 returned:
0xb771e000
1 file changed, 1 insertion(+)
create mode 100644 asdf.txt
kumbayo@soybean:~/src/git_mmap_crash2$ valgrind git diff-tree -Ganything HEAD
==8388== Memcheck, a memory error detector
==8388== Copyright (C) 2002-2011, and GNU GPL'd, by Julian Seward et al.
==8388== Using Valgrind-3.7.0 and LibVEX; rerun with -h for copyright info
==8388== Command: git diff-tree -Ganything HEAD
==8388==
==8388== Conditional jump or move depends on uninitialised value(s)
==8388== at 0x405ADD8: inflateReset2 (in /lib/i386-linux-gnu/libz.so.1.2.3.4)
==8388== by 0xA0: ???
==8388==
==8388== Conditional jump or move depends on uninitialised value(s)
==8388== at 0x405ADD8: inflateReset2 (in /lib/i386-linux-gnu/libz.so.1.2.3.4)
==8388== by 0x7F: ???
==8388==
==8388== Conditional jump or move depends on uninitialised value(s)
==8388== at 0x405ADD8: inflateReset2 (in /lib/i386-linux-gnu/libz.so.1.2.3.4)
==8388== by 0x30: ???
==8388==
==8388== Conditional jump or move depends on uninitialised value(s)
==8388== at 0x405ADD8: inflateReset2 (in /lib/i386-linux-gnu/libz.so.1.2.3.4)
==8388== by 0x50: ???
==8388==
diffcore_pickaxe_grep
diff_populate_filespec -> xmmap for asdf.txt size:0x3000 returned: 0x4035000
==8388== Invalid read of size 1
==8388== at 0x402C683: __GI_strlen (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==8388== by 0x430581F: regexec@@GLIBC_2.3.4 (regexec.c:245)
==8388== by 0x814489D: diff_grep (diffcore-pickaxe.c:110)
==8388== by 0x8144B89: pickaxe.constprop.6 (diffcore-pickaxe.c:40)
==8388== by 0x8144DCD: diffcore_pickaxe_grep (diffcore-pickaxe.c:155)
==8388== by 0x80DCE64: diffcore_std (diff.c:4638)
==8388== by 0x80F0B20: log_tree_diff_flush (log-tree.c:696)
==8388== Address 0x4038000 is not stack'd, malloc'd or (recently) free'd
==8388==
==8388==
==8388== Process terminating with default action of signal 11 (SIGSEGV)
==8388== Access not within mapped region at address 0x4038000
==8388== at 0x402C683: __GI_strlen (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==8388== by 0x430581F: regexec@@GLIBC_2.3.4 (regexec.c:245)
==8388== by 0x814489D: diff_grep (diffcore-pickaxe.c:110)
==8388== by 0x8144B89: pickaxe.constprop.6 (diffcore-pickaxe.c:40)
==8388== by 0x8144DCD: diffcore_pickaxe_grep (diffcore-pickaxe.c:155)
==8388== by 0x80DCE64: diffcore_std (diff.c:4638)
==8388== by 0x80F0B20: log_tree_diff_flush (log-tree.c:696)
==8388== If you believe this happened as a result of a stack
==8388== overflow in your program's main thread (unlikely but
==8388== possible), you can try to increase the size of the
==8388== main thread stack using the --main-stacksize= flag.
==8388== The main thread stack size used in this run was 8388608.
==8388==
==8388== HEAP SUMMARY:
==8388== in use at exit: 86,229 bytes in 69 blocks
==8388== total heap usage: 193 allocs, 124 frees, 259,991 bytes allocated
==8388==
==8388== LEAK SUMMARY:
==8388== definitely lost: 65 bytes in 1 blocks
==8388== indirectly lost: 0 bytes in 0 blocks
==8388== possibly lost: 0 bytes in 0 blocks
==8388== still reachable: 86,164 bytes in 68 blocks
==8388== suppressed: 0 bytes in 0 blocks
==8388== Rerun with --leak-check=full to see details of leaked memory
==8388==
==8388== For counts of detected and suppressed errors, rerun with: -v
==8388== Use --track-origins=yes to see where uninitialised values come from
==8388== ERROR SUMMARY: 7 errors from 5 contexts (suppressed: 0 from 0)
^ permalink raw reply
* Re: [PATCH] Document git-svn fetch --log-window-size parameter
From: Eric Wong @ 2012-10-29 20:18 UTC (permalink / raw)
To: Jeff King; +Cc: Gunnlaugur Þór Briem, git
In-Reply-To: <20121026133250.GI1455@sigill.intra.peff.net>
Jeff King <peff@peff.net> wrote:
> On Fri, Oct 26, 2012 at 09:46:02AM +0000, Eric Wong wrote:
> > Overly large values also lead to excessive memory usage. I may have
> > only had 256M in my dev machine at the time I added this parameter:
>
> That's probably worth mentioning. Gunnlaugur, any objection to me
> amending your commit with:
Thanks both, I've amended and S-o-b on my end. Shall I add:
Signed-off-by: Jeff King <peff@peff.net>
and push?
^ permalink raw reply
* Re: Removing unreachable objects in the presence of broken links?
From: Geert Uytterhoeven @ 2012-10-29 19:56 UTC (permalink / raw)
To: Andreas Schwab; +Cc: git
In-Reply-To: <m2r4oiffgy.fsf@igel.home>
Hi Andreas,
On Sun, Oct 28, 2012 at 10:34 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> Geert Uytterhoeven <geert@linux-m68k.org> writes:
>
>> Is there a way to force removing unreachable objects in the presence of broken
>> links?
>
> Does it help to forcibly expire the reflogs?
You mean "git reflog expire --all --expire=0"?
After that the reflog is empty, but "git gc" still fails.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Aw: Re: [Patch 1/1] Wire html for all files in ./technical and ./howto in Makefile
From: Thomas Ackermann @ 2012-10-29 18:33 UTC (permalink / raw)
To: peff, th.acker66; +Cc: git, gitster
In-Reply-To: <20121025094205.GI8390@sigill.intra.peff.net>
This patch addresses Junios comment in WC:
"Misapplication of a patch fixed; the ones near the tip needs to
update the links to point at the html files, though."
See older mail in this thread:
---
Thomas Ackermann <th.acker66@arcor.de> writes:
> BTW1: As only the changes in the doc files where cherry-picked, currently on pu howto-index.sh
> will create invalid links in howto-index.html because it scans all .txt-files in ./howto for
> 'Content-type: text/asciidoc' and if found, creates a reference to a html file. But these are not created
> for the new asciidoc files. So the changes in Documentation/Makefile which create html for the new
> files should be merged also.
Ah, I didn't notice that.
That means that for the patch [6/8], which adds content-type to the
text files, to be complete, it needs to update Makefile to produce
html files from them.
Thanks.
---
So IMHO no open issues with this patch.
----- Original Nachricht ----
Von: Jeff King <peff@peff.net>
An: Thomas Ackermann <th.acker66@arcor.de>
Datum: 25.10.2012 11:42
Betreff: Re: [Patch 1/1] Wire html for all files in ./technical and ./howto
in Makefile
> On Tue, Oct 23, 2012 at 07:58:04PM +0200, Thomas Ackermann wrote:
>
> > - target "html" creates html for all files in Documentation/howto and
> > Documentation/technical
>
> Thanks.
>
---
Thomas
^ permalink raw reply
* Re: merge --no-commit not able to report stats more verbosely?
From: Phil Hord @ 2012-10-29 18:12 UTC (permalink / raw)
To: Jeff King; +Cc: Scott R. Godin, git
In-Reply-To: <20121028112150.GD11434@sigill.intra.peff.net>
On Sun, Oct 28, 2012 at 7:21 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 22, 2012 at 09:39:31AM -0400, Scott R. Godin wrote:
>
>> As you can see from the below, I can't seem to get it to give me more
>> verbose results of what's being merged (as in the actual merge below)
>> with --stat or -v .. is it supposed to do that?
>
> Yes. The diffstat is shown for the completed merge, but here:
>
>> (develop)>$ git merge --no-commit --stat -v widget_twitter
>> Automatic merge went well; stopped before committing as requested
>
> You do not complete the merge.
>
>> (develop|MERGING)>$ git merge --abort
>>
>> (develop)>$ git merge widget_twitter
>> Merge made by the 'recursive' strategy.
>> .../code/community/Dnd/Magentweet/Model/User.php | 3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> Whereas here you do, and you get a diffstat.
>
> When you are in the middle of an uncompleted merge and want to know what
> is happening, you should look at the index using "git status" (to get an
> overview of what is ready to be committed and what is unmerged), "git
> diff --cached" (to see what was automatically merged and is ready for
> commit), and "git diff" (to see conflicted entries that still need to be
> resolved).
I think he is looking for this bit
"Merge made by the 'recursive' strategy."
But he is seeing this instead:
"Automatic merge went well; stopped before committing as requested"
Should the "what happened" output be silenced on --no-commit?
Phil
^ permalink raw reply
* Re: [PATCHv2] git-status: show short sequencer state
From: Phil Hord @ 2012-10-29 18:05 UTC (permalink / raw)
To: Phil Hord
Cc: Jeff King, git, Junio C Hamano, konglu, Matthieu Moy, Kong Lucien,
Duperray Valentin, Jonas Franck, Nguy Thomas,
Nguyen Huynh Khoi Nguyen
In-Reply-To: <5089633C.8030307@cisco.com>
On Thu, Oct 25, 2012 at 12:05 PM, Phil Hord <hordp@cisco.com> wrote:
>
> Jeff King wrote:
>> On Tue, Oct 23, 2012 at 04:02:54PM -0400, Phil Hord wrote:
>>
>>> Teach git-status to report the sequencer state in short form
>>> using a new --sequencer (-S) switch. Output zero or more
>>> simple state token strings indicating the deduced state of the
>>> git sequencer.
>>>
>>> Introduce a common function to determine the current sequencer
>>> state so the regular status function and this short version can
>>> share common code.
>>>
>>> Add a substate to wt_status_state to track more detailed
>>> information about a state, such as "conflicted" or "resolved".
>>> Move the am_empty_patch flage out of wt_status_state and into
>> This patch ended up quite long. It might be a little easier to review
>> if it were broken into refactoring steps (I have not looked at it too
>> closely yet, but it seems like the three paragraphs above could each be
>> their own commit).
I'm currently splitting this out into a series and reconsidering some
of it along the way. I need some guidance.
I want to support these two modes:
A. 'git status --short' with sequence tokens added:
## conflicted
## merge
?? untracked-workdir-file
etc.
B. Same as (A) but without workdir status:
## conflicted
## merge
The user who wants 'A' would initiate it like this:
git status --sequencer
or
git status -S
How do I spell the options for 'B'? I have come up with these three
possibilities:
git --sequencer-only # Another switch
git --sequencer=only # An OPTARG parser
git -S -S # like git-diff -C -C, an OPT_COUNTUP
The first one is easy but weird, imho.
The second seems silly for just one type of option.
The last one is cheap to implement, but harder to explain in Documentation/
Any opinions?
Phil
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: Phil Hord @ 2012-10-29 17:38 UTC (permalink / raw)
To: Jeff King; +Cc: W. Trevor King, Shawn Pearce, Jens Lehmann, Git, Nahor
In-Reply-To: <20121029114310.GA16046@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 7:43 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 29, 2012 at 07:29:45AM -0400, W. Trevor King wrote:
>
>> On Mon, Oct 29, 2012 at 06:58:55AM -0400, Jeff King wrote:
>> > Can you send an updated version of the patch that summarizes the
>> > situation in the commit message?
>>
>> Sure. Should I include Phil's $submodule_<var-name> export, or would
>> you rather have that be a separate series?
>
> I think it probably makes sense as a separate patch in the same series,
> since it is meant to support the same workflows.
I agree. I did expect to clean it up some, but also to suffer some
review. Feel free to clean it up as you see fit and submit it with
your series.
> I am not sure it is sufficient as-is, though. It does not seem to ever
> clear variables, only set them, which means that values could leak
> across iterations of the loop, [...] E.g., when
> the first submodule has submodule.*.foo set but the second one does not,
> you will still end up with $submodule_foo set when you process the
> second one.
Good point. That should not happen.
> or down to recursive calls.
Frankly, I consider that to be a feature. However, I can see how it
would be considered inconsistent in many ways, so it's probably best
to squash it. :-\
Phil
^ permalink raw reply
* Re: git push tags
From: Kacper Kornet @ 2012-10-29 17:23 UTC (permalink / raw)
To: Jeff King
Cc: Drew Northup, Michael Haggerty, Angelo Borsotti, Philip Oakley,
Chris Rorvick, Johannes Sixt, git
In-Reply-To: <20121029113500.GA15597@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 07:35:00AM -0400, Jeff King wrote:
> On Mon, Oct 29, 2012 at 07:21:52AM -0400, Drew Northup wrote:
> > > I would have expected git to at least complain about updating an
> > > annotated tag with another annotated tag. But it actually uses the same
> > > fast-forward rule, just on the pointed-to commits. So a fast-forward
> > > annotated re-tag will throw away the old tag object completely. Which
> > > seems a bit crazy to me.
> > > It seems like a no-brainer to me that annotated tags should not replace
> > > each other without a force, no matter where in the refs hierarchy they
> > > go.
> > > For lightweight tags, I think it's more gray. They are just pointers
> > > into history. Some projects may use them to tag immutable official
> > > versions, but I also see them used as shared bookmarks. Requiring "-f"
> > > may make the latter use more annoying. On the other hand, bookmark tags
> > > tend not to be pushed, or if they are, it is part of a mirror-like
> > > backup which should be forcing all updates anyway.
> > Would that be an endorsement of continuing to build a patch set
> > including the snippet that Kacper posted earlier (1) in response to my
> > comment about not being sure how complicated all of this would be or
> > not?
> That patch just blocks non-forced updates to refs/tags/. I think a saner
> start would be to disallow updating non-commit objects without a force.
> We already do so for blobs and trees because they are not (and cannot
> be) fast forwards. The fact that annotated tags are checked for
> fast-forward seems to me to be a case of "it happens to work that way"
> and not anything planned. Since such a push drops the reference to the
> old version of the tag, it should probably require a force.
I'm not sure. Looking at 37fde87 ("Fix send-pack for non-commitish
tags.") I have an impression that Junio allowed for fast-forward pushes
of annotated tags on purpose.
> Then on top of that we can talk about what lightweight tags should do.
> I'm not sure. Following the regular fast-forward rules makes some sense
> to me, because you are never losing objects. But there may be
> complications with updating tags in general because of fetch's rules,
> and we would be better off preventing people from accidentally doing so.
> I think a careful review of fetch's tag rules would be in order before
> making any decision there.
The problem with the current behaviour is, that one can never be 100% sure
that his push will not overwrite someone else tag.
--
Kacper
^ permalink raw reply
* Re: Git clone fails with "bad pack header", how to get remote log
From: Konstantin Khomoutov @ 2012-10-29 17:18 UTC (permalink / raw)
To: git-users-/JYPxA39Uh5TLH3MbocFFw
Cc: Kevin Molcard, git-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <7f498800-ed38-474d-86ad-cb937be68173-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org>
On Mon, 29 Oct 2012 09:52:54 -0700 (PDT)
Kevin Molcard <kev2041-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> I have a problem with my build system.
>
> I have a remote server with a relatively large repository (around 12
> GB, each branch having a size of 3 GB).
>
> I have also 2 build servers (Mac, Windows) that are cloning the repo
> from the remote.
>
> Sometimes (very often when several git clone are sent at the same
> time), I have the following error:
>
> remote: internal server error
> fatal: protocol error: bad pack header
>
> I know that it happens when the remote is compressing objects (thanks
> to `--progress -v` flags) because the last line of the log before the
> erro is:
> remote: Compressing objects: 93% (17959/19284) [K
>
> * So I have 2 questions, does anybody what is the problem and what
> should I do?
> * Is there a way to get a more precise log from the remote to debug
> this problem?
This reminds me of a bug fixed in 1.7.12.1 [1]:
* When "git push" triggered the automatic gc on the receiving end, a
message from "git prune" that said it was removing cruft leaked to
the standard output, breaking the communication protocol.
In any case, bugs should be reported to the main Git list (which is
git at vger.kernel.org), not here.
I'm Cc'ing the main Git list so you'll get any responses from there, if
any.
Kevin, please answer to this message (keeping all the Ccs -- use "Reply
to group" or "Reply to all" in your MUA) and describe exactly what Git
versions on which platforms your have.
1. https://raw.github.com/git/git/master/Documentation/RelNotes/1.7.12.1.txt
--
You received this message because you are subscribed to the Google Groups "Git for human beings" group.
To post to this group, send email to git-users-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to git-users+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at http://groups.google.com/group/git-users?hl=en.
^ permalink raw reply
* [PATCH] gitweb.perl: fix %highlight_ext
From: rh @ 2012-10-29 16:42 UTC (permalink / raw)
To: git
I also consolidated exts where applicable.
i.e. c and h maps to c
--
diff --git a/a/gitweb.cgi b/b/gitweb.cgi
index 060db27..155b238 100755
--- a/a/gitweb.cgi
+++ b/b/gitweb.cgi
@@ -246,19 +246,19 @@ our %highlight_basename = (
'Makefile' => 'make',
);
# match by extension
+
our %highlight_ext = (
# main extensions, defining name of syntax;
# see files in /usr/share/highlight/langDefs/ directory
- map { $_ => $_ }
- qw(py c cpp rb java css php sh pl js tex bib xml awk bat ini spec tcl sql make),
+ (map { $_ => $_ } qw(py rb java css js tex bib xml awk bat ini spec tcl sql)),
# alternate extensions, see /etc/highlight/filetypes.conf
- 'h' => 'c',
- map { $_ => 'sh' } qw(bash zsh ksh),
- map { $_ => 'cpp' } qw(cxx c++ cc),
- map { $_ => 'php' } qw(php3 php4 php5 phps),
- map { $_ => 'pl' } qw(perl pm), # perhaps also 'cgi'
- map { $_ => 'make'} qw(mak mk),
- map { $_ => 'xml' } qw(xhtml html htm),
+ (map { $_ => 'c' } qw(c h)),
+ (map { $_ => 'sh' } qw(sh bash zsh ksh)),
+ (map { $_ => 'cpp' } qw(cpp cxx c++ cc)),
+ (map { $_ => 'php' } qw(php php3 php4 php5 phps)),
+ (map { $_ => 'pl' } qw(pl perl pm)), # perhaps also 'cgi'
+ (map { $_ => 'make'} qw(make mak mk)),
+ (map { $_ => 'xml' } qw(xml xhtml html htm)),
);
# You define site-wide feature defaults here; override them with
^ permalink raw reply related
* Re: Subtree in Git
From: dag @ 2012-10-29 15:55 UTC (permalink / raw)
To: David Michael Barr
Cc: Herman van Rink, Junio C Hamano, greened, Hilco Wijbenga,
Git Users
In-Reply-To: <2DDAA35052EA4F88A6EAC4FBDDF7FCCD@rr-dav.id.au>
David Michael Barr <b@rr-dav.id.au> writes:
> As I have an interest in git-subtree for maintaining the out-of-tree
> version of vcs-svn/ and a desire to improve my rebase-fu, I am tempted
> to make some sense of the organic growth that happened on GitHub.
> It doesn't appear that anyone else is willing to do this, so I doubt
> there will be any duplication of effort.
Go for it! Thanks!
-David
^ permalink raw reply
* Re: Subtree in Git
From: dag @ 2012-10-29 15:53 UTC (permalink / raw)
To: Herman van Rink; +Cc: Junio C Hamano, greened, Hilco Wijbenga, Git Users
In-Reply-To: <508A8BD3.9020901@initfour.nl>
Herman van Rink <rink@initfour.nl> writes:
> What would a random user have to do to get a patch in? I've found a
> number of subtree related mails on the git-user list go completely
> unanswerd. Amongst them a patch from James Nylen wich seems very
> reasonable.
I have those patches queued for merging. I've been out of town and
otherwise occupied with critical work issues. I'm hoping to process
those this weekend.
I don't consider myself a gatekeeper and I won't complain if git-subtree
patches are accepted without my review, especially if I am caught up in
other things as I am now. Anyone is welcome to prepare, review and
recommend patches for acceptance. Junio is the real boss anyway. :)
The whole point of Free Software is that anyone can contribute. It
won't work any other way.
But when patches clearly take us backward, yeah, I'm going to have an
issue with that. :)
-David
^ permalink raw reply
* Re: [PATCH v4 00/13] New remote-hg helper
From: Felipe Contreras @ 2012-10-29 14:56 UTC (permalink / raw)
To: Jeff King
Cc: git, Junio C Hamano, Sverre Rabbelier, Johannes Schindelin,
Ilari Liusvaara, Daniel Barkalow, Michael J Gruber
In-Reply-To: <20121029085045.GA5023@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 9:50 AM, Jeff King <peff@peff.net> wrote:
> On Sun, Oct 28, 2012 at 04:54:00AM +0100, Felipe Contreras wrote:
>
>> I've ported the tests from hg-git and made sure that the output from remote-hg
>> matches the output of hg-git. With these extensive tests I would consider this
>> one ready for wide use. Not only do the tests pass, I've compared the generated
>> repos of a few projects, and the SHA-1's are exactly the same :)
>
> Sounds cool. Unfortunately, the test script hangs for me, after starting
> up xxdiff (!).
>
> pstree reveals that it is "hg" that starts it, but I didn't investigate
> beyond that.
Yeah, the test script is not ready for merging, it needs to check for
python, hg, and hg-git.
Do you have hg-git installed?
These tests compare the output of hg-git with remote-hg. It would be
nice to have tests that don't require hg-git, but I think what is
there is more than worthy of getting merged to contrib. In fact, I'm
thinking it's ready to be out of contrib and installed by default
(once the hg-git tests have proper checks), but I haven't heard much
feedback.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* merge --squash strange error
From: Angelo Borsotti @ 2012-10-29 13:37 UTC (permalink / raw)
To: git
Hello,
I have got a case in which merge --squash issues an error that does
not exist. I hope I am wrong, though.
Consider the following example:
rm -rf public.git
rm -rf private
git init --bare public.git
git clone public.git private
cd private
touch f1; git add f1; git commit -m A
git checkout -b b1
touch f2; git add f2; git commit -m B
git checkout master
git checkout -b b2
touch f3; git add f3; git commit -m C
git checkout master
git checkout -b b3
touch f4; git add f4; git commit -m D
--- at this point we have
A (f1) master
|--B (f1,f2) b1
|--C (f1,f3) b2
`--D (f1,f4) *b3
git merge --squash b1
git merge --squash b2
The first merge adds f2 to the workspace, which then contains f1, f2 and f4.
The second merge should add f3, and instead it complains:
error: Your local changes to the following files would be overwritten by merge:
f2
Please, commit your changes or stash them before you can merge.
Aborting
Why should it overwrite f2, and with what?
-Angelo
^ permalink raw reply
* Re: git push tags
From: Angelo Borsotti @ 2012-10-29 13:24 UTC (permalink / raw)
To: Jeff King
Cc: Drew Northup, Michael Haggerty, Philip Oakley, Chris Rorvick,
Johannes Sixt, git
In-Reply-To: <20121029113500.GA15597@sigill.intra.peff.net>
Jeff,
> Then on top of that we can talk about what lightweight tags should do.
> I'm not sure.
If tags (even the lightweight ones) do not behave differently from
branches, then they are of no use, and the main difference is that
they do not move. So, I would suggest not to move them either.
-Angelo
^ permalink raw reply
* [PATCHv2] replace: parse revision argument for -d
From: Michael J Gruber @ 2012-10-29 13:23 UTC (permalink / raw)
To: git; +Cc: Jeff King
In-Reply-To: <508E55B2.6060502@drmicha.warpmail.net>
'git replace' parses the revision arguments when it creates replacements
(so that a sha1 can be abbreviated, e.g.) but not when deleting
replacements.
Make it parse the arguments to 'replace -d' in the same way.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
v2 has the simplified error check as per Jeff, and a reworded message.
Comes with a free test case, too.
builtin/replace.c | 14 ++++++++------
t/t6050-replace.sh | 11 +++++++++++
2 files changed, 19 insertions(+), 6 deletions(-)
diff --git a/builtin/replace.c b/builtin/replace.c
index e3aaf70..7b00055 100644
--- a/builtin/replace.c
+++ b/builtin/replace.c
@@ -46,24 +46,26 @@ typedef int (*each_replace_name_fn)(const char *name, const char *ref,
static int for_each_replace_name(const char **argv, each_replace_name_fn fn)
{
- const char **p;
+ const char **p, *q;
char ref[PATH_MAX];
int had_error = 0;
unsigned char sha1[20];
for (p = argv; *p; p++) {
- if (snprintf(ref, sizeof(ref), "refs/replace/%s", *p)
- >= sizeof(ref)) {
- error("replace ref name too long: %.*s...", 50, *p);
+ q = *p;
+ if (get_sha1(q, sha1)) {
+ error("Failed to resolve '%s' as a valid ref.", q);
had_error = 1;
continue;
}
+ q = sha1_to_hex(sha1);
+ snprintf(ref, sizeof(ref), "refs/replace/%s", q);
if (read_ref(ref, sha1)) {
- error("replace ref '%s' not found.", *p);
+ error("replace ref '%s' not found.", q);
had_error = 1;
continue;
}
- if (fn(*p, ref, sha1))
+ if (fn(q, ref, sha1))
had_error = 1;
}
return had_error;
diff --git a/t/t6050-replace.sh b/t/t6050-replace.sh
index 5c87f28..decdc33 100755
--- a/t/t6050-replace.sh
+++ b/t/t6050-replace.sh
@@ -140,6 +140,17 @@ test_expect_success '"git replace" replacing' '
test "$HASH2" = "$(git replace)"
'
+test_expect_success '"git replace" resolves sha1' '
+ SHORTHASH2=$(git rev-parse --short=8 $HASH2) &&
+ git replace -d $SHORTHASH2 &&
+ git replace $SHORTHASH2 $R &&
+ git show $HASH2 | grep "O Thor" &&
+ test_must_fail git replace $HASH2 $R &&
+ git replace -f $HASH2 $R &&
+ test_must_fail git replace -f &&
+ test "$HASH2" = "$(git replace)"
+'
+
# This creates a side branch where the bug in H2
# does not appear because P2 is created by applying
# H2 and squashing H5 into it.
--
1.8.0.370.g8cbad08
^ permalink raw reply related
* Re: git push tags
From: Drew Northup @ 2012-10-29 12:25 UTC (permalink / raw)
To: Jeff King
Cc: Michael Haggerty, Angelo Borsotti, Philip Oakley, Chris Rorvick,
Johannes Sixt, git, Kacper Kornet
In-Reply-To: <20121029113500.GA15597@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 7:35 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 29, 2012 at 07:21:52AM -0400, Drew Northup wrote:
>> > I would have expected git to at least complain about updating an
>> > annotated tag with another annotated tag. But it actually uses the same
>> > fast-forward rule, just on the pointed-to commits. So a fast-forward
>> > annotated re-tag will throw away the old tag object completely. Which
>> > seems a bit crazy to me.
>> >
>> > It seems like a no-brainer to me that annotated tags should not replace
>> > each other without a force, no matter where in the refs hierarchy they
>> > go.
>> >
>> > For lightweight tags, I think it's more gray. They are just pointers
>> > into history. Some projects may use them to tag immutable official
>> > versions, but I also see them used as shared bookmarks. Requiring "-f"
>> > may make the latter use more annoying. On the other hand, bookmark tags
>> > tend not to be pushed, or if they are, it is part of a mirror-like
>> > backup which should be forcing all updates anyway.
>>
>> Would that be an endorsement of continuing to build a patch set
>> including the snippet that Kacper posted earlier (1) in response to my
>> comment about not being sure how complicated all of this would be or
>> not?
>
> That patch just blocks non-forced updates to refs/tags/. I think a saner
> start would be to disallow updating non-commit objects without a force.
> We already do so for blobs and trees because they are not (and cannot
> be) fast forwards. The fact that annotated tags are checked for
> fast-forward seems to me to be a case of "it happens to work that way"
> and not anything planned. Since such a push drops the reference to the
> old version of the tag, it should probably require a force.
>
> Then on top of that we can talk about what lightweight tags should do.
> I'm not sure. Following the regular fast-forward rules makes some sense
> to me, because you are never losing objects. But there may be
> complications with updating tags in general because of fetch's rules,
> and we would be better off preventing people from accidentally doing so.
> I think a careful review of fetch's tag rules would be in order before
> making any decision there.
>
> -Peff
Thanks, I had the sinking suspicion that this was going to be more complicated.
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: Jeff King @ 2012-10-29 11:43 UTC (permalink / raw)
To: W. Trevor King; +Cc: Shawn Pearce, Jens Lehmann, Git, Nahor, Phil Hord
In-Reply-To: <20121029112945.GD2424@odin.tremily.us>
On Mon, Oct 29, 2012 at 07:29:45AM -0400, W. Trevor King wrote:
> On Mon, Oct 29, 2012 at 06:58:55AM -0400, Jeff King wrote:
> > Can you send an updated version of the patch that summarizes the
> > situation in the commit message?
>
> Sure. Should I include Phil's $submodule_<var-name> export, or would
> you rather have that be a separate series?
I think it probably makes sense as a separate patch in the same series,
since it is meant to support the same workflows.
I am not sure it is sufficient as-is, though. It does not seem to ever
clear variables, only set them, which means that values could leak
across iterations of the loop, or down to recursive calls. E.g., when
the first submodule has submodule.*.foo set but the second one does not,
you will still end up with $submodule_foo set when you process the
second one.
-Peff
^ permalink raw reply
* Re: git push tags
From: Jeff King @ 2012-10-29 11:35 UTC (permalink / raw)
To: Drew Northup
Cc: Michael Haggerty, Angelo Borsotti, Philip Oakley, Chris Rorvick,
Johannes Sixt, git
In-Reply-To: <CAM9Z-nkf84cV2bYp=NL8an5DjvwP+jL7icb+jwizjHeaq40VhA@mail.gmail.com>
On Mon, Oct 29, 2012 at 07:21:52AM -0400, Drew Northup wrote:
> > I would have expected git to at least complain about updating an
> > annotated tag with another annotated tag. But it actually uses the same
> > fast-forward rule, just on the pointed-to commits. So a fast-forward
> > annotated re-tag will throw away the old tag object completely. Which
> > seems a bit crazy to me.
> >
> > It seems like a no-brainer to me that annotated tags should not replace
> > each other without a force, no matter where in the refs hierarchy they
> > go.
> >
> > For lightweight tags, I think it's more gray. They are just pointers
> > into history. Some projects may use them to tag immutable official
> > versions, but I also see them used as shared bookmarks. Requiring "-f"
> > may make the latter use more annoying. On the other hand, bookmark tags
> > tend not to be pushed, or if they are, it is part of a mirror-like
> > backup which should be forcing all updates anyway.
>
> Would that be an endorsement of continuing to build a patch set
> including the snippet that Kacper posted earlier (1) in response to my
> comment about not being sure how complicated all of this would be or
> not?
That patch just blocks non-forced updates to refs/tags/. I think a saner
start would be to disallow updating non-commit objects without a force.
We already do so for blobs and trees because they are not (and cannot
be) fast forwards. The fact that annotated tags are checked for
fast-forward seems to me to be a case of "it happens to work that way"
and not anything planned. Since such a push drops the reference to the
old version of the tag, it should probably require a force.
Then on top of that we can talk about what lightweight tags should do.
I'm not sure. Following the regular fast-forward rules makes some sense
to me, because you are never losing objects. But there may be
complications with updating tags in general because of fetch's rules,
and we would be better off preventing people from accidentally doing so.
I think a careful review of fetch's tag rules would be in order before
making any decision there.
-Peff
^ permalink raw reply
* Re: git push tags
From: Angelo Borsotti @ 2012-10-29 11:31 UTC (permalink / raw)
To: Drew Northup
Cc: Jeff King, Michael Haggerty, Philip Oakley, Chris Rorvick,
Johannes Sixt, git
In-Reply-To: <CAM9Z-nkf84cV2bYp=NL8an5DjvwP+jL7icb+jwizjHeaq40VhA@mail.gmail.com>
Hi Drew,
sure. That is a good starting point. I would suggest to block tag
updates of existing tags if a dedicated option is present in the
config of the remote repo, like, e.g. pushOverwriteTags.
-Angelo
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: W. Trevor King @ 2012-10-29 11:29 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Jens Lehmann, Git, Nahor, Phil Hord
In-Reply-To: <20121029105855.GA15075@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 582 bytes --]
On Mon, Oct 29, 2012 at 06:58:55AM -0400, Jeff King wrote:
> Can you send an updated version of the patch that summarizes the
> situation in the commit message?
Sure. Should I include Phil's $submodule_<var-name> export, or would
you rather have that be a separate series?
Phil, were you planning on rolling your patch into something more
formal, or was your preliminary patch a suggestion for me to build
from?
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: git push tags
From: Drew Northup @ 2012-10-29 11:21 UTC (permalink / raw)
To: Jeff King
Cc: Michael Haggerty, Angelo Borsotti, Philip Oakley, Chris Rorvick,
Johannes Sixt, git
In-Reply-To: <20121029103837.GA14614@sigill.intra.peff.net>
On Mon, Oct 29, 2012 at 6:38 AM, Jeff King <peff@peff.net> wrote:
> On Mon, Oct 29, 2012 at 10:58:07AM +0100, Michael Haggerty wrote:
>
>> I agree with you that it is too easy to create chaos by changing tags in
>> a published repository and that git should do more to prevent this from
>> happening without explicit user forcing. The fact that git internally
>> handles tags similarly to other references is IMO an excuse for the
>> current behavior, but not a justification.
>
> I would have expected git to at least complain about updating an
> annotated tag with another annotated tag. But it actually uses the same
> fast-forward rule, just on the pointed-to commits. So a fast-forward
> annotated re-tag will throw away the old tag object completely. Which
> seems a bit crazy to me.
>
> It seems like a no-brainer to me that annotated tags should not replace
> each other without a force, no matter where in the refs hierarchy they
> go.
>
> For lightweight tags, I think it's more gray. They are just pointers
> into history. Some projects may use them to tag immutable official
> versions, but I also see them used as shared bookmarks. Requiring "-f"
> may make the latter use more annoying. On the other hand, bookmark tags
> tend not to be pushed, or if they are, it is part of a mirror-like
> backup which should be forcing all updates anyway.
Would that be an endorsement of continuing to build a patch set
including the snippet that Kacper posted earlier (1) in response to my
comment about not being sure how complicated all of this would be or
not?
[1] http://article.gmane.org/gmane.comp.version-control.git/208473
--
-Drew Northup
--------------------------------------------------------------
"As opposed to vegetable or mineral error?"
-John Pescatore, SANS NewsBites Vol. 12 Num. 59
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: Jeff King @ 2012-10-29 10:58 UTC (permalink / raw)
To: W. Trevor King; +Cc: Shawn Pearce, Jens Lehmann, Git, Nahor, Phil Hord
In-Reply-To: <20121029104544.GA2424@odin.tremily.us>
On Mon, Oct 29, 2012 at 06:45:44AM -0400, W. Trevor King wrote:
> > > Ah, good, then we *are* all using the option for the same thing.
> >
> > That makes me more comfortable. Your patch adds support for setting the
> > variable initially. Does it need any special magic for maintenance, or
> > is it something that would always be updated by hand?
>
> Everyone we've heard from so far interprets the setting as “pull from
> $branch in the remote repository $url to update the submodule”. With
> Phil's export, that would become
>
> $ git submodule foreach 'git checkout "$submodule_branch" && git pull'
> $ git commit -a -m "Updated submodules"
> $ git push
>
> As Nahor mentioned on the 23rd, there are a number of ways that the
> upstream branch could disappear, but Git has no way to know what the
> new branch setting should be. This means that even if we make “pull
> from $branch” interpretation official, we still couldn't do anything
> slick about updating it. So, yes, it will be updated by hand.
OK.
Can you send an updated version of the patch that summarizes the
situation in the commit message?
I also think it is probably worth saying something in the documentation
for the feature like "Note that this value is not actually used by git;
however, some external tools and workflows may make use of it."
-Peff
^ permalink raw reply
* Re: [PATCH v2] git-submodule add: Add -r/--record option.
From: W. Trevor King @ 2012-10-29 10:45 UTC (permalink / raw)
To: Jeff King; +Cc: Shawn Pearce, Jens Lehmann, Git, Nahor, Phil Hord
In-Reply-To: <20121029053401.GB30186@sigill.intra.peff.net>
[-- Attachment #1: Type: text/plain, Size: 1647 bytes --]
On Mon, Oct 29, 2012 at 01:34:01AM -0400, Jeff King wrote:
> On Sun, Oct 28, 2012 at 06:34:31PM -0400, W. Trevor King wrote:
>
> > On Sun, Oct 28, 2012 at 02:59:33PM -0700, Shawn Pearce wrote:
> > > Looks like the Gerrit meaning is basically the same as Ævar's. Gerrit
> > > updates the parent project as if you had done:
> > >
> > > $ git submodule foreach 'git checkout $(git config --file
> > > $toplevel/.gitmodules submodule.$name.branch) && git pull'
> > > $ git commit -a -m "Updated submodules"
> > > $ git push
> >
> > Ah, good, then we *are* all using the option for the same thing.
>
> That makes me more comfortable. Your patch adds support for setting the
> variable initially. Does it need any special magic for maintenance, or
> is it something that would always be updated by hand?
Everyone we've heard from so far interprets the setting as “pull from
$branch in the remote repository $url to update the submodule”. With
Phil's export, that would become
$ git submodule foreach 'git checkout "$submodule_branch" && git pull'
$ git commit -a -m "Updated submodules"
$ git push
As Nahor mentioned on the 23rd, there are a number of ways that the
upstream branch could disappear, but Git has no way to know what the
new branch setting should be. This means that even if we make “pull
from $branch” interpretation official, we still couldn't do anything
slick about updating it. So, yes, it will be updated by hand.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ 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