* Re: [PATCH] git-sh-setup: Fix scripts whose PWD is a symlink into a git work-dir
From: Junio C Hamano @ 2008-12-03 7:20 UTC (permalink / raw)
To: Marcel M. Cary; +Cc: git, jnareb, ae, j.sixt
In-Reply-To: <1228282020-2294-1-git-send-email-marcel@oak.homeunix.org>
"Marcel M. Cary" <marcel@oak.homeunix.org> writes:
> If cd_to_toplevel had concatenated $(/bin/pwd) with $cdup to
> avoid the separate "cd", it would require checking for $cdup
> being an absolute path. I wasn't sure how to check that in
> a way that is both portable and clearly faster than "cd",
case "$v" in
/*) : handle absolute path ;;
*) : everything else ;;
esac
In all shells that support "case..esac", it is built-in.
Having said that, I think it would probably be better to bite the bullet
and start using "cd -P" soon after 1.6.1 goes final, and at the same time
existing places that use "cd `pwd`" as a workaround if there are some.
^ permalink raw reply
* "git help stage" doesn't display git-stage man page
From: Teemu Likonen @ 2008-12-03 7:27 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Scott Chacon
In-Reply-To: <7vvdu1hj41.fsf@gitster.siamese.dyndns.org>
Junio C Hamano (2008-12-02 22:23 -0800) wrote:
> * The 'master' branch has these since the last announcement
> in addition to the above.
> Scott Chacon (1):
> Add a built-in alias for 'stage' to the 'add' command
I think there's a minor user-interface defect:
$ git help stage
No manual entry for gitstage
"git stage" is only a built-in alias but at some point it may become the
primary staging command for new Git users and hence a kind of real Git
command. I think "git help stage" should show the git-stage manual page
(even though it only points to git-add(1)).
^ permalink raw reply
* Re: [man bug?] git rebase --preserve-merges
From: Andreas Ericsson @ 2008-12-03 7:43 UTC (permalink / raw)
To: Constantine Plotnikov; +Cc: git
In-Reply-To: <85647ef50812020845g7de701bbye4a43a4e992a264b@mail.gmail.com>
Constantine Plotnikov wrote:
> The man page for git rebase mentions "--preserve-merges" command line
> option but this option does not seems to be available.
>
> Also if this option is specified, the following usage statement is printed:
>
> Usage: git rebase [--interactive | -i] [-v] [--onto <newbase>]
> <upstream> [<branch>]
>
> And this usage statement does not mention -m and -s options that seems
> to be available. I assume that the problem is the obsolete
> documentation.
>
You're probably using an old git where merge-preserving rebase is only
available for interactive mode. Check the man-page again, and thoroughly
this time ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Implement rebase -q to fix pull --rebase -q
From: Junio C Hamano @ 2008-12-03 7:54 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git
In-Reply-To: <1228277212-5917-1-git-send-email-tuncer.ayaz@gmail.com>
Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:
> This is needed on top of the fetch/pull -q/-v changes
> to make
> $ git pull --rebase -q
> as quiet as expected.
I am not sure if this is worth it, in the sense that it is not really
quiet enough (iow, it is not what I expect even though you claim "as
expected" here), and in another sense that making it really quiet may not
be what we want anyway.
How are you dealing with messages from the actual replaying of each local
commit on top of what is fetched? In order to be able to tell where you
are when one of them fail in conflicts, you cannot stay silent while doing
so.
^ permalink raw reply
* Re: [PATCH] Implement rebase -q to fix pull --rebase -q
From: Tuncer Ayaz @ 2008-12-03 8:07 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vej0pheww.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 3, 2008 at 8:54 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Tuncer Ayaz <tuncer.ayaz@gmail.com> writes:
>
>> This is needed on top of the fetch/pull -q/-v changes
>> to make
>> $ git pull --rebase -q
>> as quiet as expected.
>
> I am not sure if this is worth it, in the sense that it is not really
> quiet enough (iow, it is not what I expect even though you claim "as
Junio, sorry for using 'expected'.
I thought about the wording while writing and had a feeling that 'expected'
may be too strong as it's my opinion only. I should have listened to myself :).
> expected" here), and in another sense that making it really quiet may not
> be what we want anyway.
I mainly use -q in automation where I only want output if something
goes wrong. Just like good old cp or mv do.
Do you think this is the wrong way to go?
> How are you dealing with messages from the actual replaying of each local
> commit on top of what is fetched? In order to be able to tell where you
> are when one of them fail in conflicts, you cannot stay silent while doing
> so.
Fair point.
Log messages that are of importance to a failure should ideally be sent to
stderr but I think caching log messages for the failure case would
over-complicate
much of the code and is not worth it. Also you may not always know which part
of stdout messages are useful for the failure case and not getting the
same messages
on a rerun for many commands makes this hard to trace back, yeah.
As we've quietened pull/fetch/clone in a major already I am OK with leaving this
change out.
I'm definitely not advocating adding/changing anything when it's not clear we
want the changed behavior. It's easier to keep out than to remove it
later on :).
^ permalink raw reply
* Re: "git help stage" doesn't display git-stage man page
From: Junio C Hamano @ 2008-12-03 8:14 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git, Scott Chacon
In-Reply-To: <87myfdn2ga.fsf@iki.fi>
Teemu Likonen <tlikonen@iki.fi> writes:
> Junio C Hamano (2008-12-02 22:23 -0800) wrote:
>
>> * The 'master' branch has these since the last announcement
>> in addition to the above.
>
>> Scott Chacon (1):
>> Add a built-in alias for 'stage' to the 'add' command
>
> I think there's a minor user-interface defect:
>
> $ git help stage
> No manual entry for gitstage
The patch also breaks the promise made at 1.6.0 that prepending exec path
to $PATH allows you to use the dashed form.
$ PATH=$(git --exec-path):$PATH
$ git-stage -p
xash: git-stage: cmd not found
> "git stage" is only a built-in alias but at some point it may become the
> primary staging command for new Git users and hence a kind of real Git
> command. I think "git help stage" should show the git-stage manual page
> (even though it only points to git-add(1)).
I do not think it would ever be _the_ primary command to add the contents
to the index; we are adding it as a training wheel.
When we had the "staging area" discussion, somehow people ended up with
this notion that you somehow *need to* use the same verb and noun.
I.e. "the index is now explained as the _staging area_. Why isn't the
command to add contents to the staging area called git-stage?" was the
primary argument that lead to this thinking.
I do not think it adds much value to the system to be dogmatic and insist
that you _have to_ use the same verb and noun. "You add your changes to
the staging area" is a perfectly natural way to explain what you are doing
and where the "add" in git-add command comes from. It however is Ok to
allow people to use different spelling (i.e. the verb "stage").
In that sense, I think the intention of the patch to add "stage" as an
additional verb, while clearly marking it as a synonym to the primary
command "add", is aimed at the right place and strikes the right balance.
By the way, I think this should fix it, although it is very late and I
have no time to test it tonight myself.
---
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git i/Makefile w/Makefile
index 9577d6f..5158197 100644
--- i/Makefile
+++ w/Makefile
@@ -320,6 +320,7 @@ BUILT_INS += git-merge-subtree$X
BUILT_INS += git-peek-remote$X
BUILT_INS += git-repo-config$X
BUILT_INS += git-show$X
+BUILT_INS += git-stage$X
BUILT_INS += git-status$X
BUILT_INS += git-whatchanged$X
^ permalink raw reply related
* fast-import problem importing dos format files under cygwin
From: Jan Hudec @ 2008-12-03 7:51 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1304 bytes --]
Hello folks,
I have been playing with fast-import in cygwin and I have problems
importing files with CR/LF line-endings. The size in data command is
calculated including the CRs and than the file is copied binary to the
fast-import input stream. However fast-import skips the CRs when reading,
overreads by that number of bytes and fails when it tries to read the next
command from the middle.
Attached is a test input stream and crash report generated by fast-import
when reading it. In case mail system damages it along the way despite
being attached to prevent that, the file should be in unix format -- that
is what my cygwin perl outputs by default -- and has CRs only on lines 15
and 16. The unix.txt and dos.txt should only differ that the '.'s in
former are replaced by '^M's in the later (so the data commands are
otherwise same).
Note, that when I convert the file to dos format, it is read as intended.
However, that is inconsistent with rest of the cygwin environment which
generated and expects files in unix format. I use binary mounts (not
converting) and CYGWIN environment variable is empty. My git version is
1.6.0.4 from official Cygwin package.
Is this behaviour intentional workaround for something or a bug?
--
- Jan Hudec <bulb@ucw.cz>
[-- Attachment #2: test1.gfi --]
[-- Type: /, Size: 495 bytes --]
commit refs/heads/master
committer Jan Hudec <bulb@ucw.cz> 1228287890 +0100
data 19
unix-formatted-file
M 100644 inline unix.txt
data 13
some.
lines.
commit refs/heads/master
committer Jan Hudec <bulb@ucw.cz> 1228287892 +0100
data 18
dos-formatted-file
M 100644 inline dos.txt
data 13
some
lines
commit refs/heads/master
committer Jan Hudec <bulb@ucw.cz> 1228287894 +0100
data 23
one more commit for fun
M 100644 inline other.txt
data 22
we need more commands
checkpoint
[-- Attachment #3: fast_import_crash_5212 --]
[-- Type: /, Size: 1034 bytes --]
fast-import crash report:
fast-import process: 5212
parent process : 1696
at Wed Dec 3 08:29:42 2008
fatal: Unsupported command: mmit refs/heads/master
Most Recent Commands Before Crash
---------------------------------
commit refs/heads/master
committer Jan Hudec <bulb@ucw.cz> 1228287890 +0100
data 19
M 100644 inline unix.txt
data 13
commit refs/heads/master
committer Jan Hudec <bulb@ucw.cz> 1228287892 +0100
data 18
M 100644 inline dos.txt
data 13
* mmit refs/heads/master
Active Branch LRU
-----------------
active_branches = 1 cur, 5 max
pos clock name
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1) 2 refs/heads/master
Inactive Branches
-----------------
refs/heads/master:
status : active loaded
tip commit : 2a11b753d155443462523e0f3cef72e4f02817b2
old tree : 5bcdcdcafba5303797865311a7fa06e2ce3ddc65
cur tree : 5bcdcdcafba5303797865311a7fa06e2ce3ddc65
commit clock: 2
last pack : 0
Marks
-----
-------------------
END OF CRASH REPORT
^ permalink raw reply
* Re: [PATCH] Implement rebase -q to fix pull --rebase -q
From: Junio C Hamano @ 2008-12-03 8:26 UTC (permalink / raw)
To: Tuncer Ayaz; +Cc: git
In-Reply-To: <4ac8254d0812030007w3217f6eei3d364ce2272930c3@mail.gmail.com>
"Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
> I mainly use -q in automation where I only want output if something
> goes wrong. Just like good old cp or mv do.
> Do you think this is the wrong way to go?
>
>> How are you dealing with messages from the actual replaying of each local
>> commit on top of what is fetched? In order to be able to tell where you
>> are when one of them fail in conflicts, you cannot stay silent while doing
>> so.
>
> Fair point.
Ahh, ok, if this is for cron jobs, then it is understandable that:
(1) You may want a successful "git pull" or "git pull --rebase" to be
absolutely silent about what it did; and
(2) A failed "git pull" and "git pull --rebase" that produces information
other than the fact it failed would not help you, the receiver of a
cron job report, very much. You would go to the repository when it
fails, reset the mess away, and then do the pull or pull-rebase
yourself manually anyway.
If that is the motivation behind the series, I think you would really want
to squelch output from "format-patch | am -3" pipeline.
Another thing to consider is that, unlike simple single-operation commands
such as "mv" or "cp" you mentioned, what "git pull" does is much more
involved and has many different failure modes, so you cannot compare them
fairly. Simple commands can have a single "quiet" level, but I have a
feeling that there is a difference between "quiet mode" I expect when I am
running "git pull" interactively and "quiet mode" I would want when I
would be driving "git pull" from a cron job. IOW, you probably would want
something like "--really-quiet" mode.
I would write such a cron-job script to capture the log and send it only
upon failure from the underlying command if I were doing this myself,
though.
^ permalink raw reply
* Re: "git help stage" doesn't display git-stage man page
From: Teemu Likonen @ 2008-12-03 8:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Scott Chacon
In-Reply-To: <7vwsehfzf7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano (2008-12-03 00:14 -0800) wrote:
> By the way, I think this should fix it, although it is very late and I
> have no time to test it tonight myself.
It does fix it for me. Thanks.
> diff --git i/Makefile w/Makefile
> index 9577d6f..5158197 100644
> --- i/Makefile
> +++ w/Makefile
> @@ -320,6 +320,7 @@ BUILT_INS += git-merge-subtree$X
> BUILT_INS += git-peek-remote$X
> BUILT_INS += git-repo-config$X
> BUILT_INS += git-show$X
> +BUILT_INS += git-stage$X
> BUILT_INS += git-status$X
> BUILT_INS += git-whatchanged$X
^ permalink raw reply
* Re: "git help stage" doesn't display git-stage man page
From: Junio C Hamano @ 2008-12-03 8:34 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git, Scott Chacon
In-Reply-To: <7vwsehfzf7.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Teemu Likonen <tlikonen@iki.fi> writes:
>
>>> Scott Chacon (1):
>>> Add a built-in alias for 'stage' to the 'add' command
>>
>> I think there's a minor user-interface defect:
>>
>> $ git help stage
>> No manual entry for gitstage
>
> ...
> In that sense, I think the intention of the patch to add "stage" as an
> additional verb, while clearly marking it as a synonym to the primary
> command "add", is aimed at the right place and strikes the right balance.
>
> By the way, I think this should fix it, although it is very late and I
> have no time to test it tonight myself.
Ok, I lied. I'll go to bed after committing this.
-- >8 --
From: Junio C Hamano <gitster@pobox.com>
Date: Wed, 3 Dec 2008 00:30:34 -0800
Subject: [PATCH] Install git-stage in exec-path
Earlier the plan was to eventually eradicate git-foo executables from the
filesystem for all the built-in commands, but when we released 1.6.0 we
decided not to do so. Instead, it has been promised that by prepending
the output from $(git --exec-path) to your $PATH, you can keep using the
dashed form of commands.
This also allows "git stage" to appear in the autogenerated command list,
which is used to offer man pages by "git help" command.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 9577d6f..5158197 100644
--- a/Makefile
+++ b/Makefile
@@ -320,6 +320,7 @@ BUILT_INS += git-merge-subtree$X
BUILT_INS += git-peek-remote$X
BUILT_INS += git-repo-config$X
BUILT_INS += git-show$X
+BUILT_INS += git-stage$X
BUILT_INS += git-status$X
BUILT_INS += git-whatchanged$X
--
1.6.1.rc1.44.g06a3
^ permalink raw reply related
* Re: [PATCH] Implement rebase -q to fix pull --rebase -q
From: Tuncer Ayaz @ 2008-12-03 8:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vr64pfyvg.fsf@gitster.siamese.dyndns.org>
On Wed, Dec 3, 2008 at 9:26 AM, Junio C Hamano <gitster@pobox.com> wrote:
> "Tuncer Ayaz" <tuncer.ayaz@gmail.com> writes:
>
>> I mainly use -q in automation where I only want output if something
>> goes wrong. Just like good old cp or mv do.
>> Do you think this is the wrong way to go?
>>
>>> How are you dealing with messages from the actual replaying of each local
>>> commit on top of what is fetched? In order to be able to tell where you
>>> are when one of them fail in conflicts, you cannot stay silent while doing
>>> so.
>>
>> Fair point.
>
> Ahh, ok, if this is for cron jobs, then it is understandable that:
>
> (1) You may want a successful "git pull" or "git pull --rebase" to be
> absolutely silent about what it did; and
>
> (2) A failed "git pull" and "git pull --rebase" that produces information
> other than the fact it failed would not help you, the receiver of a
> cron job report, very much. You would go to the repository when it
> fails, reset the mess away, and then do the pull or pull-rebase
> yourself manually anyway.
>
> If that is the motivation behind the series, I think you would really want
> to squelch output from "format-patch | am -3" pipeline.
You mean I should follow this path and produce a patch series instead?
> Another thing to consider is that, unlike simple single-operation commands
> such as "mv" or "cp" you mentioned, what "git pull" does is much more
> involved and has many different failure modes, so you cannot compare them
> fairly. Simple commands can have a single "quiet" level, but I have a
> feeling that there is a difference between "quiet mode" I expect when I am
> running "git pull" interactively and "quiet mode" I would want when I
We have the same expectation here and IDE writers also seem to expect that.
> would be driving "git pull" from a cron job. IOW, you probably would want
> something like "--really-quiet" mode.
Yeah, it gets messy and in the current codebase. I am also not sure whether
the effort/benefit ratio is good enough.
> I would write such a cron-job script to capture the log and send it only
> upon failure from the underlying command if I were doing this myself,
> though.
This is the way I do it now and I'm surprised I found no other simple way
than writing a wrapper script for it. At least not with vixie-cron.
^ permalink raw reply
* Re: git-svn with multiple remote repositories?
From: Michael J Gruber @ 2008-12-03 8:45 UTC (permalink / raw)
To: Josef Wolf, git
In-Reply-To: <20081202213930.GD12716@raven.wolf.lan>
Josef Wolf venit, vidit, dixit 02.12.2008 22:39:
> Hello,
>
> I am trying to create a git repository with two remote svn repositories
> so that I can merge/move patch-sets back and forth between the svn
> repositories.
>
> This is what I have tried so far:
>
> mkdir -p project
> cd project
> git-svn init -R private -s https://foo.bar/repos/private
>
> Then I go and edit .git/config too look like this:
>
> [core]
> repositoryformatversion = 0
> filemode = true
> bare = false
> logallrefupdates = true
> [svn-remote "private"]
> url = https://foo.bar/repos/private
> fetch = trunk:refs/remotes/private/trunk
> branches = branches/*:refs/remotes/private/*
> tags = tags/*:refs/remotes/private/tags/*
> [svn-remote "public"]
> url = https://foo.bar/repos/public
> fetch = trunk:refs/remotes/public/trunk
> branches = branches/*:refs/remotes/public/*
> tags = tags/*:refs/remotes/public/tags/*
>
> And finally, I do
>
> git-svn fetch -R private
> git-svn fetch -R public
>
> Both commands seem to fetch the contents from their origins. But
> git-branch shows me only the local master branch with contents from
> the "private" svn repository. When I do
>
> git checkout public/trunk
>
> the contents actually change to reflect the "public" svn repository,
> but git-branch says I am on "(no branch)" at all.
You want "git branch -a" if you want to see all branches including
remotes. "master" happens to reflect "remotes/private/trunk" because the
first fetch set it up like that. Further fetches will not change master.
Remote branches are your local copy, but different from local branches:
you're not supposed to check them out, and if you do anyways, you get a
"detached HEAD". Well, your repo gets a detached HEAD...
If you want to work with remote branches, create a tracking branch: a
local branch that is based on a remote one and that is set up to rebase
(or merge) new commits from the remote:
git checkout -b mypublic/trunk remotes/public/trunk
You can name the local branch any way you want, even "public/trunk", but
that may lead to confusion when you look at the output of "git branch
-a" which suppresses the "remote/" part.
Michael
^ permalink raw reply
* Ad: fast-import problem importing dos format files under cygwin
From: Jan Hudec @ 2008-12-03 9:10 UTC (permalink / raw)
To: git
In-Reply-To: <43827.194.138.12.144.1228290700.squirrel@artax.karlin.mff.cuni.cz>
On 3 December 2008, 08:51, Jan Hudec wrote:
> Hello folks,
>
> I have been playing with fast-import in cygwin and I have problems
> importing files with CR/LF line-endings. The size in data command is
> calculated including the CRs and than the file is copied binary to the
> fast-import input stream. However fast-import skips the CRs when reading,
> overreads by that number of bytes and fails when it tries to read the
> next command from the middle.
One addition:
I have tried with MSYS version 1.5.6.1.1071.g76fb and it imported the
test, as it was, except it didn't like 'refs/heads/master' as branchname
(and accepted bare 'master', but that created '.git/master').
--
- Jan Hudec <bulb@ucw.cz>
^ permalink raw reply
* Re: [PATCH 0/2] gitweb: patch view
From: Giuseppe Bilotta @ 2008-12-03 9:25 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Petr Baudis, Junio C Hamano
In-Reply-To: <200812011202.41300.jnareb@gmail.com>
On Mon, Dec 1, 2008 at 12:02 PM, Jakub Narebski <jnareb@gmail.com> wrote:
> On Mon, 1 December 2008, Giuseppe Bilotta wrote:
>> On Mon, Dec 1, 2008 at 1:45 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>> On Sun, 30 Nov 2008, Giuseppe Bilotta wrote:
>>>> On Sun, Nov 30, 2008 at 2:06 AM, Jakub Narebski <jnareb@gmail.com> wrote:
>>>>> On Sat, 29 Nov 2008, Giuseppe Bilotta wrote:
>>>>
>>>>> By the way, we still might want to add somehow X-Git-Url and X-Git-Tag
>>>>> headers later to 'patch' ('patchset') output format.
>>>>
>>>> Yeah, I've been thinking about it, but I couldn't find an easy and
>>>> robust way to do it. Plus, should we add them for each patch, or just
>>>> once for the whole patchset?
>>>
>>> True, that is a complication. Perhaps they should be added only for
>>> single patch?
>>
>> Although that's rather easy to implement technically, it also creates
>> some kind of inconsistency.
>
> Well, it is problem also from technical point of view. Currently we can
> just stream (dump) git-format-patch output to browser (not forgetting
> adding '--encoding=utf8' if it is not used already), and do not need
> to have markers between commits. It is very simple code, which is its
> own advantage.
>
> From theoretical point of view corrected X-Git-Tag functioning as
> a kind of ref marker but for the raw (text/plain) output could be added
> for each end every patch, so there would be no inconsistency for _this_
> extra header.
>
> I don't know what can be done about X-Git-URL.
I'm thinking that the best way to achieve these results would be to
have some way to specify extra headers to git format-patch from the
command line and not just from a config file. Plus, we want to make
them 'dynamic' in the sense that we want to be able to put hash or ref
names etc in them. For the moment I'll mark this 'TODO' in the file.
>>>> Considering I think commitdiff is ugly and long, you can guess my
>>>> opinion on format_patch 8-P. 'patchset' might be a good candidate,
>>>> considering it's what it does when both hash_parent and hash are
>>>> given.
>>>
>>> True, 'patchset' might be even better, especially that it hints
>>> what it does for a range a..b (not diff of endpoints, but series
>>> of patches).
>>
>> Good, I'll rename it.
>
> I just don't know if it would be best name. Perhaps 'patches' would
> be better?
The only thing I don't like about 'patches' is that if you ask for a
single commit you get a single patch. I'd rather stick to 'patch'
then, maybe make 'patches' a synonym?
>>>> * diff(_plain): do what commitdiff(_plain) currently does for
>>>> parent..hash views, modulo something to be discussed for commit
>>>> messages (a shortlog rather maybe?)
>>>
>>> Equivalent of "git diff" (or "git diff-tree").
>>>
>>> Diffstat, or dirstat might be a good idea. Shortlog... I am not sure.
>>> Diff is about endpoints, and they can be in reverse, too.
>>>
>>> There is a problem how to denote endpoints.
>>
>> Hm? Doesn't parent..hash work? Or are you talking about something else?
>
> Errr... I meant here for the user, not for gitweb. To somehow denote
> before patch itself the endpoints. Just like for diff _for_ a commit
> we have commit message denoting :-).
Ah, in the sense that you have to specify parent..hash manually in the
URL presently? I've seen some patches to non-main gitweb doing this
kind of thing. If it got merged with upstream we could use that as
well.
>>>> * patch[set?][_plain?]: format-patch style output (maybe with option
>>>> for HTML stuff too)
>>>
>>> Equivalent of "git format-patch".
>>>
>>> Actually the HTML format would be more like "git log -p", so perhaps
>>> that could be handled simply as a version of 'log' view (perhaps via
>>> @extra_options aka 'opt' parameter).
>>
>> This is starting to get complicated ... I'm not sure how far in this I
>> can go with this patchset, so for the time being I'll probably just
>> stick to refining the (plain) patchset feature.
>
> What I meant here is that it would be IMHO enough to have 'patch' view
> (or whatever it ends up named) be raw format / plain/text format only,
> and leave HTML equivalent for extra options/extra format to 'log' view.
Ah, ok. I'll resubmit a cleaned up version of these two patches for
the time being then.
>>>>>> The second patch exposes it from commitdiff view (obviosly), but also
>>>>>> from shortlog view, when less than 16 patches are begin shown.
>>>>>
>>>>> Why this nonconfigurable limit?
>>>>
>>>> Because the patch was actually a quick hack for the proof of concept
>>>> 8-) I wasn't even sure the patch idea would have been worth it (as
>>>> opposed to email-izing commitdiff_plain).
>>>
>>> Ah.
>>>
>>> Well, we might want to impose some limit to avoid generating and sending
>>> patchset for a whole history. Perhaps to page size (100), or some similar
>>> number?
>>
>> The reason why I chose 16 is that (1) it's a rather commonly used
>> 'small' number across gitweb and (2) it's a rather acceptable
>> 'universal' upper limit for patchsets. There _are_ a few patchbombs
>> that considerably overtake that limit, but observe that this limit is
>> not an arbitrary limit on patchsets generated by the 'patchset' view,
>> but only a condition for which a link is generated from shortlog view.
>
> I see.
>
>> We may want to have TWO limits here: one is the absolute maximum limit
>> to the number of patches dumped in a patchset (to prevent DoS attacks
>> by repeated requests of the whole history), and the other one is the
>> limit for autogenerated patchset links.
>
> A pageful (100 commits) as hard limit against DoS attacks?
I suspect 100 is too hight already, but I guess we can tune it later.
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* [PATCH] Make t9128-git-svn-cmd-branch pass with svn 1.4
From: Michael J Gruber @ 2008-12-03 9:30 UTC (permalink / raw)
To: git
In-Reply-To: <7vbpvtj4kl.fsf@gitster.siamese.dyndns.org>
The copy command in svn 1.4 allows only one source (svn copy A D), whereas
the copy command in svn 1.5 allows multiple sources (svn copy A B C D).
This patch rewrites t9128 to use the backwards compatible form.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
t/t9128-git-svn-cmd-branch.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/t/t9128-git-svn-cmd-branch.sh b/t/t9128-git-svn-cmd-branch.sh
index e2b6696..252daa7 100755
--- a/t/t9128-git-svn-cmd-branch.sh
+++ b/t/t9128-git-svn-cmd-branch.sh
@@ -61,7 +61,9 @@ test_expect_success 'branch uses correct svn-remote' '
cd svn &&
mkdir mirror &&
svn add mirror &&
- svn copy trunk tags branches mirror/ &&
+ svn copy trunk mirror/ &&
+ svn copy tags mirror/ &&
+ svn copy branches mirror/ &&
svn ci -m "made mirror" ) &&
rm -rf svn &&
git svn init -s -R mirror --prefix=mirror/ "$svnrepo"/mirror &&
--
1.6.1.rc1
^ permalink raw reply related
* Re: [PATCH] git-svn: Make branch use correct svn-remote
From: Michael J Gruber @ 2008-12-03 9:33 UTC (permalink / raw)
To: Git Mailing List; +Cc: Junio C Hamano, Eric Wong, Deskin Miller
In-Reply-To: <7vbpvtj4kl.fsf@gitster.siamese.dyndns.org>
Junio C Hamano venit, vidit, dixit 03.12.2008 04:55:
> Eric Wong <normalperson@yhbt.net> writes:
>
>> Deskin Miller <deskinm@umich.edu> wrote:
>>> The 'branch' subcommand incorrectly had the svn-remote to use hardcoded
>>> as 'svn', the default remote name. This meant that branches derived
>>> from other svn-remotes would try to use the branch and tag configuration
>>> for the 'svn' remote, potentially copying would-be branches to the wrong
>>> place in SVN, into the branch namespace for another project.
>>>
>>> Fix this by using the remote name extracted from the svn info for the
>>> specified git ref. Add a testcase for this behaviour.
>>>
>>> Signed-off-by: Deskin Miller <deskinm@umich.edu>
>> Looks alright to me, thanks Deskin.
>>
>> Acked-by: Eric Wong <normalperson@yhbt.net>
>
> Does not work for me X-<.
>
> * expecting success:
> (svn co "$svnrepo" svn &&
> cd svn &&
> mkdir mirror &&
> svn add mirror &&
> svn copy trunk tags branches mirror/ &&
> svn ci -m "made mirror" ) &&
> rm -rf svn &&
> git svn init -s -R mirror --prefix=mirror/ "$svnrepo"/mirror &&
> git svn fetch -R mirror &&
> git checkout mirror/trunk &&
> base=$(git rev-parse HEAD:) &&
> git svn branch -m "branch in mirror" d &&
> test $base = $(git rev-parse remotes/mirror/d:) &&
> test_must_fail git rev-parse remotes/d
>
> A svn/trunk
> A svn/trunk/foo
> A svn/branches
> A svn/branches/a
> A svn/branches/a/foo
> A svn/branches/b
> A svn/branches/b/foo
> A svn/tags
> A svn/tags/tag4
> A svn/tags/tag4/foo
> A svn/tags/tag1
> A svn/tags/tag1/foo
> A svn/tags/tag2
> A svn/tags/tag2/foo
> A svn/tags/tag3
> A svn/tags/tag3/foo
> Checked out revision 8.
> A mirror
> svn: Client error in parsing arguments
> * FAIL 4: branch uses correct svn-remote
>
> (svn co "$svnrepo" svn &&
> cd svn &&
> mkdir mirror &&
> svn add mirror &&
> svn copy trunk tags branches mirror/ &&
With my svn (1.4.6) it fails already here: "svn copy" allows two
arguments only. That may be different in svn 1.5.
> svn ci -m "made mirror" ) &&
> rm -rf svn &&
> git svn init -s -R mirror --prefix=mirror/ "$svnrepo"/mirror &&
> git svn fetch -R mirror &&
> git checkout mirror/trunk &&
> base=$(git rev-parse HEAD:) &&
> git svn branch -m "branch in mirror" d &&
> test $base = $(git rev-parse remotes/mirror/d:) &&
> test_must_fail git rev-parse remotes/d
If I split the above copy into three lines then the test passes (svn
1.4.6, Deskin's patch applied onto 1.6.1-rc1 with the fix.
Patch coming. (Sorry I always forget the ccs with send-email.)
Michael
^ permalink raw reply
* [RFCv2 0/2] gitweb: patch view
From: Giuseppe Bilotta @ 2008-12-03 10:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
Another go at the patch view feature. I'm marking this as RFC because
there are still a couple of points that need to be agreed on, esp. wrt
to the patch limiting and the insertion of extra X-Git-* email headers.
Giuseppe Bilotta (2):
gitweb: add patch view
gitweb: links to patch action in commitdiff and shortlog view
Makefile | 2 ++
gitweb/gitweb.perl | 39 +++++++++++++++++++++++++++++++++++++--
2 files changed, 39 insertions(+), 2 deletions(-)
^ permalink raw reply
* [RFCv2 1/2] gitweb: add patch view
From: Giuseppe Bilotta @ 2008-12-03 10:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1228298862-28191-1-git-send-email-giuseppe.bilotta@gmail.com>
The manually-built email format in commitdiff_plain output is not
appropriate for feeding git-am, because of two limitations:
* when a range of commits is specified, commitdiff_plain publishes a
single patch with the message from the first commit, instead of a
patchset,
* in either case, the patch summary is replicated both as email subject
and as first line of the email itself, resulting in a doubled summary
if the output is fed to git-am.
We thus create a new view that can be fed to git-am directly by exposing
the output of git format-patch directly. This allows patch exchange and
submission via gitweb. A hard limit (configurable, defaults to 100) is
imposed on the number of commits which will be included in a patchset,
to prevent DoS attacks on the server.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Makefile | 2 ++
gitweb/gitweb.perl | 30 +++++++++++++++++++++++++++++-
2 files changed, 31 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 5a69a41..dbf414c 100644
--- a/Makefile
+++ b/Makefile
@@ -220,6 +220,7 @@ GITWEB_LOGO = git-logo.png
GITWEB_FAVICON = git-favicon.png
GITWEB_SITE_HEADER =
GITWEB_SITE_FOOTER =
+GITWEB_PATCH_MAX = 100
export prefix bindir sharedir htmldir sysconfdir
@@ -1210,6 +1211,7 @@ gitweb/gitweb.cgi: gitweb/gitweb.perl
-e 's|++GITWEB_FAVICON++|$(GITWEB_FAVICON)|g' \
-e 's|++GITWEB_SITE_HEADER++|$(GITWEB_SITE_HEADER)|g' \
-e 's|++GITWEB_SITE_FOOTER++|$(GITWEB_SITE_FOOTER)|g' \
+ -e 's|++GITWEB_PATCH_MAX++|$(GITWEB_PATCH_MAX)|g' \
$< >$@+ && \
chmod +x $@+ && \
mv $@+ $@
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 2738643..10cbe93 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -87,6 +87,9 @@ our $projects_list = "++GITWEB_LIST++";
# the width (in characters) of the projects list "Description" column
our $projects_list_description_width = 25;
+# the maximum number of patches allowed in patch view
+our $patch_max = "++GITWEB_PATCH_MAX++";
+
# default order of projects list
# valid values are none, project, descr, owner, and age
our $default_projects_order = "project";
@@ -503,6 +506,7 @@ our %actions = (
"heads" => \&git_heads,
"history" => \&git_history,
"log" => \&git_log,
+ "patch" => \&git_patch,
"rss" => \&git_rss,
"atom" => \&git_atom,
"search" => \&git_search,
@@ -5483,7 +5487,12 @@ sub git_commitdiff {
open $fd, "-|", git_cmd(), "diff-tree", '-r', @diff_opts,
'-p', $hash_parent_param, $hash, "--"
or die_error(500, "Open git-diff-tree failed");
-
+ } elsif ($format eq 'patch') {
+ open $fd, "-|", git_cmd(), "format-patch", '--encoding=utf8',
+ '--stdout', "-$patch_max",
+ $hash_parent ? ('-n', "$hash_parent..$hash") :
+ ('--root', '-1', $hash)
+ or die_error(500, "Open git-format-patch failed");
} else {
die_error(400, "Unknown commitdiff format");
}
@@ -5532,6 +5541,15 @@ sub git_commitdiff {
print to_utf8($line) . "\n";
}
print "---\n\n";
+ } elsif ($format eq 'patch') {
+ my $filename = basename($project) . "-$hash.patch";
+
+ print $cgi->header(
+ -type => 'text/plain',
+ -charset => 'utf-8',
+ -expires => $expires,
+ -content_disposition => 'inline; filename="' . "$filename" . '"');
+ # TODO add X-Git-Tag/X-Git-Url headers in a sensible way
}
# write patch
@@ -5553,6 +5571,11 @@ sub git_commitdiff {
print <$fd>;
close $fd
or print "Reading git-diff-tree failed\n";
+ } elsif ($format eq 'patch') {
+ local $/ = undef;
+ print <$fd>;
+ close $fd
+ or print "Reading git-format-patch failed\n";
}
}
@@ -5560,6 +5583,11 @@ sub git_commitdiff_plain {
git_commitdiff('plain');
}
+# format-patch-style patches
+sub git_patch {
+ git_commitdiff('patch');
+}
+
sub git_history {
if (!defined $hash_base) {
$hash_base = git_get_head_hash($project);
--
1.5.6.5
^ permalink raw reply related
* [RFCv2 2/2] gitweb: links to patch action in commitdiff and shortlog view
From: Giuseppe Bilotta @ 2008-12-03 10:07 UTC (permalink / raw)
To: git; +Cc: Jakub Narebski, Petr Baudis, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <1228298862-28191-2-git-send-email-giuseppe.bilotta@gmail.com>
In shortlog view, a link to the patchset is only offered when the number
of commits shown is less than the allowed maximum number of patches.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
gitweb/gitweb.perl | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 10cbe93..aea0e07 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -5403,7 +5403,9 @@ sub git_commitdiff {
if ($format eq 'html') {
$formats_nav =
$cgi->a({-href => href(action=>"commitdiff_plain", -replay=>1)},
- "raw");
+ "raw") . " | " .
+ $cgi->a({-href => href(action=>"patch", -replay=>1)},
+ "patch");
if (defined $hash_parent &&
$hash_parent ne '-c' && $hash_parent ne '--cc') {
@@ -5938,6 +5940,11 @@ sub git_shortlog {
$cgi->a({-href => href(-replay=>1, page=>$page+1),
-accesskey => "n", -title => "Alt-n"}, "next");
}
+ if ($#commitlist <= $patch_max) {
+ $paging_nav .= " ⋅ " .
+ $cgi->a({-href => href(action=>"patch", -replay=>1)},
+ $#commitlist > 1 ? "patchset" : "patch");
+ }
git_header_html();
git_print_page_nav('shortlog','', $hash,$hash,$hash, $paging_nav);
--
1.5.6.5
^ permalink raw reply related
* Re: [PATCH] gitweb: Fix handling of non-ASCII characters in inserted HTML files
From: Jakub Narebski @ 2008-12-03 10:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Tatsuki Sugiura, Gerrit Pape, Recai Oktas
In-Reply-To: <7v63m1j4ke.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
> > Use new insert_file() subroutine to insert HTML chunks from external
> > files: $site_header, $home_text (by default indextext.html),
> > $site_footer, and $projectroot/$project/REAME.html.
> >
> > All non-ASCII chars of those files will be broken by Perl IO layer
> > without decoding to utf8, so insert_file() does to_utf8() on each
> > printed line; alternate solution would be to open those files with
> > "binmode $fh, ':utf8'", or even all files with "use open qw(:std :utf8)".
> > This is more complete solution that the one provided by Tatsuki Sugiura
> > in original patch
> >
> > [PATCH] gitweb: fix encode handling for site_{header,footer}
> > Msg-Id: <87vdumbxgc.wl@vaj-k-334-sugi.local.valinux.co.jp>
> > http://thread.gmane.org/gmane.comp.version-control.git/101199
>
> It may be more complete but it is obviously untested. Please help me
> trust you better with your future patches. Because I personally do not
> run gitweb myself, I really need a trustworthy lieutenant(s) in the area.
>
> [Wed Dec 3 01:52:07 2008] gitweb.perl: Global symbol "$fd" requires explicit package name at /git.git/t/../gitweb/gitweb.perl line 4500.
> [Wed Dec 3 01:52:07 2008] gitweb.perl: Execution of /git.git/t/../gitweb/gitweb.perl aborted due to compilation errors.
>
> > but it is in principle the same solution.
> >
> > I think this one as it is a bugfix should go in git 1.6.1
>
> Trading a gitweb with a small bug with a gitweb that does not even pass
> its test script does not feel like a good change to me.
>
> I think the breakage is the "close $fd" at the end of this hunk:
[...]
> I'll queue it to 'pu', with the "close $fd" removed, for now.
I'm very sorry about that. It was a bit of time since my last patch
sent, and I forgot that nevermind how obvious and simple the change,
one should run relevant parts of test suite, or at least try to run
gitweb / changed command.
With "close $fd" removed the patch is correct (and patches t9500*).
--
Jakub Narebski
Poland
^ permalink raw reply
* Is there a way to control the number of revisions will be saved by git
From: Tzury Bar Yochay @ 2008-12-03 11:01 UTC (permalink / raw)
To: git
Hello Happy Gitters,
Say I wish to save only 100 generations back (per branch).
Is it possible to configure git so it will save only N records back.
If git cannot be configured for that, Is there a way to shrink the repository
manually so it will contain the last N generations?
- Tzury
^ permalink raw reply
* Problems with EGit
From: Bastian Flinspach @ 2008-12-03 11:08 UTC (permalink / raw)
To: git
Hi everyone.
I am a newbie in regards to Linux and especially git. I worked with SVN
for some time, but mainly as a client.
Never the less, i wanted to set up some form of code repository for my
workplace and git seems to be a good fit.
So i installed git on our local development server here in our office. I
am the only developer at the time, so i can do as i please. :-)
The Server is a debian machine, essentially only running a web server (I
develop web apps), which webroot directory is also shared via samba with
the otherwise all windows network. The first Version of git i got from
the apt was an old one and after some struggling, i managed to update it
to 1.6.0.3.g9f8f13. I also created my repository and installed EGit in
my eclipse 3.4.
In Eclipse, i linked to the samba Folder containing the code.
When i try to commit changes via the command line, everything works fine
(well, except for me not being able to use my keyboard right for
entering the commit message, but thats probably not important because i
want to use EGit anyways).
Eclipse recognizes the repository and also displays changes i make. When
trying to commit, however, i get a permission denied error.
So, this is basically where i am stuck. What can be the problem and what
would be a solution? I assume, that i might have something to do with
Linux users and privileges, but i am not yet versed enough to identify
the problem on my own.
Please keep in mind, that i am a complete beginner with these topics
when answering.
I would appreciate your help.
best regards
Bastian Flinspach
^ permalink raw reply
* Re: [RFCv2 1/2] gitweb: add patch view
From: Junio C Hamano @ 2008-12-03 11:19 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Jakub Narebski, Petr Baudis
In-Reply-To: <1228298862-28191-2-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta <giuseppe.bilotta@gmail.com> writes:
> We thus create a new view that can be fed to git-am directly by exposing
> the output of git format-patch directly. This allows patch exchange and
> submission via gitweb. A hard limit (configurable, defaults to 100) is
> imposed on the number of commits which will be included in a patchset,
> to prevent DoS attacks on the server.
Hmm, I would imagine that "snapshot" would be a much more effective way to
do such an attack, and notice the way we prevent it is to selectively
enable the feature per repository.
Perhaps this configuration should also be a feature defined in %feature,
overridable by each repository? If you default it to "disabled" (as any
new feature typically does), you do not have to yank a random number such
as 100 out of thin air.
^ permalink raw reply
* [BUG] git bisect visualize crash
From: Alejandro Riveira @ 2008-12-03 11:20 UTC (permalink / raw)
To: git
i'm using ubuntu 8.10 and git bisect visualize is crashing.
Noticed when bisecting the kernel but it is easily reproducible
in git repository as of today
$ git bisect bad
$ git bisect good HEAD~20
$ git bisect visualize (03-12 12:16)
Error in startup script: can't read "notflag": no such variable
while executing
"expr {!$notflag}"
("--not" arm line 2)
invoked from within
"switch -glob -- $arg {
"-d" -
"--date-order" {
set vdatemode($n) 1
# remove from origargs in case we hit an unknown option
set origarg..."
(procedure "parseviewargs" line 21)
invoked from within
"parseviewargs $view $args"
(procedure "start_rev_list" line 27)
invoked from within
"start_rev_list $curview"
(procedure "getcommits" line 5)
invoked from within
"getcommits {}"
(file "/usr/local/bin/gitk" line 10897)
$ git --version
git version 1.6.1.rc1
$
^ permalink raw reply
* Re: Is there a way to control the number of revisions will be saved by git
From: Johannes Sixt @ 2008-12-03 11:22 UTC (permalink / raw)
To: Tzury Bar Yochay; +Cc: git
In-Reply-To: <2f5ea7490812030301p29e944fw5f59943dc352cd09@mail.gmail.com>
Tzury Bar Yochay schrieb:
> Hello Happy Gitters,
>
> Say I wish to save only 100 generations back (per branch).
> Is it possible to configure git so it will save only N records back.
No.
> If git cannot be configured for that, Is there a way to shrink the repository
> manually so it will contain the last N generations?
Yes:
$ git rev-parse HEAD~$N >> .git/info/grafts
$ git filter-branch HEAD
This assumes that your history is strictly linear and you do not have
tags. It also rewrites the $N commits so that they now have different
SHA1s. For this reason, don't share this repository with anyone - it leads
to confusion.
-- Hannes
^ 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