* Re: [PATCHv2 0/13] credential helpers
From: Jeff King @ 2011-12-09 23:39 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vehwdcob3.fsf@alter.siamese.dyndns.org>
On Fri, Dec 09, 2011 at 03:34:08PM -0800, Junio C Hamano wrote:
> > We _could_ modify credential_match() to automatically reject such a
> > pattern at that level,...
>
> I do not think that is such a good idea to modify "match()" function
> either, as I agree match with empty has its uses, but that does not stop
> "rewrite_credential_file()" from being safe by default, no? After all, the
> one that makes the decision to drop things that match the pattern is that
> function (it chooses to give NULL to match_cb).
Yeah, you could move it down to that level, but there isn't much point.
rewrite_credential_file is unique to credential-store, and the only two
callers are store_credential (which has its own, stricter rules already)
and remove_credential, which we are modifying here.
Note that I didn't bother with the same safety valve for
credential-cache. It is, after all, a cache that will go away eventually
anyway, so safety is less interesting.
Third-party helpers will have to do their own checks anyway, as in
general I don't plan on them linking directly against git code.
Speaking of which, I hackishly ported Jay's osxkeychain helper to the
new format last night. I'll try to clean that up and post it tonight.
-Peff
^ permalink raw reply
* [PATCH 0/4] git-p4: paths for p4
From: Pete Wyckoff @ 2011-12-09 23:48 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons, Junio C Hamano
There are two problems associated with how we set up paths for
use by p4, fixed in this series. Each fix is accompanied by
another patch that is the unit test.
There is a break in the sequence in the t98* patches here, but
that is on purpose to avoid collision with new tests from other
in-flight patches.
1-2:
in submit, create clientPath if it does not exist
3-4:
in clone, make sure p4 sees an absolute path
Gary Gibbons (2):
git-p4: ensure submit clientPath exists before chdir
git-p4: use absolute directory for PWD env var
Pete Wyckoff (2):
git-p4: submit test for auto-creating clientPath
git-p4: test for absolute PWD problem
contrib/fast-import/git-p4 | 9 ++++++-
t/t9807-submit.sh | 38 ++++++++++++++++++++++++++++++++++
t/t9808-chdir.sh | 49 ++++++++++++++++++++++++++++++++++++++++++++
3 files changed, 94 insertions(+), 2 deletions(-)
create mode 100755 t/t9807-submit.sh
create mode 100755 t/t9808-chdir.sh
--
1.7.8.rc4.42.g8317d
^ permalink raw reply
* [PATCH 1/4] git-p4: ensure submit clientPath exists before chdir
From: Pete Wyckoff @ 2011-12-09 23:48 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons, Junio C Hamano
In-Reply-To: <1323474497-14339-1-git-send-email-pw@padd.com>
From: Gary Gibbons <ggibbons@perforce.com>
Submitting patches back to p4 requires a p4 "client". This
is a mapping from server depot paths into a local directory.
The directory need not exist or be populated with files; only
the mapping on the server is required. When there is no
directory, make git-p4 automatically create it.
[ reword description --pw ]
Signed-off-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index b975d67..99d3abe 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -1099,6 +1099,10 @@ class P4Submit(Command, P4UserMap):
print "Perforce checkout for depot path %s located at %s" % (self.depotPath, self.clientPath)
self.oldWorkingDirectory = os.getcwd()
+ # ensure the clientPath exists
+ if not os.path.exists(self.clientPath):
+ os.makedirs(self.clientPath)
+
chdir(self.clientPath)
print "Synchronizing p4 checkout..."
p4_sync("...")
--
1.7.8.rc4.42.g8317d
^ permalink raw reply related
* [PATCH 2/4] git-p4: submit test for auto-creating clientPath
From: Pete Wyckoff @ 2011-12-09 23:48 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons, Junio C Hamano
In-Reply-To: <1323474497-14339-1-git-send-email-pw@padd.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9807-submit.sh | 38 ++++++++++++++++++++++++++++++++++++++
1 files changed, 38 insertions(+), 0 deletions(-)
create mode 100755 t/t9807-submit.sh
diff --git a/t/t9807-submit.sh b/t/t9807-submit.sh
new file mode 100755
index 0000000..85ab0d0
--- /dev/null
+++ b/t/t9807-submit.sh
@@ -0,0 +1,38 @@
+#!/bin/sh
+
+test_description='git-p4 submit'
+
+. ./lib-git-p4.sh
+
+test_expect_success 'start p4d' '
+ start_p4d
+'
+
+test_expect_success 'init depot' '
+ (
+ cd "$cli" &&
+ echo file1 >file1 &&
+ p4 add file1 &&
+ p4 submit -d "change 1"
+ )
+'
+
+test_expect_success 'submit with no client dir' '
+ test_when_finished cleanup_git &&
+ "$GITP4" clone --dest="$git" //depot &&
+ (
+ cd "$git" &&
+ echo file2 >file2 &&
+ git add file2 &&
+ git commit -m "git commit 2" &&
+ rm -rf "$cli" &&
+ git config git-p4.skipSubmitEdit true &&
+ "$GITP4" submit
+ )
+'
+
+test_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
1.7.8.rc4.42.g8317d
^ permalink raw reply related
* [PATCH 3/4] git-p4: use absolute directory for PWD env var
From: Pete Wyckoff @ 2011-12-09 23:48 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons, Junio C Hamano
In-Reply-To: <1323474497-14339-1-git-send-email-pw@padd.com>
From: Gary Gibbons <ggibbons@perforce.com>
P4 only looks at the environment variable $PWD to figure out
where it is, so chdir() has code to set that every time. But
when the clone --destination is not an absolute path, PWD will
not be absolute and P4 won't be able to find any files expected
to be in the current directory. Fix this by expanding PWD to
an absolute path.
One place this crops up is when using a P4CONFIG environment
variable to specify P4 parameters, such as P4USER or P4PORT.
Setting P4CONFIG=.p4config works for p4 invocations from the
current directory. But if the value of PWD is not absolute, it
fails.
[ update description --pw ]
Signed-off-by: Gary Gibbons <ggibbons@perforce.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
contrib/fast-import/git-p4 | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/contrib/fast-import/git-p4 b/contrib/fast-import/git-p4
index 99d3abe..0083f86 100755
--- a/contrib/fast-import/git-p4
+++ b/contrib/fast-import/git-p4
@@ -53,9 +53,10 @@ def p4_build_cmd(cmd):
def chdir(dir):
# P4 uses the PWD environment variable rather than getcwd(). Since we're
- # not using the shell, we have to set it ourselves.
- os.environ['PWD']=dir
+ # not using the shell, we have to set it ourselves. This path could
+ # be relative, so go there first, then figure out where we ended up.
os.chdir(dir)
+ os.environ['PWD'] = os.getcwd()
def die(msg):
if verbose:
--
1.7.8.rc4.42.g8317d
^ permalink raw reply related
* [PATCH 4/4] git-p4: test for absolute PWD problem
From: Pete Wyckoff @ 2011-12-09 23:48 UTC (permalink / raw)
To: git; +Cc: Gary Gibbons, Junio C Hamano
In-Reply-To: <1323474497-14339-1-git-send-email-pw@padd.com>
Signed-off-by: Pete Wyckoff <pw@padd.com>
---
t/t9808-chdir.sh | 49 +++++++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 49 insertions(+), 0 deletions(-)
create mode 100755 t/t9808-chdir.sh
diff --git a/t/t9808-chdir.sh b/t/t9808-chdir.sh
new file mode 100755
index 0000000..e6fd681
--- /dev/null
+++ b/t/t9808-chdir.sh
@@ -0,0 +1,49 @@
+#!/bin/sh
+
+test_description='git-p4 relative chdir'
+
+. ./lib-git-p4.sh
+
+test_expect_success 'start p4d' '
+ start_p4d
+'
+
+test_expect_success 'init depot' '
+ (
+ cd "$cli" &&
+ echo file1 >file1 &&
+ p4 add file1 &&
+ p4 submit -d "change 1"
+ )
+'
+
+# P4 reads from P4CONFIG file to find its server params, if the
+# environment variable is set
+test_expect_success 'P4CONFIG and absolute dir clone' '
+ printf "P4PORT=$P4PORT\nP4CLIENT=$P4CLIENT\n" >p4config &&
+ test_when_finished "rm \"$TRASH_DIRECTORY/p4config\"" &&
+ test_when_finished cleanup_git &&
+ (
+ P4CONFIG=p4config && export P4CONFIG &&
+ unset P4PORT P4CLIENT &&
+ "$GITP4" clone --verbose --dest="$git" //depot
+ )
+'
+
+# same thing, but with relative directory name, note missing $ on --dest
+test_expect_success 'P4CONFIG and relative dir clone' '
+ printf "P4PORT=$P4PORT\nP4CLIENT=$P4CLIENT\n" >p4config &&
+ test_when_finished "rm \"$TRASH_DIRECTORY/p4config\"" &&
+ test_when_finished cleanup_git &&
+ (
+ P4CONFIG=p4config && export P4CONFIG &&
+ unset P4PORT P4CLIENT &&
+ "$GITP4" clone --verbose --dest="git" //depot
+ )
+'
+
+test_expect_success 'kill p4d' '
+ kill_p4d
+'
+
+test_done
--
1.7.8.rc4.42.g8317d
^ permalink raw reply related
* Re: [PATCHv2 0/13] credential helpers
From: Junio C Hamano @ 2011-12-09 23:56 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20111209233957.GC10560@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Speaking of which, I hackishly ported Jay's osxkeychain helper to the
> new format last night. I'll try to clean that up and post it tonight.
;-).
^ permalink raw reply
* Re: Auto update submodules after merge and reset
From: Phil Hord @ 2011-12-09 23:57 UTC (permalink / raw)
To: andreas.t.auer_gtml_37453; +Cc: Jens Lehmann, git
In-Reply-To: <4EE07FCD.8090702@ursus.ath.cx>
On Thu, Dec 8, 2011 at 4:13 AM, <andreas.t.auer_gtml_37453@ursus.ath.cx> wrote:
>
> On 07.12.2011 23:23 Jens Lehmann wrote:
>> > If you have tracking branches, the supermodule can just update the
>> > corresponding branch. If this branch is currently checkedout and
>> > the work area is clean, then the work area is updated, too. If
>> > there is currently a local branch or a diffent super-branch
>> > checked out then the working area should be considered "detached"
>> > from the superproject and not updated.
>>
>> This sounds a lot like the "follow branch tip" model we discussed
>> recently (which could be configured via .gitmodules), but I'm not
>> sure you really are in the same boat here.
>
> When I understood that correctly it was just a configuration to what branch
> should be automatically checked out in the submodule. This seems to be too
> complicated IMO, because when you have different branches in the
> superproject then you may want to have different branches in the submodules,
> too, but you would need to configure that submodule branch in .gitmodules
> for each branch separately. I.e. in the master branch the .gitmodule may
> contain "master", in the maint branch the .gitmodules may have "maint" as
> the branch to follow.
Yes, but maybe you can update this information in the .gitmodules file
easily with a command. Maybe it could be something simpler than "git
sync-gitmodules-branches", but that is essentially what it would do:
it would save the current branch in each submodule as the "tracked"
branch in the .gitmodules file.
The advantages to this, I think, are that
1. Your "submodule A follows branch X" information is explicit in the
.gitmodules file and so it is not hidden when I examine your patch.
(It sounds to me like the refs/super/* branches would necessarily be
hard to find since the refs/ hierarchy is usually meta data about
local and remote branches. Maybe I should think about tags and notes
more, though.)
2. When you change to "submodule A now follows branch Y", this
information can be unambiguously saved in the commit where it occurred
rather than tucked away, again, in refs/super/*.
The disadvantage, maybe, are that you must now use 'git submodule
sync' or something like that to put any .gitmodules changes into
effect.
Or maybe that is an advantage. How often will this branch tracking change?
I like where you are going, though. But I have trouble following your
meaning when you toss around words like "ref" and "HEAD" and "branch"
and "super-branch". Maybe we can set up a strawman repo (virtually or
on github) where you can explain what happens now and what you wish
would happen instead.
For example, I have some repos like this:
super
+--subA
+--subB
I wish I could do this:
cd super && checkout master
to get this:
super (master)
+--subA (master)
+--subB (master)
Or, if I have SubB on super/'master' tracking 'foo', I could get this:
super (master)
+--subA (master)
+--subB (foo)
And I wish these commands would work as if this was all one repository:
cd super && git diff master maint
cd super && git grep foo
cd subA && git grep foo -- :/
cd super && git status
cd subA && git status
But I wonder what this would do:
cd super && git remote -v &&
cd subA && git remote -v
> I do want to follow the tip of the branch, if the superproject has that
> currently checked out. If the superproject checks out a tagged version for a
> rebuild, then the submodule should not follow the tip, but should get a
> detached HEAD of the corresponding commit, just as the superproject. When
> the superproject goes back to the branch, the submodule should go back to
> its tracking branch.
Now this makes sense. I want the same thing. I want to preserve
history on "old" commits, but I want to "advance to tip" on "new"
commits.
The trouble, I think, is in telling the difference between "old" and
"new". I think it means there is a switch, like --auto-follow (or
--no-auto-follow for the alternate if core.auto_follow is set). But
having a config option as the default is likely to break lots of
scripts.
So maybe I need a new command that does this:
git checkout master && git submodule foreach 'git checkout master'
Maybe it's called "git checkout master --recurse-submodules". But I
seem to recall this is already a non-starter for some reason, and
anyway it doesn't solve the "variant branches in some submodules"
problem.
Which brings us back to .gitmodules.
>> > With this concept you could even switch branches in the
>> > superproject and the attached submodules follow - still having no
>> > detached HEAD. When you want to do some local work on the
>> > submodule you checkout a local branch and merge back into the super
>> > branch later.
>>
>> You lost me here. How can you merge a submodule branch into one of
>> the superproject?
>
> It wouldn't work, if the super/* branch would contain a superproject's
> SHA-1, that is right. But as explained above, it points to a commit of the
> submodule.
>>
>>
>> But we would want to have a deterministic update procedure, no? (And
>> what has more freedom than a detached HEAD? ;-)__
>
> I think my proposal would be deterministic.
> And everything where you can commit to has more freedom than a detached HEAD
You can commit to a detached HEAD. I do it all the time. The trick
is in not switching away from a detached HEAD with your local commits
still on it. :-)
>> > Even though it will raise a lot of detailed questions like "should
>> > the refs/super/* be pushed/pulled when syncing the submodule
>> > repositories".
>>
>> I doubt that is a good idea, as that might conflict with the same
>> submodule sitting in a different superproject. But I'm interested to
>> hear how you want to solve that.
>
> The first answer to my question was "yes, you need to transfer the refs or
> you get unreferenced objects" and "no, you can't transfer the refs, because
> they are owned by the superproject, not the submodule."
> But binding a submodule to a superproject makes perfect sense if it is _one_
> project that is split into submodules. In that case you only have one
> superproject for a submodule and for that purpose it would be good workflow.
This is not useful to me, though. Sorry.
> It is even nice to see which commits in the submodule belong to what
> branches in the superproject or to what release version (so tracking
> superproject tags would make sense, too). If you have a submodule that has
> more than one superproject but these are well-defined, it could be solved
> using refspecs (e.g. refs/super/foo/* for one and refs/super/bar/* for the
> other superproject), but currently I can't think of a context where this
> makes sense.
I can, but this does put the cart before the horse. The submodule is
subservient to the super project in all my setups. The submodule is
not aware who owns him. He is a bit like the DAG in reverse. He
knows one direction only (children), not the other (parents).
Phil
^ permalink raw reply
* Re: [PATCH 4/7] refactor git_getpass into generic prompt function
From: Junio C Hamano @ 2011-12-09 23:58 UTC (permalink / raw)
To: Jeff King; +Cc: git, Erik Faye-Lund
In-Reply-To: <20111208083133.GD26409@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 2. The first series had a special "name" parameter just for generating
> error messages. This drops it in the name of simplicity, so error
> messages have gone from (assuming you don't have a tty):
>
> Could not read password: No such device or address
>
> to:
>
> Could not read 'Username for 'https://example.com': ': No such
> device or address
>
> which is verbose, yes, but contains a little more useful
> information. The formatting is rather unfortunate,...
It also would be unpleasant to i18n it, I suspect.
> + r = getpass(prompt);
> + if (!r)
> + die_errno("could not read '%s'", prompt);
Taking advantage of the "prompt-string"-ness of the message, this might be
a cuter workaround:
fatal: Password: <<could not be read>>
But I do not think it matters that much. Let's queue what you have, and
work out these details in-tree.
^ permalink raw reply
* Re: [PATCH] Set hard limit on delta chain depth
From: Junio C Hamano @ 2011-12-10 0:02 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy; +Cc: git
In-Reply-To: <CACsJy8AZg3DgZzmPyXhCH9bGBqo9UN7-zLt_feTtpyajf5U1tw@mail.gmail.com>
Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
> That's interesting. First of all xmalloc() is controlled by us while
> index-pack code might lead to stack overflow exploit (never done it,
> not sure if it's really pratical to do in this case).
What do you exactly mean by "stack overflow exploit"?
If your callee has prepares a stackframe that is not sufficiently big but
carelessly tries to store more than it has space for, such a write can
overflow the stack (without hardware traps) and overwrite return address,
and instead of coming back to you, the control can be transferred to
random places.
But I do not think that is what we are talking about here.
You attempt to write parameters and return address to the area of memory
pointed by your stack pointer, advance the stack pointer to create a stack
frame and the callee attempts to write to its local variables in the newly
allocated stack frame. These memory accesses eventually attempt to touch
memory beyond the address range the kernel gave you page table entries to
be used as your stack space, and hardware traps. If you haven't run out of
the stack, a new page is lazily added to the page table and your attempted
access will succeed. If you are recursing too deeply, you won't be given a
new page and you will be killed by the kernel. That is a rather controlled
death of the process, unlike smashing the contents of the stack to jump to
a randomly chosen place, isn't it?
Of course, some platforms do not have an unwritable gap between the stack
segment that grow downwards and the heap that grow upwards, and also your
stackframe could be larger than such a gap (in this particular callchain I
do not think that is the case), so the above discussion does not apply
universally, though.
^ permalink raw reply
* Bug in filter-branch example for moving into a subdirectory
From: Jesse Keating @ 2011-12-10 0:07 UTC (permalink / raw)
To: git
I ran into a bug with the example in the man page for filter-branch, for moving everything into a subdir:
git filter-branch --index-filter \
'git ls-files -s | sed "s-\t\"*-&newsubdir/-" |
GIT_INDEX_FILE=$GIT_INDEX_FILE.new \
git update-index --index-info &&
mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE"' HEAD
The problem seems to be when a commit happens that is just a file removal with no added file. In those cases, git ls-files doesn't output anything. Trying to throw a -d option in doesn't seem to improve matters.
So the problem is that if a commit is just file removals, this example will actually crash. Unfortunately I don't have a suggested solution at the moment.
--
Jesse Keating
Fedora -- Freedom² is a feature!
identi.ca: http://identi.ca/jkeating
^ permalink raw reply
* What's cooking in git.git (Dec 2011, #03; Fri, 9)
From: Junio C Hamano @ 2011-12-10 0:09 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in
'next'.
Two of the more important topics slated for 1.7.9 have been merged to
'master'. Let's hope the other ones also will stabilize soonish, so that
we can smoothly close this cycle early.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint and master:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches:
https://github.com/gitster/git
The preformatted documentation in HTML and man format are found in:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[Graduated to "master"]
* ab/pull-rebase-config (2011-11-07) 1 commit
(merged to 'next' on 2011-12-05 at 6d235a4)
+ pull: introduce a pull.rebase option to enable --rebase
* jc/pull-signed-tag (2011-11-12) 15 commits
(merged to 'next' on 2011-12-05 at c949bd1)
+ commit-tree: teach -m/-F options to read logs from elsewhere
+ commit-tree: update the command line parsing
+ commit: teach --amend to carry forward extra headers
+ merge: force edit and no-ff mode when merging a tag object
+ commit: copy merged signed tags to headers of merge commit
+ merge: record tag objects without peeling in MERGE_HEAD
+ merge: make usage of commit->util more extensible
+ fmt-merge-msg: Add contents of merged tag in the merge message
+ fmt-merge-msg: package options into a structure
+ fmt-merge-msg: avoid early returns
+ refs DWIMmery: use the same rule for both "git fetch" and others
+ fetch: allow "git fetch $there v1.0" to fetch a tag
+ merge: notice local merging of tags and keep it unwrapped
+ fetch: do not store peeled tag object names in FETCH_HEAD
+ Split GPG interface into its own helper library
(this branch is used by jc/signed-commit.)
Allow pulling/merging a signed tag instead of a branch tip, and record
the GPG signature in the merge commit for later audit.
* jc/request-pull-show-head-4 (2011-11-09) 12 commits
(merged to 'next' on 2011-12-05 at 8f05b45)
+ request-pull: use the annotated tag contents
+ fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error
+ environment.c: Fix an sparse "symbol not declared" warning
+ builtin/log.c: Fix an "Using plain integer as NULL pointer" warning
+ fmt-merge-msg: use branch.$name.description
+ request-pull: use the branch description
+ request-pull: state what commit to expect
+ request-pull: modernize style
+ branch: teach --edit-description option
+ format-patch: use branch description in cover letter
+ branch: add read_branch_desc() helper function
+ Merge branch 'bk/ancestry-path' into jc/branch-desc
Allow setting "description" for branches and use it to help communications
between humans in various workflow elements. It also allows requesting for
a signed tag to be pulled and shows the tag message in the generated message.
* nd/resolve-ref (2011-12-05) 2 commits
(merged to 'next' on 2011-12-05 at d55637f)
+ Copy resolve_ref() return value for longer use
+ Convert many resolve_ref() calls to read_ref*() and ref_exists()
* rs/allocate-cache-entry-individually (2011-10-26) 2 commits
(merged to 'next' on 2011-12-05 at 241e711)
+ cache.h: put single NUL at end of struct cache_entry
+ read-cache.c: allocate index entries individually
* sg/complete-refs (2011-10-21) 9 commits
(merged to 'next' on 2011-12-05 at 03e5527)
+ completion: remove broken dead code from __git_heads() and __git_tags()
+ completion: fast initial completion for config 'remote.*.fetch' value
+ completion: improve ls-remote output filtering in __git_refs_remotes()
+ completion: query only refs/heads/ in __git_refs_remotes()
+ completion: support full refs from remote repositories
+ completion: improve ls-remote output filtering in __git_refs()
+ completion: make refs completion consistent for local and remote repos
+ completion: optimize refs completion
+ completion: document __gitcomp()
--------------------------------------------------
[New Topics]
* rr/revert-cherry-pick (2011-12-09) 9 commits
- revert: simplify communicating command-line arguments
- revert: report fine-grained error messages from insn parser
- revert: allow mixed pick and revert instructions
- t3510 (cherry-pick-sequencer): remove malformed sheet 2
- t3510 (cherry-pick-sequencer): use exit status
- revert: simplify getting commit subject in format_todo()
- revert: tolerate extra spaces, tabs in insn sheet
- revert: make commit subjects in insn sheet optional
- revert: free msg in format_todo()
This is not the latest one but the last one posted to the list.
* ew/keepalive (2011-12-05) 1 commit
- enable SO_KEEPALIVE for connected TCP sockets
Comments?
* jc/checkout-m-twoway (2011-12-06) 1 commit
(merged to 'next' on 2011-12-09 at c946009)
+ checkout -m: no need to insist on having all 3 stages
* tr/cache-tree (2011-12-06) 5 commits
- reset: update cache-tree data when appropriate
- commit: write cache-tree data when writing index anyway
- Refactor cache_tree_update idiom from commit
- Test the current state of the cache-tree optimization
- Add test-scrap-cache-tree
Will merge to 'next' after taking another look.
* tr/userdiff-c-returns-pointer (2011-12-06) 1 commit
(merged to 'next' on 2011-12-09 at 0b6a092)
+ userdiff: allow * between cpp funcname words
* jc/commit-amend-no-edit (2011-12-08) 5 commits
(merged to 'next' on 2011-12-09 at b9cfa4e)
+ test: commit --amend should honor --no-edit
+ commit: honour --no-edit
+ t7501 (commit): modernize style
+ test: remove a porcelain test that hard-codes commit names
+ test: add missing "&&" after echo command
* jl/submodule-status-failure-report (2011-12-08) 1 commit
(merged to 'next' on 2011-12-09 at 53eb3b3)
+ diff/status: print submodule path when looking for changes fails
* ks/tag-cleanup (2011-12-09) 1 commit
(merged to 'next' on 2011-12-09 at cbea045)
+ git-tag: introduce --cleanup option
* rr/test-chaining (2011-12-09) 5 commits
- t3040 (subprojects-basic): fix '&&' chaining, modernize style
- t1510 (worktree): fix '&&' chaining
- t3030 (merge-recursive): use test_expect_code
- test: fix '&&' chaining
- t3200 (branch): fix '&&' chaining
I think Martin's patches to t3401 should also be queued here.
--------------------------------------------------
[Cooking]
* bc/maint-apply-check-no-patch (2011-12-05) 2 commits
(merged to 'next' on 2011-12-09 at fc780cd)
+ builtin/apply.c: report error on failure to recognize input
+ t/t4131-apply-fake-ancestor.sh: fix broken test
* aw/rebase-i-stop-on-failure-to-amend (2011-11-30) 1 commit
(merged to 'next' on 2011-12-09 at a117e83)
+ rebase -i: interrupt rebase when "commit --amend" failed during "reword"
* jc/split-blob (2011-12-01) 6 commits
. WIP (streaming chunked)
- chunked-object: fallback checkout codepaths
- bulk-checkin: support chunked-object encoding
- bulk-checkin: allow the same data to be multiply hashed
- new representation types in the packstream
- varint-in-pack: refactor varint encoding/decoding
(this branch uses jc/stream-to-pack.)
Not ready. At least pack-objects and fsck need to learn the new encoding
for the series to be usable locally, and then index-pack/unpack-objects
needs to learn it to be used remotely.
* jh/fast-import-notes (2011-11-28) 3 commits
(merged to 'next' on 2011-12-09 at 2b01132)
+ fast-import: Fix incorrect fanout level when modifying existing notes refs
+ t9301: Add 2nd testcase exposing bugs in fast-import's notes fanout handling
+ t9301: Fix testcase covering up a bug in fast-import's notes fanout handling
Comments?
* tj/maint-imap-send-remove-unused (2011-11-23) 2 commits
(merged to 'next' on 2011-12-09 at 877cc11)
+ Merge branch 'maint' into tj/imap-send-remove-unused
+ imap-send: Remove unused 'use_namespace' variable
* cn/maint-lf-to-crlf-filter (2011-11-28) 1 commit
(merged to 'next' on 2011-12-09 at c374d14)
+ convert: track state in LF-to-CRLF filter
* jn/branch-move-to-self (2011-11-28) 2 commits
(merged to 'next' on 2011-12-09 at 7d27260)
+ Allow checkout -B <current-branch> to update the current branch
+ branch: allow a no-op "branch -M <current-branch> HEAD"
* jk/credentials (2011-12-09) 20 commits
- credential: use git_prompt instead of git_getpass
- prompt: use git_terminal_prompt
- add generic terminal prompt function
- refactor git_getpass into generic prompt function
- move git_getpass to its own source file
- imap-send: don't check return value of git_getpass
- imap-send: avoid buffer overflow
- t: add test harness for external credential helpers
- credentials: add "store" helper
- strbuf: add strbuf_add*_urlencode
- credentials: add "cache" helper
- docs: end-user documentation for the credential subsystem
- credential: make relevance of http path configurable
- credential: add credential.*.username
- credential: apply helper config
- http: use credential API to get passwords
- credential: add function for parsing url components
- introduce credentials API
- t5550: fix typo
- test-lib: add test_config_global variant
Looking good.
* nd/ignore-might-be-precious (2011-11-28) 2 commits
(merged to 'next' on 2011-12-09 at 1a94553)
+ checkout,merge: disallow overwriting ignored files with --no-overwrite-ignore
+ Merge branch 'nd/maint-ignore-exclude' into nd/ignore-might-be-precious
* jk/upload-archive-use-start-command (2011-11-21) 1 commit
(merged to 'next' on 2011-12-09 at 88cb83a)
+ upload-archive: use start_command instead of fork
* jk/maint-1.6.2-upload-archive (2011-11-21) 1 commit
+ archive: don't let remote clients get unreachable commits
(this branch is used by jk/maint-upload-archive.)
* jk/maint-upload-archive (2011-11-21) 1 commit
(merged to 'next' on 2011-12-09 at 03deb16)
+ Merge branch 'jk/maint-1.6.2-upload-archive' into jk/maint-upload-archive
(this branch uses jk/maint-1.6.2-upload-archive.)
* ab/enable-i18n (2011-12-05) 1 commit
- i18n: add infrastructure for translating Git with gettext
Will merge to 'next'.
* jc/signed-commit (2011-11-29) 5 commits
- gpg-interface: allow use of a custom GPG binary
- pretty: %G[?GS] placeholders
- test "commit -S" and "log --show-signature"
- log: --show-signature
- commit: teach --gpg-sign option
Not exactly urgent.
* jc/stream-to-pack (2011-12-01) 5 commits
(merged to 'next' on 2011-12-09 at d0fd605)
+ bulk-checkin: replace fast-import based implementation
+ csum-file: introduce sha1file_checkpoint
+ finish_tmp_packfile(): a helper function
+ create_tmp_packfile(): a helper function
+ write_pack_header(): a helper function
(this branch is used by jc/split-blob.)
Teaches "git add" to send large-ish blob data straight to a packfile.
This is a continuation to the "large file support" topic. The codepath to
move data from worktree to repository is made aware of streaming, just
like the checkout codepath that goes the other way, which was done in the
previous "large file support" topic in the 1.7.7 cycle.
* jn/gitweb-side-by-side-diff (2011-10-31) 8 commits
- gitweb: Add navigation to select side-by-side diff
- gitweb: Use href(-replay=>1,...) for formats links in "commitdiff"
- t9500: Add basic sanity tests for side-by-side diff in gitweb
- t9500: Add test for handling incomplete lines in diff by gitweb
- gitweb: Give side-by-side diff extra CSS styling
- gitweb: Add a feature to show side-by-side diff
- gitweb: Extract formatting of diff chunk header
- gitweb: Refactor diff body line classification
Replaces a series from Kato Kazuyoshi on the same topic.
Is this ready for 'next'?
--------------------------------------------------
[Discarded]
* hv/submodule-merge-search (2011-10-13) 4 commits
. submodule.c: make two functions static
. allow multiple calls to submodule merge search for the same path
. push: Don't push a repository with unpushed submodules
. push: teach --recurse-submodules the on-demand option
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
. t5800: point out that deleting branches does not work
. t5800: document inability to push new branch with old content
* sr/fix-fast-export-tips (2011-11-05) 3 commits
. fast-export: output reset command for commandline revs
. fast-export: do not refer to non-existing marks
. t9350: point out that refs are not updated correctly
* jc/lookup-object-hash (2011-08-11) 6 commits
. object hash: replace linear probing with 4-way cuckoo hashing
. object hash: we know the table size is a power of two
. object hash: next_size() helper for readability
. pack-objects --count-only
. object.c: remove duplicated code for object hashing
. object.c: code movement for readability
* jc/verbose-checkout (2011-10-16) 2 commits
. checkout -v: give full status output after switching branches
. checkout: move the local changes report to the end
* eh/grep-scale-to-cpunum (2011-11-05) 1 commit
. grep: detect number of CPUs for thread spawning
* jc/commit-tree-extra (2011-11-12) 2 commits
. commit-tree: teach -C <extra-commit>
. commit-tree: teach -x <extra>
(this branch uses jc/pull-signed-tag; is tangled with jc/signed-commit.)
* cb/daemon-permission-errors (2011-10-17) 2 commits
. daemon: report permission denied error to clients
. daemon: add tests
* ld/p4-labels-branches (2011-11-30) 4 commits
. git-p4: importing labels should cope with missing owner
. git-p4: add test for p4 labels
. git-p4: cope with labels with empty descriptions
. git-p4: handle p4 branches and labels containing shell chars
* mh/ref-api-2 (2011-11-16) 15 commits
. refs: loosen over-strict "format" check
. resolve_gitlink_ref_recursive(): change to work with struct ref_cache
. Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
. resolve_gitlink_ref(): improve docstring
. get_ref_dir(): change signature
. refs: change signatures of get_packed_refs() and get_loose_refs()
. is_dup_ref(): extract function from sort_ref_array()
. add_ref(): add docstring
. parse_ref_line(): add docstring
. is_refname_available(): remove the "quiet" argument
. clear_ref_array(): rename from free_ref_array()
. refs: rename parameters result -> sha1
. refs: rename "refname" variables
. struct ref_entry: document name member
. cache.h: add comments for git_path() and git_path_submodule()
(this branch is tangled with mh/ref-api-3.)
* mh/ref-api-3 (2011-11-16) 26 commits
. refs: loosen over-strict "format" check
. is_refname_available(): reimplement using do_for_each_ref_in_array()
. names_conflict(): simplify implementation
. names_conflict(): new function, extracted from is_refname_available()
. repack_without_ref(): reimplement using do_for_each_ref_in_array()
. do_for_each_ref_in_array(): new function
. do_for_each_ref(): correctly terminate while processesing extra_refs
. add_ref(): take a (struct ref_entry *) parameter
. create_ref_entry(): extract function from add_ref()
. parse_ref_line(): add a check that the refname is properly formatted
. repack_without_ref(): remove temporary
. Rename another local variable name -> refname
. resolve_gitlink_ref_recursive(): change to work with struct ref_cache
. Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
. resolve_gitlink_ref(): improve docstring
. get_ref_dir(): change signature
. refs: change signatures of get_packed_refs() and get_loose_refs()
. is_dup_ref(): extract function from sort_ref_array()
. add_ref(): add docstring
. parse_ref_line(): add docstring
. is_refname_available(): remove the "quiet" argument
. clear_ref_array(): rename from free_ref_array()
. refs: rename parameters result -> sha1
. refs: rename "refname" variables
. struct ref_entry: document name member
. cache.h: add comments for git_path() and git_path_submodule()
(this branch is tangled with mh/ref-api-2.)
^ permalink raw reply
* Re: Question about commit message wrapping
From: Sidney San Martín @ 2011-12-09 14:10 UTC (permalink / raw)
To: Frans Klaver, git
In-Reply-To: <op.v57na7120aolir@keputer>
On Dec 9, 2011, at 2:05 AM, Frans Klaver wrote:
> On Fri, 09 Dec 2011 02:59:06 +0100, Sidney San Martín <s@sidneysm.com> wrote:
>
>> Hey, I want to ask about the practice of wrapping commit messages to 70-something charaters.
>>
>> The webpage most cited about it, which I otherwise really like, is
>>
>> http://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html
>>
>> *Nothing else* in my everyday life works this way anymore. Line wrapping gets done on the display end in my email client, my web browser, my ebook reader entirely automatically, and it adapts to the size of the window.
>
> Actually, opera-mail autowraps at 72 characters but sets the text format to flowed. It also wraps the quoted text when you reply. But there's a reasonable chance that you don't use opera in your daily life. On the other hand I would not be surprised if most decent e-mail clients worked that way.
>
Interesting… either way, the end result is that the receiving mail client can wrap the lines to whatever length it (or you, as its operator) desires, which I think we can agree is a good thing, right?
> Nobody's forcing you to use the same practice in your own projects anyway.
>
>
>>
>> That article gives two reasons why commits should be wrapped to 72 columns. First:
>>
>>> git log doesn’t do any special special wrapping of the commit messages. With the default pager of less -S, this means your paragraphs flow far off the edge of the screen, making them difficult to read. On an 80 column terminal, if we subtract 4 columns for the indent on the left and 4 more for symmetry on the right, we’re left with 72 columns.
>>
>> Here, I put a patch at the bottom of this email that wraps commit messages to, right now, 80 columns when they're displayed. (It’s a quick one, probably needs configurability. Also, beware, I don’t program in C too much.)
>
> Hm. Saying "that's how the tool works" is not a good reason in my opinion. There might be tons of other reasons for wrapping at 80 characters. Readability is one that comes to mind for me.
>
That's my basic point. I hope it didn't seem like I was arguing against reading commit messages wrapped to 80 columns, by default. I only wanted to discuss whether it makes more sense to handle it on the display end instead of asking committers to do it in advance.
- My phone shows text most comfortably at about 40 characters per line. I do look at terminals at 80 columns most of the time, but not always, and I sometimes browse projects in GUI tools that use a proportional font in a window may be narrower or wider than that.
- Right now, when I *am* in an 80-col terminal I have to trust everyone else to wrap their commit messages. Not everyone does. I feel like it would be more effective to give git the ability to wrap them automatically when I read them.
>>
>> Second:
>>
>>> git format-patch --stdout converts a series of commits to a series of emails, using the messages for the message body. Good email netiquette dictates we wrap our plain text emails such that there’s room for a few levels of nested reply indicators without overflow in an 80 column terminal. (The current rails.git workflow doesn’t include email, but who knows what the future will bring.)
>>
>> There's been a standard for flowed plain text emails (which don't have to wrap at 80 columns) for well over ten years, RFC-2646 and is widely supported. Besides, code in diffs is often longer than 7x characters, and wrapping, like `git log`, could be done inside git. FWIW, there are a bunch of merge commits with lines longer than 80 characters in the git repo itself.
>
> Yes, that standard allows e-mail clients to display the text more fluidly, even if the source text is word-wrapped. While git uses e-mail format, it isn't an e-mail client. I always interpreted this whole thing as git basically creating plain-text e-mails. You're actually writing the source of the e-mail in your commit message. If you care about actual use in e-mail (like we do here on the list) you might want to add the relevant header to the mails. That said, Apple Mail (the client you used to send your mail) doesn't even use the RFC you quote in the sent message. That mail is going to be a pain in the butt to read in mutt from work ;).
>
Sorry, I'm not sure what you mean by, “If you care about actual use in e-mail (like we do here on the list) you might want to add the relevant header to the mails”.
Interesting, I didn't realize that Mail didn't use it. It does, however, use quoted-printable which, as far as I can tell, has a similar effect on line wrapping. What happens when you view this email in mutt?
>
>>
>> Finally, people read commits these days in many other places than `git log` (and make commits in many other places than a text editor configured to wrap). Most every GUI and already word wraps commit messages just fine. As a result, there are commits in popular repos much longer than the 72-column standard and no one notices. Instead, properly-formatted commit messages end up looking cramped when you see them in anywhere wider than 80 columns.
>
> Cramped? I think it's compact and actually I prefer it over long lines.
>
>> Am I crazy?
>
> Probably not. Don't take my word for it. I'm not a psychiatrist.
>
>
>> If this makes sense to anyone else, I'd be happy to help massage this into something git-worthy, with some help (never worked on Git before).
>>
>> - - -
>>
>> From a93b390d1506652d4ad41d1cbd987ba98a8deca0 Mon Sep 17 00:00:00 2001
>> From: =?UTF-8?q?Sidney=20San=20Marti=CC=81n?= <s@sidneysm.com>
>> Date: Thu, 8 Dec 2011 20:26:23 -0500
>> Subject: [PATCH] Wrap commit messages on display
>>
>> - Wrap to 80 characters minus the indent
>> - Use a hanging indent for lines which begin with "- "
>> - Do not wrap lines which begin with whitespace
>> ---
>> pretty.c | 10 ++++++++--
>> 1 files changed, 8 insertions(+), 2 deletions(-)
>>
>> diff --git a/pretty.c b/pretty.c
>> index 230fe1c..15804ce 100644
>> --- a/pretty.c
>> +++ b/pretty.c
>> @@ -1243,8 +1243,14 @@ void pp_remainder(const struct pretty_print_context *pp,
>> memset(sb->buf + sb->len, ' ', indent);
>> strbuf_setlen(sb, sb->len + indent);
>> }
>> - strbuf_add(sb, line, linelen);
>> - strbuf_addch(sb, '\n');
>> + if (line[0] == ' ' || line[0] == '\t') {
>> + strbuf_add(sb, line, linelen);
>> + } else {
>> + struct strbuf wrapped = STRBUF_INIT;
>> + strbuf_add(&wrapped, line, linelen);
>> + strbuf_add_wrapped_text(sb, wrapped.buf, 0, indent + (line[0] == '-' && line[1] == ' ' ? 2 : 0), 80 - indent);
>
> While on the subject, In my mail view, the new line started with the [1] from line[1], in the quote the line looks entirely different. Now this is code we're talking about, so it makes slightly more sense to have a proper wrapping hard-coded. Compare the above with the following:
>
> + int hanging_indent = ((line[0] == '-' && line[1] == ' ') ? 2 : 0);
> [...]
> + strbuf_add_wrapped_text(sb, wrapped.buf, 0,
> + indent + hanging_indent,
> + 80 - indent);
>
> Much clearer, no? I personally usually have two or three terminals tucked next to each other, so I can look at two or three things at the same time. 80 characters limit is a nice feature then.
Good point, that makes it clearer either way. I put an updated patch at the bottom of this email (also fixed forgetting the newline after lines with leading whitespace). I hope it's OK to include patches this way, I understand that they're supposed to represent whole emails but want to include them with this discussion.
>
>
>> + strbuf_addch(sb, '\n');
>> + }
>> }
>> }
>>
>
> Cheers,
> Frans
From 53fd7deedaf5ac522c9d752e79cf71561cc57f07 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Sidney=20San=20Marti=CC=81n?= <s@sidneysm.com>
Date: Thu, 8 Dec 2011 20:26:23 -0500
Subject: [PATCH] Wrap commit messages on display
- Wrap to 80 characters, minus the indent
- Use a hanging indent for lines which begin with "- "
- Do not wrap lines which begin with whitespace
---
pretty.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/pretty.c b/pretty.c
index 230fe1c..841ccd1 100644
--- a/pretty.c
+++ b/pretty.c
@@ -1243,7 +1243,14 @@ void pp_remainder(const struct pretty_print_context *pp,
memset(sb->buf + sb->len, ' ', indent);
strbuf_setlen(sb, sb->len + indent);
}
- strbuf_add(sb, line, linelen);
+ if (line[0] == ' ' || line[0] == '\t') {
+ strbuf_add(sb, line, linelen);
+ } else {
+ struct strbuf wrapped = STRBUF_INIT;
+ strbuf_add(&wrapped, line, linelen);
+ int hanging_indent = ((line[0] == '-' && line[1] == ' ') ? 2 : 0);
+ strbuf_add_wrapped_text(sb, wrapped.buf, 0, indent + hanging_indent, 80 - indent);
+ }
strbuf_addch(sb, '\n');
}
}
--
1.7.8
^ permalink raw reply related
* Re: Auto update submodules after merge and reset
From: Andreas T.Auer @ 2011-12-10 1:41 UTC (permalink / raw)
To: Phil Hord; +Cc: Jens Lehmann, git
In-Reply-To: <CABURp0rcT2FR3uOmhyPUV5W3pu7WuJzjXktmUq0eb4nOiUwDKA@mail.gmail.com>
On 10.12.2011 00:57 Phil Hord wrote:
> On Thu, Dec 8, 2011 at 4:13 AM,<andreas.t.auer_gtml_37453@ursus.ath.cx> wrote:
>
>> On 07.12.2011 23:23 Jens Lehmann wrote:
>>
>>>> If you have tracking branches, the supermodule can just update the
>>>> corresponding branch. If this branch is currently checkedout and
>>>> the work area is clean, then the work area is updated, too. If
>>>> there is currently a local branch or a diffent super-branch
>>>> checked out then the working area should be considered "detached"
>>>> from the superproject and not updated.
>>>>
>>> This sounds a lot like the "follow branch tip" model we discussed
>>> recently (which could be configured via .gitmodules), but I'm not
>>> sure you really are in the same boat here.
>>>
>> When I understood that correctly it was just a configuration to what branch
>> should be automatically checked out in the submodule. This seems to be too
>> complicated IMO, because when you have different branches in the
>> superproject then you may want to have different branches in the submodules,
>> too, but you would need to configure that submodule branch in .gitmodules
>> for each branch separately. I.e. in the master branch the .gitmodule may
>> contain "master", in the maint branch the .gitmodules may have "maint" as
>> the branch to follow.
>>
> Yes, but maybe you can update this information in the .gitmodules file
> easily with a command. Maybe it could be something simpler than "git
> sync-gitmodules-branches", but that is essentially what it would do:
> it would save the current branch in each submodule as the "tracked"
> branch in the .gitmodules file.
>
> The advantages to this, I think, are that
>
> 1. Your "submodule A follows branch X" information is explicit in the
> .gitmodules file and so it is not hidden when I examine your patch.
> (It sounds to me like the refs/super/* branches would necessarily be
> hard to find since the refs/ hierarchy is usually meta data about
> local and remote branches. Maybe I should think about tags and notes
> more, though.)
>
Branches can be seen as "dynamic data" that can easily be updated,
renamed or even deleted, if a branch is merged into another.
On the other hand .gitmodules can be seen as "static data" because it is
committed to the object database, so if you checkout an old revision,
you could get a version of the .gitmodules that refers to a branch,
which existed at that time, but was deleted meanwhile.
> 2. When you change to "submodule A now follows branch Y", this
> information can be unambiguously saved in the commit where it occurred
> rather than tucked away, again, in refs/super/*.
>
If you place a reference in refs/super/ it will be displayed by gitk
currently, so it is not really hidden.
> The disadvantage, maybe, are that you must now use 'git submodule
> sync' or something like that to put any .gitmodules changes into
> effect.
> Or maybe that is an advantage. How often will this branch tracking change?
>
It depends on your use case. In mine it will change quite often.
> For example, I have some repos like this:
>
> super
> +--subA
> +--subB
>
> I wish I could do this:
> cd super&& checkout master
>
> to get this:
> super (master)
> +--subA (master)
> +--subB (master)
>
> Or, if I have SubB on super/'master' tracking 'foo', I could get this:
> super (master)
> +--subA (master)
> +--subB (foo)
>
No, the branch super/master always follows the master of the
superproject. That's why it is called super/, because it contains the
branchnames from the supermodule's namespace. The normal "local"
submodule branches are in refs/heads/*. The references in refs/super can
easily be created "on the fly" by the superproject, so they are not
really properties of the submodules. It is a little bit like a cookie
jar ;-).
>
>> I do want to follow the tip of the branch, if the superproject has that
>> currently checked out. If the superproject checks out a tagged version for a
>> rebuild, then the submodule should not follow the tip, but should get a
>> detached HEAD of the corresponding commit, just as the superproject. When
>> the superproject goes back to the branch, the submodule should go back to
>> its tracking branch.
>>
> Now this makes sense. I want the same thing. I want to preserve
> history on "old" commits, but I want to "advance to tip" on "new"
> commits.
> The trouble, I think, is in telling the difference between "old" and
> "new".
My approach says: Just like the superproject. If it checks out an old
commit, do that, if it checks out the branch, follow.
> So maybe I need a new command that does this:
> git checkout master&& git submodule foreach 'git checkout master'
>
> Maybe it's called "git checkout master --recurse-submodules". But I
> seem to recall this is already a non-starter for some reason, and
> anyway it doesn't solve the "variant branches in some submodules"
> problem.
>
I don't know that problem, but maybe it is because the master branch of
the submodule is not corresponding to the master branch of the
superproject, which is a common use case, when external modules are used
with different release cycles.
For that reason I chose to use a different namespace in
refs/super/master instead of that maybe existing refs/heads/master of
the submodule.
>
> You can commit to a detached HEAD. I do it all the time. The trick
> is in not switching away from a detached HEAD with your local commits
> still on it. :-)
>
Yes. And you can't push it, it can't be fetched, etc. So it really
shouldn't be used that way, but you can do a lot of things you shouldn't
do in git.
>> The first answer to my question was "yes, you need to transfer the refs or
>> you get unreferenced objects" and "no, you can't transfer the refs, because
>> they are owned by the superproject, not the submodule."
>> But binding a submodule to a superproject makes perfect sense if it is _one_
>> project that is split into submodules. In that case you only have one
>> superproject for a submodule and for that purpose it would be good workflow.
>>
> This is not useful to me, though. Sorry.
>
>
It is useful in huge projects.
>> It is even nice to see which commits in the submodule belong to what
>> branches in the superproject or to what release version (so tracking
>> superproject tags would make sense, too). If you have a submodule that has
>> more than one superproject but these are well-defined, it could be solved
>> using refspecs (e.g. refs/super/foo/* for one and refs/super/bar/* for the
>> other superproject), but currently I can't think of a context where this
>> makes sense.
>>
> I can, but this does put the cart before the horse. The submodule is
> subservient to the super project in all my setups. The submodule is
> not aware who owns him. He is a bit like the DAG in reverse. He
> knows one direction only (children), not the other (parents).
>
>
In the setup I have in mind, the submodules are not subservient to the
superproject, but a part of the whole project.
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2011, #03; Fri, 9)
From: Jakub Narebski @ 2011-12-10 2:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk465b834.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> --------------------------------------------------
> [Cooking]
> * jn/gitweb-side-by-side-diff (2011-10-31) 8 commits
> - gitweb: Add navigation to select side-by-side diff
> - gitweb: Use href(-replay=>1,...) for formats links in "commitdiff"
> - t9500: Add basic sanity tests for side-by-side diff in gitweb
> - t9500: Add test for handling incomplete lines in diff by gitweb
> - gitweb: Give side-by-side diff extra CSS styling
> - gitweb: Add a feature to show side-by-side diff
> - gitweb: Extract formatting of diff chunk header
> - gitweb: Refactor diff body line classification
>
> Replaces a series from Kato Kazuyoshi on the same topic.
> Is this ready for 'next'?
I think it is.
--
Jakub Narębski
^ permalink raw reply
* git for change control of software deployment updates
From: Neal Kreitzinger @ 2011-12-10 2:37 UTC (permalink / raw)
To: git
I am considering using git with submodules to deploy most of our updates to
our customer linux servers (not including third party rpm updates already
tracked by linux distro rpm repository). Has anyone else done this?
Comments? (Sanity check.) (I am new to submodules.)
Here are some rationale and concerns I submit for review:
Reasons:
- (Main Premise) I maintain dozens of divergent custom versions
concurrently with each running on its own server (we do merge these versions
eventually and then immediately start diverging again). (This is the main
reason we chose git for scm.) Hundreds of servers run the 'main generic'
version. Git will allow these branches to deploy to their respective
customers.
- (Main Supporting Premise) others on the git-newsgroup talk about using
git submodules to maintain web sites. Not sure how robust they are. In
theory, a website seems no different than any other application server.
- git on the customer server would allow better tracking of what the
customer is really running (ie, dirty tree).
- Submodules will track everything outside of linux distro rpms that we
update outside of linux rpms (third party binaries, html, etc.).
- Submodules containing source will be separate and not deployed.
- I already use git to deploy test versions of the core software from
dev-server to qa-servers (using git-pull --ff-only, git-clone, etc. on the
qa-server end).
- I can do most of the work using git features/git-scripts with a minimum of
homegrown bash scripts/tars.
- git with ssh will make it secure (most customer servers are in vpn
anyway).
- using separate worktree will separate git repos from deployed binaries.
- git will figure out the 'patches' to transfer in order to effect a version
change.
- versioning of config files (apache, etc.) to aid in troubleshooting.
- trying to do this with rpm's makes no sense when I can do it with git.
- trying to do this with homemade scripts/tars makes no sense when I can do
this with git.
- gitweb will make semi-technical support personnel use possible on the
customer server in the absence of gitk (gui portion of linux).
- I can have a development superproject pointing to all submodules, and a
deployment superproject pointing to same submodules but not including source
code submodules.
- if fetch/pull are better for this than push I can setup a deployment
server that customers have access to. It seems fetch/pull are more
conducive to monitoring success/failure, but push is more conducive to
central control.
- having some history of previous versions seems valuable for rapid
remediation of regressions (git checkout <prev-version> -- mybinary).
- remote tracking of customer server configurations.
- git could track pre/post-conversion/initialization data file states.
- track customer server configuration file customizations and merge them
with subsequent changes to base version.
- such a git deployment setup would make emulating a prod server on a test
server a matter of course.
Concerns:
- is there something about git that would make this unsecure during the
"patch" transfer (push, fetch, etc)?
- can I limit disk use (repo history) using shallow-clone or some disk
saving tricks? IOW, repo on customer server only needs sufficient common
ancestor to accept updates and not the whole history before the common
ancestor. (The majority of deployed content will be binaries.)
- customer servers will not have gui portion of linux loaded (minimal VM
images on an array in most cases).
- automation of the execution of data format conversion/initialization
programs (receive hook that checks for and executes and waits for completion
of such programs) as such commits apply on the repo on the customer server
or as an aggregate after all commits apply. (I think of the new execute
option in rebase, but that is different from receiving during a push.)
- upgrading git versions (breaking deployment system).
- size limits in git to versioning large data files (works for most
customers, but not the huge ones).
- gitweb is getting smarter and is no longer 'view only' like the old days.
Can it be made 'view only'?
- github (paid version) is too dumbed down to play well with this usage.
(I've only read about github but may be asked to use it to some extent.)
- one little git command could wreak havoc on a live customer server. Then
again, so can one little linux command. Is there a way to 'sudo' the git
commands?
- I rely on porcelain and do not recreate my own porcelain from plumbing.
(I am a porcelain level user.)
- detection of failures allowing for reset to previous version of software
and data.
- limits to mass deployment (max approx 500 servers in one night).
Concurrent pushes? Concurrent fetches from same remote?
- is there something else about git that might make this untenable over
time?
Thanks in advance.
v/r,
neal
^ permalink raw reply
* Re: [PATCH] Copy resolve_ref() return value for longer use
From: Tony Wang @ 2011-12-10 3:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vobwgo3l5.fsf@alter.siamese.dyndns.org>
Hi,
I don't know about the procedure, but wonder is any one following this?
--
BR,
Tony Wang
On Sunday, November 13, 2011 at 15:59, Junio C Hamano wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com (mailto:pclouds@gmail.com)> writes:
>
> > I went through all of them. Most of them only checks if return value
> > is NULL, or does one-time string comparison. Others do xstrdup() to
> > save the return value. Will update the patch message to reflect this.
>
>
>
> Thanks. Given your analysis, I think the potential change I alluded to to
> return allocated memory from the function is probably overkill in the
> current state of the code.
>
> But as the codepaths around the existing callsites evolve, some of these
> call sites that are not problematic in today's code can become problematic
> if we are not careful. I was primarily wondering if an updated API could
> force us to be careful when making future changes.
>
> And a change along the lines of your suggestion
>
> > ... Though if you don't mind a bigger patch, we could turn
> >
> > const char *resolve_ref(const char *path, const char *sha1, int
> > reading, int *flag);
> >
> > to
> >
> > int resolve_ref(const char *path, const char *sha1, int reading, int
> > *flag, char **ref);
> >
> > where *ref is the current return value and is only allocated by
> > resolve_ref() if ref != NULL.
>
>
>
> might be one such updated API that makes mistakes harder to make. I dunno.
>
> But if we were to go that route, as the first step, it might make sense to
> rewrite "only checks if it returns NULL and uses sha1" callers to call
> either read_ref() or ref_exists(), so that we do not have to worry about
> leaking at such callers when we later decide to return allocated memory
> from resolve_ref().
>
>
> builtin/branch.c | 3 +--
> builtin/merge.c | 4 ++--
> 2 files changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/builtin/branch.c b/builtin/branch.c
> index 51ca6a0..94948a4 100644
> --- a/builtin/branch.c
> +++ b/builtin/branch.c
> @@ -565,7 +565,6 @@ static int print_ref_list(int kinds, int detached, int verbose, int abbrev, stru
> static void rename_branch(const char *oldname, const char *newname, int force)
> {
> struct strbuf oldref = STRBUF_INIT, newref = STRBUF_INIT, logmsg = STRBUF_INIT;
> - unsigned char sha1[20];
> struct strbuf oldsection = STRBUF_INIT, newsection = STRBUF_INIT;
> int recovery = 0;
>
> @@ -577,7 +576,7 @@ static void rename_branch(const char *oldname, const char *newname, int force)
> * Bad name --- this could be an attempt to rename a
> * ref that we used to allow to be created by accident.
> */
> - if (resolve_ref(oldref.buf, sha1, 1, NULL))
> + if (ref_exists(oldref.buf))
> recovery = 1;
> else
> die(_("Invalid branch name: '%s'"), oldname);
> diff --git a/builtin/merge.c b/builtin/merge.c
> index dffd5ec..42b4f9e 100644
> --- a/builtin/merge.c
> +++ b/builtin/merge.c
> @@ -420,7 +420,7 @@ static struct object *want_commit(const char *name)
> static void merge_name(const char *remote, struct strbuf *msg)
> {
> struct object *remote_head;
> - unsigned char branch_head[20], buf_sha[20];
> + unsigned char branch_head[20];
> struct strbuf buf = STRBUF_INIT;
> struct strbuf bname = STRBUF_INIT;
> const char *ptr;
> @@ -479,7 +479,7 @@ static void merge_name(const char *remote, struct strbuf *msg)
> strbuf_addstr(&truname, "refs/heads/");
> strbuf_addstr(&truname, remote);
> strbuf_setlen(&truname, truname.len - len);
> - if (resolve_ref(truname.buf, buf_sha, 1, NULL)) {
> + if (ref_exists(truname.buf)) {
> strbuf_addf(msg,
> "%s\t\tbranch '%s'%s of .\n",
> sha1_to_hex(remote_head->sha1),
^ permalink raw reply
* Re: [PATCH] Copy resolve_ref() return value for longer use
From: Nguyen Thai Ngoc Duy @ 2011-12-10 4:48 UTC (permalink / raw)
To: Tony Wang; +Cc: Junio C Hamano, git
In-Reply-To: <626C086D699644D181B9FA573EDFFCA6@gmail.com>
On Sat, Dec 10, 2011 at 10:43 AM, Tony Wang <wwwjfy@gmail.com> wrote:
> Hi,
>
> I don't know about the procedure, but wonder is any one following this?
This series has been merged in master. I'll resend patches to rename
resolve_ref() to resolve_ref_unsafe() soon.
--
Duy
^ permalink raw reply
* Re: [RFC/PATCH] add update to branch support for "floating submodules"
From: Leif Gruenwoldt @ 2011-12-10 5:50 UTC (permalink / raw)
To: git
In-Reply-To: <20111129220854.GB2812@sandbox-rc.fritz.box>
Heiko Voigt <hvoigt <at> hvoigt.net> writes:
>
> Hi,
>
> On Wed, Nov 09, 2011 at 10:01:33AM -0800, Junio C Hamano wrote:
> > Heiko Voigt <hvoigt <at> hvoigt.net> writes:
> >
> > > This is almost ready but I would like to know what users of the
> > > "floating submodule" think about this.
> >
> > Thanks for working on this.
> >
> > I do like to hear from potential users as well, because the general
> > impression we got was that floating submodules is not a real need of
> > anybody, but it is merely an inertia of people who (perhaps mistakenly)
> > thought svn externals that are not anchored to a particular revision is a
> > feature when it is just a limitation in reality. During the GitTogether'11
> > we learned that Android that uses floating model does not really have to.
>
> Since we did not get any reply from potential floating submodule users I
> do not mind to drop this patch for now. It is archived in the mailing list
> and it should be easy to revive once there is real world need for it.
>
> Once we have the "exact" model support for checkout and friends this
> might be a handy tool to update submodules before releases and such. But
> currently I would like to focus on the "exact" front first.
>
> Cheers Heiko
>
If I understand the description of "floating submodules", it's something I have
been wanting for a while now! The lack of it is currently a deal breaker for
using submodules within my organisation.
Our use case is as follows. We have several repositories for our common code
(commonA.git, commonB.git, etc) and a few different products that leverage these
common repos (productA.git, productB.git, etc). When one of the products is in
heavy development we often need to do a lot of work in the common repos. Having
to increment the sha1 of the submodules to track the latest tip would be overly
arduous. (Obviously when development of the product stabilizes we would want to
change to anchoring to a specific sha1 in the common repos).
^ permalink raw reply
* Re: What's cooking in git.git (Dec 2011, #03; Fri, 9)
From: Junio C Hamano @ 2011-12-10 6:13 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3vcppgojy.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> --------------------------------------------------
>> [Cooking]
>
>> * jn/gitweb-side-by-side-diff (2011-10-31) 8 commits
>> ...
>>
>> Replaces a series from Kato Kazuyoshi on the same topic.
>> Is this ready for 'next'?
>
> I think it is.
Thanks.
^ permalink raw reply
* Re: [RFC/PATCH] add update to branch support for "floating submodules"
From: Jonathan Nieder @ 2011-12-10 6:19 UTC (permalink / raw)
To: Leif Gruenwoldt; +Cc: git, Heiko Voigt, Junio C Hamano
In-Reply-To: <loom.20111210T062013-538@post.gmane.org>
(restoring cc list)
Hi Leif,
Leif Gruenwoldt wrote:
> If I understand the description of "floating submodules", it's something I have
> been wanting for a while now! The lack of it is currently a deal breaker for
> using submodules within my organisation.
>
> Our use case is as follows.
[...]
> When one of the products is in
> heavy development we often need to do a lot of work in the common repos. Having
> to increment the sha1 of the submodules to track the latest tip would be overly
> arduous.
What happens when a bug was introduced in this period of heavy development
and someone wants to look back in the development history and build each
version to find which introduced the bug?
If I were part of such a project, I would be tempted to follow one of two
rules. Either
A. Each commit of productA strives to work with the latest version of
the common code possible. Which version of the common code that was
tested against gets recorded (perhaps by some record-submodule-versions-
and-commit script, or even a pre-commit hook) so others can
reproduce the results.
or
B. Occasionally (e.g., daily or weekly) the "baseline" version of the
common code that can be relied on gets bumped, and each commit of
productA should work with that version and all later versions for a
while. Everyday development might typically happen with the tip
version of the common code which may be faster, have more
bugfixes, and otherwise be more pleasant to work with, but commits
should work against the baseline version as well. When it is time
to bump the baseline, that fact gets recorded (in a separate
commit).
For this, the '[submodule "<name>"] ignore' setting described in
gitmodules(5) might be helpful.
Though of course other variations are possible.
Would you be able to try out using Heiko's patch for a while, adapt it
to your needs as necessary, and let us know how it goes?
Thanks very much, and good luck,
Jonathan
^ permalink raw reply
* Re: [RFC/PATCH] add update to branch support for "floating submodules"
From: Junio C Hamano @ 2011-12-10 6:30 UTC (permalink / raw)
To: Leif Gruenwoldt; +Cc: git
In-Reply-To: <loom.20111210T062013-538@post.gmane.org>
Leif Gruenwoldt <leifer@gmail.com> writes:
> Our use case is as follows. We have several repositories for our common code
> (commonA.git, commonB.git, etc) and a few different products that leverage these
> common repos (productA.git, productB.git, etc). When one of the products is in
> heavy development we often need to do a lot of work in the common repos. Having
> to increment the sha1 of the submodules to track the latest tip would be overly
> arduous. (Obviously when development of the product stabilizes we would want to
> change to anchoring to a specific sha1 in the common repos).
Nobody forces you to update the commit in the submodule bound to the
superproject tree every time you update areas that are unrelated to or
independent from that frequently updated submodule.
During the period the submodule is so often updated that you feel "having
to increment ... would be overly arduous", it does not matter which exact
commit in that submodule is used in the tree for your other modules and
the superproject. Otherwise you _would_ want to say something like "for
this entire tree state from the top-level superproject to correctly work,
we absolutely need to have this commit, not any commit that is older and
is known to be broken, from this submodule", and cannot afford to use
floating.
Which means by definition anybody who wants floating can instead let such
an often updated submodule stay somewhat stale by not running "submodule
update" for it unnecessarily. In a well-modularized set of projects, the
interface to the busy submodule may be stable and I can imagine that kind
of arrangement would well be not just possible but practical, and probably
yours may be such a project.
So that use case does not sound like a good rationale to require addition
of floating submodules.
^ permalink raw reply
* [RFC/PATCH] show tracking branches with their associated branch names
From: Santhosh Kumar Mani @ 2011-12-10 7:40 UTC (permalink / raw)
To: git
The "git branch" command, by default, displays the local branches. There
is no visual distinction made between the tracking branches and normal
local branches. This patch enables the "git branch" to display
tracking info for tracking branches:
Before this patch:
$ git branch
* master
local
After this patch:
$ git branch
* master [origin/master]
local
Signed-off-by: Santhosh Kumar Mani <santhoshmani@gmail.com>
---
builtin/branch.c | 16 ++++++++++++++++
1 files changed, 16 insertions(+), 0 deletions(-)
diff --git a/builtin/branch.c b/builtin/branch.c
index e1e486e..4841416 100644
--- a/builtin/branch.c
+++ b/builtin/branch.c
@@ -373,6 +373,19 @@ static int ref_cmp(const void *r1, const void *r2)
return strcmp(c1->name, c2->name);
}
+static int get_tracking_branch_name(struct strbuf *name, const char
*branch_name)
+{
+ struct branch *branch = branch_get(branch_name);
+
+ if (branch && branch->merge && branch->merge[0]->dst) {
+ strbuf_addf(name, " [%s]",
+ shorten_unambiguous_ref(branch->merge[0]->dst, 0));
+ return 1;
+ }
+
+ return 0;
+}
+
static void fill_tracking_info(struct strbuf *stat, const char
*branch_name,
int show_upstream_ref)
{
@@ -475,6 +488,9 @@ static void print_ref_item(struct ref_item *item,
int maxwidth, int verbose,
else if (verbose)
/* " f7c0c00 [ahead 58, behind 197] vcs-svn: drop obj_pool.h" */
add_verbose_info(&out, item, verbose, abbrev);
+ else if (get_tracking_branch_name(&out, item->name))
+ ;
+
printf("%s\n", out.buf);
strbuf_release(&name);
strbuf_release(&out);
--
1.7.0.4
^ permalink raw reply related
* Re: [PATCH 1/2] t3401: modernize style
From: Martin von Zweigbergk @ 2011-12-10 8:14 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ramkumar Ramachandra, git, Junio C Hamano
In-Reply-To: <20111209200703.GA21280@elie.hsd1.il.comcast.net>
On Fri, Dec 9, 2011 at 12:07 PM, Jonathan Nieder <jrnieder@gmail.com> wrote:
> Ramkumar Ramachandra wrote:
>
>> The motivation is unclear: lazy afternoon? :P
>
> Perhaps he was reading the list and after noticing a few patches in
> the same vein, realized that this test script could be made easier to
> read, too.
Sort of. These patches have been sitting in my repo since late Sept
and the patches you mention made me decide to send them out now. The
reason I did this back then was while trying to fix rebase to pick the
right patches when used with --onto. See this old discussion:
http://thread.gmane.org/gmane.comp.version-control.git/161917/focus=162041.
Also in the same series are patches teach rebase to only feed the
commit names to git-am (wrapped in a silly "From $sha1 Mon
Sep 17 00:00:00 2001" to please git-mailsplit). These patches have
been taking way too long, which is why I'm sending these little
cleanups separately.
>> Martin von Zweigbergk wrote:
>
>>> + echo First > A &&
>>> + git update-index --add A &&
>>> + git commit -m "Add A." &&
>>
>> Style nit: >[^ ] is prevalent FWIW.
>
> Finally I caught on that you mean that redirection operators tend to
> be flush against the filename they are redirecting to.
So did I. I think I'll leave the code unchanged, though, because the
end result, after patch 2/2 is unaffected anyways (it removes
redirections).
>> While at it, why not change this "test ! -d" to
>> "test_path_is_missing"?
Will bake it into patch 2/2 if you don't mind. Unless there are other
comments, that would mean this patch can be applies as is, Junio.
> The patch looks good to me, too. Thanks, both.
Thanks to you both, too.
^ permalink raw reply
* Access to git repository through squid proxy: The remote end hung up unexpectedly
From: Mathieu Peltier @ 2011-12-10 8:56 UTC (permalink / raw)
To: git
Hi,
I am trying to access a git repository (git:// URL) through a squid proxy.
squid allows CONNECT for port 9418:
$ more /etc/squid/squid.conf
...
acl password proxy_auth REQUIRED
acl git_port port 9418
...
http_access allow CONNECT git_port password
http_access deny CONNECT !SSL_ports
The proxy server can connect to git server :
$ telnet git.server.org 9418
Trying w.x.y.z...
Connected to git.server.org.
Escape character is '^]'.
Here is the error I get on the client side:
$ git config --list
core.gitproxy=gitproxy.sh
$ more ~/bin/gitproxy.sh
#!/bin/sh
PROXY=x.domain.org
PROXYPORT=8080
PROXYAUTH=user:pass
DEBUG="-d -d -d -d"
exec socat $DEBUG - PROXY:$PROXY:$1:$2,proxyport=$PROXYPORT,proxyauth=$PROXYAUTH
$ git clone git://git.server.org/gitroot/repo/repo
Initialized empty Git repository in /tmp/GIT/repo/.git/
...
2011/12/09 12:22:44 socat[21428] D socat version 1.7.1.3 on Aug 23 2010 23:26:54
2011/12/09 12:22:44 socat[21428] D setenv("SOCAT_VERSION", "1.7.1.3", 1)
...
2011/12/09 12:22:44 socat[21428] D running on Linux version #1 SMP Tue
Mar 23 09:47:08 UTC 2010, release x.y
2011/12/09 12:22:44 socat[21428] D argv[0]: "socat"
2011/12/09 12:22:44 socat[21428] D argv[1]: "-d"
2011/12/09 12:22:44 socat[21428] D argv[2]: "-d"
2011/12/09 12:22:44 socat[21428] D argv[3]: "-d"
2011/12/09 12:22:44 socat[21428] D argv[4]: "-d"
2011/12/09 12:22:44 socat[21428] D argv[5]: "-"
2011/12/09 12:22:44 socat[21428] D argv[6]:
"PROXY:x.domain.org:git.server.org:9418,proxyport=8080,proxyauth=user:pass"
...
2011/12/09 12:22:44 socat[21428] I setting option "proxyport" to "8080"
2011/12/09 12:22:44 socat[21428] I setting option
"proxy-authorization" to "user:pass"
...
2011/12/09 12:22:44 socat[21428] I sending "CONNECT
git.server.org:9418 HTTP/1.0\r\n"
...
2011/12/09 12:22:44 socat[21428] I proxy_connect: received answer
"HTTP/1.1 403 OK\r\n"
2011/12/09 12:22:44 socat[21428] E CONNECT git.server.org:9418: OK
2011/12/09 12:22:44 socat[21428] N exit(1)
2011/12/09 12:22:44 socat[21428] I shutdown(3, 2)
2011/12/09 12:22:44 socat[21428] D shutdown() -> 0
fatal: The remote end hung up unexpectedly
I tried to use also nc but I get the same error.
Any advice?
Thanks in advance,
Mathieu
^ 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