Junio C Hamano writes:
> Thomas Rast writes:
>
>> In some sense this is a really bad case of wrong UI design, because we
>> (this happens on #git a lot) have to teach users not to use the command
>> so they won't trip over this problem. It would be better to fix the
>> real issue instead. IIRC
On Mon, Aug 13, 2012 at 2:05 PM, Junio C Hamano wrote:
> Martin von Zweigbergk writes:
>
>> To connect to the other mail I sent on this thread (in parallel with
>> yours), do you think "git cherrry-pick HEAD HEAD~1" should apply the
>> commits in the same order as "git cherry-pick HEAD~2..HEAD" (
The --access-hook option to "git daemon" specifies an external
command to be run every time a client connects, with
- service name (e.g. "upload-pack", etc.),
- path to the repository,
- hostname (%H),
- canonical hostname (%CH),
- ip address (%IP),
- tcp port (%P)
as its command line argum
On Wed, Aug 15, 2012 at 5:13 AM, Florian Achleitner
wrote:
> Hi.
>
> Version 3 of this series adds the 'bidi-import' capability, as suggested
> Jonathan.
> Diff details are attached to the patches.
> 04 and 05 are completely new.
>
> [PATCH/RFC v3 01/16] Implement a remote helper for svn in C.
> [
Martin von Zweigbergk writes:
> On Tue, Aug 14, 2012 at 3:25 PM, Junio C Hamano wrote:
>> People answer 'y' to "Who should the emails appear to be from?" and
>> 'n' to "Message-ID to be used as In-Reply-To for the first email?"
>> for some unknown reason.
>
> Yeah, I know :-(. I did feel stupid
Hilco Wijbenga writes:
>> I meant something else than Junio hinted at. Saying
>>
>> git fetch origin master
>> # or by extension
>> git pull origin master
>>
>> does not update the origin/* namespace, not even origin/master. All
>> fetching happens only into FETCH_HEAD. This leads to con
On Tue, Aug 14, 2012 at 3:25 PM, Junio C Hamano wrote:
> People answer 'y' to "Who should the emails appear to be from?" and
> 'n' to "Message-ID to be used as In-Reply-To for the first email?"
> for some unknown reason.
Yeah, I know :-(. I did feel stupid already. Thanks for improving.
--
To un
People answer 'y' to "Who should the emails appear to be from?" and
'n' to "Message-ID to be used as In-Reply-To for the first email?"
for some unknown reason. While it is possible that really have "y"
as your local username and sending the mail to your local colleagues,
it is plausible that it c
On 14 August 2012 13:12, Thomas Rast wrote:
> Hilco Wijbenga writes:
>
>> On 14 August 2012 10:19, Junio C Hamano wrote:
>>> Hilco Wijbenga writes:
>>>
On 14 August 2012 01:27, Thomas Rast wrote:
> [git pull with two args] it's ok if you use it with an URL instead
> of a remote ni
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
Hopefully tomorrow's 1.7.12-rc3 will be the final rc before the real
thing.
You can find the changes described here in the integration branches
Heiko Voigt writes:
> During discussion of other patches these preferences have been revealed.
> Lets add them to the guidelines.
>
> Signed-off-by: Heiko Voigt
> ---
> Documentation/CodingGuidelines | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/Documentation/CodingGuidelines b
Heiko Voigt writes:
> Previously the exit status of git submodule was zero for various
> subcommands even though the user specified an unknown path.
As any patch that fixes behaviour deals with "Previously", I'd
prefer to omit it and describe the current problem in present tense
instead.
Will q
On Mon, Aug 13, 2012 at 4:53 PM, Junio C Hamano wrote:
> Stephen Boyd writes:
>
>> Can we throw up a big warning or just outright fail if someone types
>> 'n' or 'y' and hits enter for the in-reply-to question in
>> git-send-email? I saw a git-send-email sent patch with an In-Reply-To
>> header c
Thomas Rast writes:
> In some sense this is a really bad case of wrong UI design, because we
> (this happens on #git a lot) have to teach users not to use the command
> so they won't trip over this problem. It would be better to fix the
> real issue instead. IIRC it was even on the 1.8.0 wishli
Florian Achleitner writes:
> Allow execution of git-remote-svn even if the binary
> currently is located in contrib/svn-fe/.
>
> Signed-off-by: Florian Achleitner
> ---
> git-remote-svn |1 +
> 1 file changed, 1 insertion(+)
> create mode 12 git-remote-svn
>
> diff --git a/git-remote-s
Florian Achleitner writes:
> Allow execution of git-remote-svn even if the binary
> currently is located in contrib/svn-fe/.
>
> Signed-off-by: Florian Achleitner
> ---
> git-remote-svn |1 +
> 1 file changed, 1 insertion(+)
> create mode 12 git-remote-svn
>
> diff --git a/git-remote-s
Florian Achleitner writes:
> The fast-import commands 'cat-blob' and 'ls' can be used by remote-helpers
> to retrieve information about blobs and trees that already exist in
> fast-import's memory. This requires a channel from fast-import to the
> remote-helper.
> remote-helpers that use this fea
During discussion of other patches these preferences have been revealed.
Lets add them to the guidelines.
Signed-off-by: Heiko Voigt
---
Documentation/CodingGuidelines | 6 ++
1 file changed, 6 insertions(+)
diff --git a/Documentation/CodingGuidelines b/Documentation/CodingGuidelines
index
Previously the exit status of git submodule was zero for various
subcommands even though the user specified an unknown path.
The reason behind that was that they all pipe the output of module_list
into the while loop which then does the action on the paths specified by
the commandline. Since the e
Florian Achleitner writes:
> The existing function only allows reading from a filename or
> from stdin. Allow passing of a FD and an additional FD for
> the back report pipe. This allows us to retrieve the name of
> the pipe in the caller.
>
> Fixes the filename could be NULL bug.
What bug? Was
Florian Achleitner writes:
> Requires some sha.h to be used and the libraries
> to be linked, this is currently hardcoded.
>
> Signed-off-by: Florian Achleitner
> ---
> contrib/svn-fe/Makefile | 16 ++--
> 1 file changed, 10 insertions(+), 6 deletions(-)
>
> diff --git a/contrib/s
Hilco Wijbenga writes:
> On 14 August 2012 10:19, Junio C Hamano wrote:
>> Hilco Wijbenga writes:
>>
>>> On 14 August 2012 01:27, Thomas Rast wrote:
[git pull with two args] it's ok if you use it with an URL instead
of a remote nickname
>>>
>>> Why would that be okay? What is the dif
Florian Achleitner writes:
> Enable basic fetching from subversion repositories. When processing remote
> URLs
> starting with svn::, git invokes this remote-helper.
> It starts svnrdump to extract revisions from the subversion repository in the
> 'dump file format', and converts them to a git-f
Use svnrdump_sim.py to emulate svnrdump without an svn server.
Tests fetching, incremental fetching, fetching from file://,
and the regeneration of fast-import's marks file.
Signed-off-by: Florian Achleitner
---
t/t9020-remote-svn.sh | 69 +
tran
fast-import mark files are stored outside the object database and are therefore
not fetched and can be lost somehow else.
marks provide a svn revision --> git sha1 mapping, while the notes that are
attached
to each commit when it is imported provide a git sha1 --> svn revision.
If the marks file
To ease testing without depending on a reachable svn server, this
compact python script mimics parts of svnrdumps behaviour.
It requires the remote url to start with sim://.
Start and end revisions are evaluated.
If the requested revision doesn't exist, as it is the case with
incremental imports, i
Search for a note attached to the ref to update and read it's
'Revision-number:'-line. Start import from the next svn revision.
If there is no next revision in the svn repo, svnrdump terminates
with a message on stderr an non-zero return value. This looks a
little weird, but there is no other way
To provide metadata from svn dumps for further processing, e.g.
branch detection, attach a note to each imported commit that
stores additional information.
The notes are currently hard-coded in refs/notes/svn/revs.
Currently the following lines from the svn dump are directly
accumulated in the note
For testing as well as for importing large, already
available dumps, it's useful to bypass svnrdump and
replay the svndump from a file directly.
Add support for file:// urls in the remote url.
e.g. svn::file:///path/to/dump
When the remote helper finds an url starting with
file:// it tries to open
The reference to update by the fast-import stream is hard-coded.
When fetching from a remote the remote-helper shall update refs
in a private namespace, i.e. a private subdir of refs/.
This namespace is defined by the 'refspec' capability, that the
remote-helper advertises as a reply to the 'capabl
Signed-off-by: Florian Achleitner
---
Documentation/git-remote-helpers.txt | 21 -
1 file changed, 20 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-remote-helpers.txt
b/Documentation/git-remote-helpers.txt
index f5836e4..5faa48e 100644
--- a/Documentation/git
The existing function only allows reading from a filename or
from stdin. Allow passing of a FD and an additional FD for
the back report pipe. This allows us to retrieve the name of
the pipe in the caller.
Fixes the filename could be NULL bug.
Signed-off-by: Florian Achleitner
---
- dup input fil
Enable basic fetching from subversion repositories. When processing remote URLs
starting with svn::, git invokes this remote-helper.
It starts svnrdump to extract revisions from the subversion repository in the
'dump file format', and converts them to a git-fast-import stream using
the functions of
Hi.
Version 3 of this series adds the 'bidi-import' capability, as suggested
Jonathan.
Diff details are attached to the patches.
04 and 05 are completely new.
[PATCH/RFC v3 01/16] Implement a remote helper for svn in C.
[PATCH/RFC v3 02/16] Integrate remote-svn into svn-fe/Makefile.
[PATCH/RFC v
On Tue, Aug 14, 2012 at 10:23 AM, Junio C Hamano wrote:
> Charles Bailey writes:
>
>> On Tue, Aug 14, 2012 at 08:06:56AM -0700, Junio C Hamano wrote:
>>>
>>> Could it be that the calling user or script does not even have a
>>> terminal but still can spawn the chosen mergetool backend and
>>> inte
Hilco Wijbenga writes:
> I suppose I'm not entirely clear on how this two step process is
> "safer". Doing "git fetch" would seem to be harmless, right? So the
> problem is with "git merge" but master should always be "behind"
> origin/master so that "git merge" should just FF to origin/master
>
Shawn Pearce writes:
> But seeing this, yes, that is a bad idea. Better to treat that like a
> hook, where exit status 0 allows the connection to continue, and exit
> status non-zero causes the connection to be closed. Maybe with an
> error printed to stderr (if any) being echoed first to the cli
On 14 August 2012 10:19, Junio C Hamano wrote:
> Hilco Wijbenga writes:
>
>> On 14 August 2012 01:27, Thomas Rast wrote:
>>> Hilco Wijbenga writes:
>>>
# On branch master
# Your branch and 'origin/master' have diverged,
# and have 250 and 19 different commit(s) each, respectively
On Tue, Aug 14, 2012 at 10:06 AM, Junio C Hamano wrote:
> Shawn Pearce writes:
>
>> Parsing the request line of git-daemon is easy. But we could make it
>> easier. An alternative arrangement would be to add a new command line
>> flag to git daemon like --command-filter that names an executable
>>
Charles Bailey writes:
> On Tue, Aug 14, 2012 at 08:06:56AM -0700, Junio C Hamano wrote:
>>
>> Could it be that the calling user or script does not even have a
>> terminal but still can spawn the chosen mergetool backend and
>> interact with the user via its GUI? Or it may have a terminal that
Hilco Wijbenga writes:
> On 14 August 2012 01:27, Thomas Rast wrote:
>> Hilco Wijbenga writes:
>>
>>> # On branch master
>>> # Your branch and 'origin/master' have diverged,
>>> # and have 250 and 19 different commit(s) each, respectively.
>>> #
>>> nothing to commit (working directory clean)
>
On Tue, Aug 14, 2012 at 08:06:56AM -0700, Junio C Hamano wrote:
>
> Could it be that the calling user or script does not even have a
> terminal but still can spawn the chosen mergetool backend and
> interact with the user via its GUI? Or it may have a terminal that
> is hard for the user to inter
On 14 August 2012 09:02, PJ Weisberg wrote:
> On Mon, Aug 13, 2012 at 12:58 PM, Hilco Wijbenga
> wrote:
>> Hi all,
>>
>> A colleague of mine (after a relatively long absence) noticed the
>> following when running "git status":
>>
>> # On branch master
>> # Your branch and 'origin/master' have div
Shawn Pearce writes:
> Parsing the request line of git-daemon is easy. But we could make it
> easier. An alternative arrangement would be to add a new command line
> flag to git daemon like --command-filter that names an executable
> git-daemon will invoke after parsing the request line. It can p
On 14 August 2012 01:27, Thomas Rast wrote:
> Hilco Wijbenga writes:
>
>> # On branch master
>> # Your branch and 'origin/master' have diverged,
>> # and have 250 and 19 different commit(s) each, respectively.
>> #
>> nothing to commit (working directory clean)
>>
>> He asked me what to do and I
On Tue, Aug 14, 2012 at 9:12 AM, Junio C Hamano wrote:
> Michal Novotny writes:
>
>> Hi,
>> this is the patch to introduce the ACL module architecture into git
>> versioning system.
>
> No, it doesn't. It adds something only to "git daemon", but does
> not affect any other uses of Git.
Yes, thi
Michal Novotny writes:
> Hi,
> this is the patch to introduce the ACL module architecture into git
> versioning system.
No, it doesn't. It adds something only to "git daemon", but does
not affect any other uses of Git.
Side note: I am not saying other uses of Git must be ACL
controlled
On 08/14/2012 10:04 AM, Junio C Hamano wrote:
> Michal Novotny writes:
>
>> this is the patch to limit repositories to be shown by the
>> ServerName in the gitweb.cgi script. This is useful for cases
>> you're hosting multiple websites on a single machine and you don't
>> want all the repos to be
Michal Novotny writes:
> this is the patch to limit repositories to be shown by the
> ServerName in the gitweb.cgi script. This is useful for cases
> you're hosting multiple websites on a single machine and you don't
> want all the repos to be shown in all of them.
> ...
> Use case scenario: Imag
On Mon, Aug 13, 2012 at 12:58 PM, Hilco Wijbenga
wrote:
> Hi all,
>
> A colleague of mine (after a relatively long absence) noticed the
> following when running "git status":
>
> # On branch master
> # Your branch and 'origin/master' have diverged,
> # and have 250 and 19 different commit(s) each,
> From: Junio C Hamano [mailto:gits...@pobox.com]
> Sent: Tuesday, August 14, 2012 4:44 PM
> To: Joachim Schmitz
> Subject: Re: git on HP NonStop
>
> "Joachim Schmitz" writes:
>
> > Interesting, I never mentioned Tandem did I, But still you recognized
> > HP NonStop as that.
>
> No, *you* did i
Thomas Rast writes:
> Junio C Hamano writes:
>
>> Thomas Rast writes:
>>
>>> So the --topo-order switch *ensures* that we process commits in
>>> topological order even in the face of skewed clocks.
>>
>> Yes, I *think* that I attempted to show with the illustration.
>
> But then the new descrip
Charles Bailey writes:
> On Tue, Aug 14, 2012 at 12:07:26AM -0700, David Aguilar wrote:
>> Right now there are two code paths, resolving deletion conflicts
>> and resolving symlink conflicts, in git-mergetool that do not
>> honor --no-prompt. They force user-interaction with the shell
>> even th
"Joachim Schmitz" writes:
>> /usr/local/bin/diff -EBbu ./git-compat-util.h.orig ./git-compat-util.h
>> --- ./git-compat-util.h.orig2012-07-30 15:50:38 -0500
>> +++ ./git-compat-util.h 2012-08-10 09:59:56 -0500
>> @@ -74,7 +74,8 @@
>> # define _XOPEN_SOURCE 500
>> # endif
>> #elif !defined(
Martin von Zweigbergk writes:
> Still, the "Even without this option" strongly suggests to me that
> what follows ("descendant commits are shown before parents") applies
> to the "By default" case. Would it be correct to say something like
> "By default, the commits are shown in reverse chronolog
Junio C Hamano writes:
> Thomas Rast writes:
>
>> So the --topo-order switch *ensures* that we process commits in
>> topological order even in the face of skewed clocks.
>
> Yes, I *think* that I attempted to show with the illustration.
But then the new description is wrong. It claims that chi
Thomas Rast writes:
> So the --topo-order switch *ensures* that we process commits in
> topological order even in the face of skewed clocks.
Yes, I *think* that I attempted to show with the illustration.
> I suspect that
>
>> +their parents, but this tries to avoid showing commits on
>> +
On Tue, Aug 14, 2012 at 11:55 AM, Thomas Rast wrote:
> Fun stuff. This will be very interesting to debug. It's still
> possible, though perhaps not extremely likely, that git is writing
> garbage to the terminal and it just happens to work for xterm.
>
> Whatever you do next, *please* post the *
Thomas Rast writes:
> Whatever you do next, *please* post the *exact* file contents *and*
> output in a format that does not suffer any transport damage, neither to
> whitespace nor to binary data (such as terminal escapes). Piping
> through xxd comes to mind, perhaps by using
>
> GIT_PAGER=xx
Hi,
this is the patch to introduce the ACL module architecture into git
versioning system. The variable of GIT_BASE_DIR is being used to seek
for the modules if available. If variable is unset then daemon looks
for the /etc/git-daemon.conf file existence and reads the
'base_path' key if it exists t
Bernd Jendrissek writes:
> On Tue, Aug 14, 2012 at 10:18 AM, Thomas Rast wrote:
>> Can you try the following:
>>
>> git ls-files --debug
>> gnetlist/tests/common/outputs/osmond/TwoStageAmp-output.net
>> cp .git/index .git/index.orig
>> touch gnetlist/tests/common/outputs/osmond/TwoStageAm
On Tue, Aug 14, 2012 at 10:18 AM, Thomas Rast wrote:
> That sounds like an issue with stat() data, and then it doesn't. cp -a
> would change all the inode numbers, triggering a full refresh of the
> index in 'git diff'. But I'm not sure exactly how this can lead to
> disagreement, since both com
Hi,
this is the patch to limit repositories to be shown
by the ServerName in the gitweb.cgi script. This is
useful for cases you're hosting multiple websites on
a single machine and you don't want all the repos to
be shown in all of them.
Functionality: Simply create file called 'server' in
Junio C Hamano writes:
> --topo-order::
> -
> - This option makes them appear in topological order (i.e.
> - descendant commits are shown before their parents).
> + This option makes them appear in topological order. Even
> + without this option, descendant commits are shown bef
On 08/14/2012 12:21 AM, Junio C Hamano wrote:
We said "--date-order" still does not violate the topology, but it
was still not clear enough.
Reword the description for both "--date-order" and "--topo-order",
and add an illustration to it.
Signed-off-by: Junio C Hamano
Thanks for this change.
Hilco Wijbenga writes:
> # On branch master
> # Your branch and 'origin/master' have diverged,
> # and have 250 and 19 different commit(s) each, respectively.
> #
> nothing to commit (working directory clean)
>
> He asked me what to do and I told him to do what has always worked for
> me in the p
Bernd Jendrissek writes:
> On Mon, Aug 13, 2012 at 5:02 PM, Thomas Rast wrote:
>> Can you share this repository?
>
> This weird behaviour doesn't even survive making a copy (cp -a) of the
> whole repository, so I very much doubt making it available would be
> illuminative. My disk's SMART data s
On Tue, Aug 14, 2012 at 12:07:26AM -0700, David Aguilar wrote:
> Right now there are two code paths, resolving deletion conflicts
> and resolving symlink conflicts, in git-mergetool that do not
> honor --no-prompt. They force user-interaction with the shell
> even though the caller (such as a prog
Right now there are two code paths, resolving deletion conflicts
and resolving symlink conflicts, in git-mergetool that do not
honor --no-prompt. They force user-interaction with the shell
even though the caller (such as a program) said that they do
not want to be prompted.
This was an oversight
> From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
> Sent: Friday, August 10, 2012 10:09 PM
> To: 'Shawn Pearce'
> Cc: 'git@vger.kernel.org'; 'rsbec...@nexbridge.com'
> Subject: RE: Porting git to HP NonStop
>
> > From: Joachim Schmitz [mailto:j...@schmitz-digital.de]
> > Sent: Friday, Augus
70 matches
Mail list logo
