* Re: gitweb index performance (Re: [PATCH] gitweb: support the rel=vcs-* microformat)
From: Jakub Narebski @ 2009-01-10 1:44 UTC (permalink / raw)
To: J.H.; +Cc: Joey Hess, git, Giuseppe Bilotta
In-Reply-To: <496691EC.1070805@eaglescrag.net>
"J.H." <warthog19@eaglescrag.net> writes:
> Joey Hess wrote:
>> Giuseppe Bilotta wrote:
>>
>>>> There is a small overhead in including the microformat on project list
>>>> and forks list pages, but getting the project descriptions for those pages
>>>> already incurs a similar overhead, and the ability to get every repo url
>>>> in one place seems worthwhile.
>>>>
>>> I agree with this, although people with very large project lists may
>>> differ ... do we have timings on these?
>>>
>>
>> AFAICS, when displaying the project list, gitweb reads each project's
>> description file, falling back to reading its config file if there is no
>> description file.
>>
>> If performance was a problem here, the thing to do would be to add
>> project descriptions to the $project_list file, and use those in
>> preference to the description files. If a large site has done that,
>> they've not sent in the patch. :-)
>
> No because all the large sites have pain points and issues elsewhere
> in the app. Most of the large sites (which I can at least speak for
> Kernel.org) went and have built in full caching layers into gitweb
> itself to deal with the problem. This means that we don't have to
> worry about nickle and dime performance improvements that are specific
> to one section, but can do a very broad sweep and get dramatically
> better performance across all of gitweb. Those patches have all made
> it back out onto the mailing list, but for a number of different
> reasons none have been accepted into the mainline branch.
Additional issue is that when you add or delete repository (project),
you have to correct or regenerate projects_index file. While it is I
think quite easy for git hosting sites such as repo.or.cz, it is
harder for sites which offer gitweb just like they ofer WWW homepages:
as a service, with repositories created (and descriptions updated)
outside of gitweb control.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH v2] make diff --color-words customizable
From: Jakub Narebski @ 2009-01-10 1:50 UTC (permalink / raw)
To: git
In-Reply-To: <1231549039-5236-1-git-send-email-trast@student.ethz.ch>
Thomas Rast wrote:
> --color-words works (and always worked) by splitting words onto one
> line each, and using the normal line-diff machinery to get a word
> diff.
Cannot we generalize diff machinery / use underlying LCS diff engine
instead of going through line diff?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH v4] submodule: add --no-fetch parameter to update command
From: Fabian Franz @ 2009-01-10 2:10 UTC (permalink / raw)
To: git; +Cc: j.sixt, hjemli, gitster, Fabian Franz
In-Reply-To: <1231553410-7541-1-git-send-email-git@fabian-franz.de>
git submodule update --no-fetch makes it possible to use git submodule
update in complete offline mode by not fetching new revisions.
Signed-off-by: Fabian Franz <git@fabian-franz.de>
---
Documentation/git-submodule.txt | 7 ++++++-
git-submodule.sh | 16 ++++++++++++----
2 files changed, 18 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 232697d..14c1d5c 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git submodule' [--quiet] add [-b branch] [-t|--track <branch>] [--] <repository> <path>
'git submodule' [--quiet] status [--cached] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
-'git submodule' [--quiet] update [--init] [--] [<path>...]
+'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--] [<path>...]
'git submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]
'git submodule' [--quiet] foreach <command>
'git submodule' [--quiet] sync [--] [<path>...]
@@ -180,6 +180,11 @@ OPTIONS
(the default). This limit only applies to modified submodules. The
size is always limited to 1 for added/deleted/typechanged submodules.
+-N::
+--no-fetch::
+ This option is only valid for the update command.
+ Don't fetch new objects from the remote site.
+
<path>...::
Paths to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
diff --git a/git-submodule.sh b/git-submodule.sh
index 6af3d96..f66622b 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
USAGE="[--quiet] [--cached] \
-[add <repo> [-b branch] [--track|-t <branch>] <path>]|[status|init|update [-i|--init]|summary [-n|--summary-limit <n>] [<commit>]] \
+[add <repo> [-b branch] [--track|-t <branch>] <path>]|[status|init|update [-i|--init] [-N|--no-fetch]|summary [-n|--summary-limit <n>] [<commit>]] \
[--] [<path>...]|[foreach <command>]|[sync [--] [<path>...]]"
OPTIONS_SPEC=
. git-sh-setup
@@ -17,6 +17,7 @@ branch=
quiet=
cached=
track=
+nofetch=
#
# print stuff on stdout unless -q was specified
@@ -313,6 +314,10 @@ cmd_update()
shift
cmd_init "$@" || return
;;
+ -N|--no-fetch)
+ shift
+ nofetch=1
+ ;;
--)
shift
break
@@ -370,9 +375,12 @@ cmd_update()
# First fetch ...
- (unset GIT_DIR; cd "$path" &&
- git-fetch) ||
- die "Unable to fetch in submodule path '$path'"
+ if test -z "$nofetch"
+ then
+ (unset GIT_DIR; cd "$path" &&
+ git-fetch) ||
+ die "Unable to fetch in submodule path '$path'"
+ fi
if test "$sha1" = "NULL"
then
--
1.5.3.6
^ permalink raw reply related
* [PATCH v4] submodule: allow tracking of the newest revision of a branch in a submodule
From: Fabian Franz @ 2009-01-10 2:10 UTC (permalink / raw)
To: git; +Cc: j.sixt, hjemli, gitster, Fabian Franz
Submodules currently only allow tracking a specific revision
and each update in a submodule leads to a new commit in the
master repository. However some users may want to always track
the newest revision of a specific (named) tag or branch or HEAD.
For example the user might want to track a staging branch in all
submodules.
To allow this the "--track|-t <branch>" parameter was added to
git-submodule.sh, which is added to .gitmodules config file as
well as "track" parameter.
Signed-off-by: Fabian Franz <git@fabian-franz.de>
---
This patch now uses the --assume-unchanged approach to be able to track any
revision in the submodule.
It adresses the issues that were in the comments for the previous patches.
And it does even more, it consists of 5 patches:
(1) allow tracking of the newest revision of a branch in a submodule
----------------------------------------------------------------
Is just handling tracked submodules the same way as if the sha1 sum
was directly in the index (i.e. detached head, checkout by sha1 id)
only that the information comes from the track parameter.
Here one can either track local branches like master or remote branches
via track = origin/master or anything else that is a pathspec.
(like: refs/remotes/origin/master)
(2) add --no-fetch parameter to update command
----------------------------------------------
Junio commented that it was bad that the submodule update needed a
online connection to update. This was true even before the "tracking"
patch and for normal operation can update --no-fetch be useful as well.
This was implemented by first fetching and then checking out instead
of doing it in one step.
(3) add --use-gitmodules parameter to update command
----------------------------------------------------
Lars correctly commented that the track parameter should be read from
.git/config and also added when init is used.
However there _are_ uses for directly reading .gitmodules and such
not using .git/config for the track parameter.
Example: I want to quickly change my tree to staging mode to test something:
$ git checkout staging
$ git submodule update -u
Now it can be that: submodule one is at master, submodule 2 at staging and
submodule3 at tagXYZ and all this was recorded in .gitmodules, which is more powerful than git submodule foreach "git checkout staging".
(4) add +<branch> syntax for track to allow automatic pulling.
--------------------------------------------------------------
As I inititially already tried, I want some branches that are automatically
pulling when I update the submodules, so I can use the submodule mechanism
to update my tree with updates, but still keep my head attached to my branch.
Syntax for the track parameter is here: +<branchname>
And it does checkout or create branch based on the origin and then do a
git-pull.
Of course conflicts arising need to be fixed manually like normal, but that
is okay, as the person adding that to .git/config or .gitmodules knows what
he/she is doing.
(5) add --recursive parameter to update command
-----------------------------------------------
I just need it. We have a fairly complex setup in the company I work for
and now that we are migrating to git, we find that we have a complex software
inside already one git repository.
And this software is going to use git submodules as well for tracking vendor
dependencies, but this can't (policy) be added to master repository as its
an component by itself.
Anyway recursive operation is lots of fun :).
Example:
$ git submodule update -r audio/
Entering submodule path 'audio/software/'
Submodule path 'dependencies/vendor1': checked out
'8b3b8ebca95d5a7e09760916ae38e4fe494ad2a2'
Leaving submodule path 'audio/software/'
And we have more software (X11) that can have submodules
inside of submodules.
So, that is all and it works perfect for me and is suited to our
needs.
Let me know, what you think.
Best Wishes,
Fabian
Documentation/git-submodule.txt | 10 +++++-
git-submodule.sh | 64 +++++++++++++++++++++++++++++++++++---
2 files changed, 68 insertions(+), 6 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 2f207fb..232697d 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -9,7 +9,7 @@ git-submodule - Initialize, update or inspect submodules
SYNOPSIS
--------
[verse]
-'git submodule' [--quiet] add [-b branch] [--] <repository> <path>
+'git submodule' [--quiet] add [-b branch] [-t|--track <branch>] [--] <repository> <path>
'git submodule' [--quiet] status [--cached] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] update [--init] [--] [<path>...]
@@ -118,6 +118,10 @@ update::
If the submodule is not yet initialized, and you just want to use the
setting as stored in .gitmodules, you can automatically initialize the
submodule with the --init option.
++
+If you used --track or set the "track" option this will automatically checkout
+the newest available revision instead of the commit specified in the index of
+the containing repository.
summary::
Show commit summary between the given commit (defaults to HEAD) and
@@ -159,6 +163,10 @@ OPTIONS
--branch::
Branch of repository to add as submodule.
+-t::
+--track::
+ Branch/Tag/HEAD (pathspec) of repository to track in a submodule.
+
--cached::
This option is only valid for status and summary commands. These
commands typically use the commit found in the submodule HEAD, but
diff --git a/git-submodule.sh b/git-submodule.sh
index 2f47e06..6af3d96 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
USAGE="[--quiet] [--cached] \
-[add <repo> [-b branch] <path>]|[status|init|update [-i|--init]|summary [-n|--summary-limit <n>] [<commit>]] \
+[add <repo> [-b branch] [--track|-t <branch>] <path>]|[status|init|update [-i|--init]|summary [-n|--summary-limit <n>] [<commit>]] \
[--] [<path>...]|[foreach <command>]|[sync [--] [<path>...]]"
OPTIONS_SPEC=
. git-sh-setup
@@ -16,6 +16,7 @@ command=
branch=
quiet=
cached=
+track=
#
# print stuff on stdout unless -q was specified
@@ -130,6 +131,11 @@ cmd_add()
-q|--quiet)
quiet=1
;;
+ -t|--track)
+ case "$2" in '') usage ;; esac
+ track=$2
+ shift
+ ;;
--)
shift
break
@@ -201,8 +207,11 @@ cmd_add()
git add "$path" ||
die "Failed to add submodule '$path'"
+ test -n "$track" && git-update-index --assume-unchanged "$path"
+
git config -f .gitmodules submodule."$path".path "$path" &&
git config -f .gitmodules submodule."$path".url "$repo" &&
+ git config -f .gitmodules submodule."$path".track "$track" &&
git add .gitmodules ||
die "Failed to register submodule '$path'"
}
@@ -277,6 +286,10 @@ cmd_init()
git config submodule."$name".url "$url" ||
die "Failed to register url for submodule path '$path'"
+ track=$(git config -f .gitmodules submodule."$name".track)
+ git config submodule."$name".track "$track" ||
+ die "Failed to register track for submodule path '$path'"
+
say "Submodule '$name' ($url) registered for path '$path'"
done
}
@@ -328,6 +341,15 @@ cmd_update()
continue
fi
+ track=$(git config submodule."$name".track)
+ if test -n "$track"
+ then
+ git-update-index --assume-unchanged "$path"
+ sha1="NULL"
+ else
+ git-update-index --no-assume-unchanged "$path"
+ fi
+
if ! test -d "$path"/.git -o -f "$path"/.git
then
module_clone "$path" "$url" || exit
@@ -345,11 +367,42 @@ cmd_update()
then
force="-f"
fi
- (unset GIT_DIR; cd "$path" && git-fetch &&
- git-checkout $force -q "$sha1") ||
+
+ # First fetch ...
+
+ (unset GIT_DIR; cd "$path" &&
+ git-fetch) ||
+ die "Unable to fetch in submodule path '$path'"
+
+ if test "$sha1" = "NULL"
+ then
+ : ${track:="HEAD"}
+
+ sha1=$(unset GIT_DIR; cd "$path" &&
+ git-rev-parse --verify --quiet "$track")
+
+ # Only use $origin/$track path if the user
+ # supplied path does not work
+ if test -z "$sha1"
+ then
+ origin=$(unset GIT_DIR; cd "$path" &&
+ get_default_remote) ||
+ die "Unable to get default remote destination in submodule path '$path'."
+ track="$origin/$track"
+
+ sha1=$(unset GIT_DIR; cd "$path" &&
+ git-rev-parse --verify "$track") ||
+ die "Unable to find newest revision of '$track' in submodule path '$path'."
+ fi
+ fi
+
+ # ... then checkout
+
+ (unset GIT_DIR; cd "$path" &&
+ git-checkout $force -q "$sha1") ||
die "Unable to checkout '$sha1' in submodule path '$path'"
- say "Submodule path '$path': checked out '$sha1'"
+ say "Submodule path '$path': checked out '$sha1'${track:+ ($track)}"
fi
done
}
@@ -596,7 +649,8 @@ cmd_status()
set_name_rev "$path" "$sha1"
if git diff-files --quiet -- "$path"
then
- say " $sha1 $path$revname"
+ track=$(git config submodule."$name".track)
+ say " $sha1 $path$revname${track:+ (tracking "$track")}"
else
if test -z "$cached"
then
--
1.5.3.6
^ permalink raw reply related
* [PATCH v4] submodule: add --use-gitmodules parameter to update command
From: Fabian Franz @ 2009-01-10 2:10 UTC (permalink / raw)
To: git; +Cc: j.sixt, hjemli, gitster, Fabian Franz
In-Reply-To: <1231553410-7541-2-git-send-email-git@fabian-franz.de>
When -u|--use-gitmodules is given the update command uses the .gitmodules
config file instead of the .git/config file to obtain the track parameter.
This makes it for example possible to change branches for all submodules
at the same time without having to sync up .git/config first.
Signed-off-by: Fabian Franz <git@fabian-franz.de>
---
Documentation/git-submodule.txt | 8 +++++++-
git-submodule.sh | 9 ++++++++-
2 files changed, 15 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 14c1d5c..175b4b5 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -12,7 +12,7 @@ SYNOPSIS
'git submodule' [--quiet] add [-b branch] [-t|--track <branch>] [--] <repository> <path>
'git submodule' [--quiet] status [--cached] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
-'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--] [<path>...]
+'git submodule' [--quiet] update [--init] [-N|--no-fetch] [-u|--use-gitmodules] [--] [<path>...]
'git submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]
'git submodule' [--quiet] foreach <command>
'git submodule' [--quiet] sync [--] [<path>...]
@@ -185,6 +185,12 @@ OPTIONS
This option is only valid for the update command.
Don't fetch new objects from the remote site.
+-u::
+--use-gitmodules::
+ This option is only valid for the update command.
+ Use the tracking information found in .gitmodules
+ (track) and ignore .git/config.
+
<path>...::
Paths to submodule(s). When specified this will restrict the command
to only operate on the submodules found at the specified paths.
diff --git a/git-submodule.sh b/git-submodule.sh
index f66622b..81b96dd 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
USAGE="[--quiet] [--cached] \
-[add <repo> [-b branch] [--track|-t <branch>] <path>]|[status|init|update [-i|--init] [-N|--no-fetch]|summary [-n|--summary-limit <n>] [<commit>]] \
+[add <repo> [-b branch] [--track|-t <branch>] <path>]|[status|init|update [-i|--init] [-N|--no-fetch] [-u|--use-gitmodules]|summary [-n|--summary-limit <n>] [<commit>]] \
[--] [<path>...]|[foreach <command>]|[sync [--] [<path>...]]"
OPTIONS_SPEC=
. git-sh-setup
@@ -18,6 +18,7 @@ quiet=
cached=
track=
nofetch=
+usegitmodules=
#
# print stuff on stdout unless -q was specified
@@ -318,6 +319,10 @@ cmd_update()
shift
nofetch=1
;;
+ -u|--use-gitmodules)
+ shift
+ usegitmodules=1
+ ;;
--)
shift
break
@@ -347,6 +352,8 @@ cmd_update()
fi
track=$(git config submodule."$name".track)
+ test -n "$usegitmodules" &&
+ track=$(git config -f .gitmodules submodule."$name".track)
if test -n "$track"
then
git-update-index --assume-unchanged "$path"
--
1.5.3.6
^ permalink raw reply related
* [PATCH v4] submodule: add +<branch> syntax for track to allow automatic pulling.
From: Fabian Franz @ 2009-01-10 2:10 UTC (permalink / raw)
To: git; +Cc: j.sixt, hjemli, gitster, Fabian Franz
In-Reply-To: <1231553410-7541-3-git-send-email-git@fabian-franz.de>
When the track parameter is set to +<branch>, on update command a
new branch is created tracking the remote branch (if it does not
yet exist). Then the branch is checked out and git-pull is run.
Signed-off-by: Fabian Franz <git@fabian-franz.de>
---
Documentation/git-submodule.txt | 3 +++
git-submodule.sh | 26 ++++++++++++++++++++++++++
2 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 175b4b5..fbb18ee 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -166,6 +166,9 @@ OPTIONS
-t::
--track::
Branch/Tag/HEAD (pathspec) of repository to track in a submodule.
+ If you give +<branch> as parameter, a new branch will be created and
+ setup to track the remote branch. Then on update git-pull is used to
+ update the branch.
--cached::
This option is only valid for status and summary commands. These
diff --git a/git-submodule.sh b/git-submodule.sh
index 81b96dd..54b59b2 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -372,6 +372,32 @@ cmd_update()
die "Unable to find current revision in submodule path '$path'"
fi
+ pull=
+ case "$track" in
+ "+"*)
+ pull=1
+ track=${track#+}
+ ;;
+ esac
+
+ if test -n "$pull"
+ then
+ say "Pulling updates for branch '$track' for submodule path '$path'"
+ origin=$(unset GIT_DIR; cd "$path" &&
+ get_default_remote) ||
+ die "Unable to get default remote destination in submodule path '$path'."
+ (unset GIT_DIR; cd "$path" &&
+ git-rev-parse --verify --quiet "refs/heads/$track" >/dev/null ||
+ git-branch --track "$track" "$origin/$track") ||
+ die "Unable to create branch '$track' in submodule path '$path'"
+
+ (unset GIT_DIR; cd "$path" &&
+ git-checkout -q "$track" &&
+ git-pull ${quiet:+-q}) ||
+ die "Unable to pull for branch '$track' in submodule path '$path'"
+ sha1="$track"
+ fi
+
if test "$subsha1" != "$sha1"
then
force=
--
1.5.3.6
^ permalink raw reply related
* [PATCH v4] submodule: add --recursive parameter to update command
From: Fabian Franz @ 2009-01-10 2:10 UTC (permalink / raw)
To: git; +Cc: j.sixt, hjemli, gitster, Fabian Franz
In-Reply-To: <1231553410-7541-4-git-send-email-git@fabian-franz.de>
If --recursive is specified on update, then recursively check for
.gitmodules in each updated submodule and run init and update commands.
The update command is run with the same parameters as the original update
command with the exception of the path.
Signed-off-by: Fabian Franz <git@fabian-franz.de>
---
Documentation/git-submodule.txt | 8 ++++++++
git-submodule.sh | 17 ++++++++++++++++-
2 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index fbb18ee..c9adc43 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -188,6 +188,14 @@ OPTIONS
This option is only valid for the update command.
Don't fetch new objects from the remote site.
+-r::
+--recursive::
+ This option is only valid for the update command.
+ Recursively check for .gitmodules in each updated submodule and run
+ init and update commands. The update command is run with the same
+ parameters as the original update command with the exception of the
+ path.
+
-u::
--use-gitmodules::
This option is only valid for the update command.
diff --git a/git-submodule.sh b/git-submodule.sh
index 54b59b2..8bb00b7 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
USAGE="[--quiet] [--cached] \
-[add <repo> [-b branch] [--track|-t <branch>] <path>]|[status|init|update [-i|--init] [-N|--no-fetch] [-u|--use-gitmodules]|summary [-n|--summary-limit <n>] [<commit>]] \
+[add <repo> [-b branch] [--track|-t <branch>] <path>]|[status|init|update [-i|--init] [-N|--no-fetch] [-r|--recursive] [-u|--use-gitmodules]|summary [-n|--summary-limit <n>] [<commit>]] \
[--] [<path>...]|[foreach <command>]|[sync [--] [<path>...]]"
OPTIONS_SPEC=
. git-sh-setup
@@ -19,6 +19,7 @@ cached=
track=
nofetch=
usegitmodules=
+recursive=
#
# print stuff on stdout unless -q was specified
@@ -319,6 +320,10 @@ cmd_update()
shift
nofetch=1
;;
+ -r|--recursive)
+ shift
+ recursive=1
+ ;;
-u|--use-gitmodules)
shift
usegitmodules=1
@@ -445,6 +450,16 @@ cmd_update()
say "Submodule path '$path': checked out '$sha1'${track:+ ($track)}"
fi
+ if test -n "$recursive" -a -f "$path/.gitmodules"
+ then
+ PARAMS="${quiet:+-q} ${nofetch:+--no-fetch} ${recursive:+-r} ${usegitmodules:+-u}"
+ say "Entering submodule path '$path'"
+ (unset GIT_DIR; cd "$path" &&
+ git-submodule init &&
+ git-submodule update $PARAMS) ||
+ die "Unable to run 'git-submodule update $PARAMS' in submodule path '$path'"
+ say "Leaving submodule path '$path'"
+ fi
done
}
--
1.5.3.6
^ permalink raw reply related
* Re: fetch branch blacklist
From: jidanni @ 2009-01-10 2:30 UTC (permalink / raw)
To: jnareb; +Cc: git
In-Reply-To: <m3wsd41b7q.fsf@localhost.localdomain>
If anybody is going to implement this, then the order of the two lines
fetch=+refs/heads/*:refs/remotes/origin/*
fetch=!refs/heads/man
should probably matter...
^ permalink raw reply
* Re: [PATCH 2/2] Use is_pseudo_dir_name everywhere
From: Junio C Hamano @ 2009-01-10 2:48 UTC (permalink / raw)
To: Alexander Potashev; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <20090109102407.GA4089@myhost>
Alexander Potashev <aspotashev@gmail.com> writes:
> I didn't think over the support of 'lost+found'.
Yeah, I do not think it is particularly a good idea, but that is what (I
thought) you implied in your original message.
In any case, you can always do
$ git clone -n $there it.git
$ mv it.git/.git . && rmdir it.git && git checkout -f
or something like that (adjust what you move out of it.git when you are
doing a bare clone), so in that sense I do not deeply care about the
motivation of your patch myself.
But I liked the helper function to abstract away the many identical checks
we do for "is it a dot or a dot dot?", and that was the primary reason why
I commented on your patches.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #01; Mon, 05)
From: Jonas Fonseca @ 2009-01-10 4:15 UTC (permalink / raw)
To: Junio C Hamano, Miklos Vajna; +Cc: git
In-Reply-To: <7vbpulnduj.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 6, 2009 at 01:33, Junio C Hamano <gitster@pobox.com> wrote:
> ----------------------------------------------------------------
> * mv/apply-parse-opt (Sun Dec 28 00:03:57 2008 +0100) 1 commit
> + parse-opt: migrate builtin-apply.
This broke apply for me after updating to the current "next" earlier
today. When requesting that the patch be read from stdin I get the
following error message:
> git diff | git apply -R -
fatal: can't open patch '-': No such file or directory
--
Jonas Fonseca
^ permalink raw reply
* Git - Pushing to a production website
From: 4jxDQ6FQee2H @ 2009-01-10 4:23 UTC (permalink / raw)
To: git
Hi,
Our company's website is stored in a GIT Repository.
The repository is coded for our test server. When we push updates to
the production server, have manually run a script to patch several
files to make the code work on the production server (i.e. port
numbers, etc).
I'd like to write a script to email me whenever someone changes files
on the production server without checking those changes back into git
(i.e. running 'git status | grep "nothing to commit" ...').
However, this approach get confused by the files patched to work
correctly.
Is there any way to 'save' those patched files so they don't get
reported by 'git status', yet not mung up the git history every time
we push out an update?
Thanks!
^ permalink raw reply
* Re: Git - Pushing to a production website
From: Boyd Stephen Smith Jr. @ 2009-01-10 4:38 UTC (permalink / raw)
To: 4jxDQ6FQee2H; +Cc: git
In-Reply-To: <20090109222344.3539138a@family.dyweni.com>
[-- Attachment #1: Type: text/plain, Size: 1251 bytes --]
On Friday 2009 January 09 22:23:44 4jxDQ6FQee2H@dyweni.com wrote:
>Our company's website is stored in a GIT Repository.
Interesting. I like the thought.
>The repository is coded for our test server. When we push updates to
>the production server, have manually run a script to patch several
>files to make the code work on the production server (i.e. port
>numbers, etc).
>
>I'd like to write a script to email me whenever someone changes files
>on the production server without checking those changes back into git
>(i.e. running 'git status | grep "nothing to commit" ...').
>
>However, this approach get confused by the files patched to work
>correctly.
>
>Is there any way to 'save' those patched files so they don't get
>reported by 'git status', yet not mung up the git history every time
>we push out an update?
You could simply commit after running the perl script. You could even commit
to a branch so that it's (a little) less likely those changes get integrated
into master.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git - Pushing to a production website
From: 4jxDQ6FQee2H @ 2009-01-10 4:46 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901092238.06968.bss@iguanasuicide.net>
> You could simply commit after running the perl script. You could
> even commit to a branch so that it's (a little) less likely those
> changes get integrated into master.
How about this, ran by the post-update hook:
For the first update:
- Do a git pull
- Then create a new branch 'working' and checkout
- Apply the patches to 'working' and commit
This leaves 'working' == 'master^'
For subsequent updates:
- Compare the SHA1 hashes for 'working' and 'master^'.
- If they don't match, throw an error and exit
- Assuming they match, checkout 'master' and delete 'working'
- Do a git pull
- Then create a new branch 'working' and checkout
- Apply the patches to 'working' and commit
This would keep the working directory clean and allow future updates to
occur, if no one commits anything to git 'working'. If they did, the
script would exit and prevent the update requiring the developer to
review the commit logs and cherry-pick where necessary.
^ permalink raw reply
* Re: Git - Pushing to a production website
From: david @ 2009-01-10 5:58 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: 4jxDQ6FQee2H, git
In-Reply-To: <200901092238.06968.bss@iguanasuicide.net>
On Fri, 9 Jan 2009, Boyd Stephen Smith Jr. wrote:
> On Friday 2009 January 09 22:23:44 4jxDQ6FQee2H@dyweni.com wrote:
>> Our company's website is stored in a GIT Repository.
>
> Interesting. I like the thought.
>
>> The repository is coded for our test server. When we push updates to
>> the production server, have manually run a script to patch several
>> files to make the code work on the production server (i.e. port
>> numbers, etc).
>>
>> I'd like to write a script to email me whenever someone changes files
>> on the production server without checking those changes back into git
>> (i.e. running 'git status | grep "nothing to commit" ...').
>>
>> However, this approach get confused by the files patched to work
>> correctly.
>>
>> Is there any way to 'save' those patched files so they don't get
>> reported by 'git status', yet not mung up the git history every time
>> we push out an update?
>
> You could simply commit after running the perl script. You could even commit
> to a branch so that it's (a little) less likely those changes get integrated
> into master.
one nice thing about git commit is that if there are no changes it doesn't
make a commit.
I have a couple files on my desktop (firefox status files for example)
that I have a cron job do a commit on every min so that when firefox
crashes in a way that can't be recovered by it's 'restore old pages'
option I can go back and save things anyway.
David Lang
^ permalink raw reply
* Re: Git - Pushing to a production website
From: Boyd Stephen Smith Jr. @ 2009-01-10 5:04 UTC (permalink / raw)
To: 4jxDQ6FQee2H; +Cc: git
In-Reply-To: <20090109224618.5d8c461c@family.dyweni.com>
[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]
On Friday 2009 January 09 22:46:18 4jxDQ6FQee2H@dyweni.com wrote:
>> You could simply commit after running the perl script. You could
>> even commit to a branch so that it's (a little) less likely those
>> changes get integrated into master.
>
>How about this, ran by the post-update hook:
>
>For the first update:
>
> - Do a git pull
I'm not enitirely sure you want post-update doing the pull.
> - Then create a new branch 'working' and checkout
> - Apply the patches to 'working' and commit
>
>This leaves 'working' == 'master^'
Actually, it leaves HEAD == working and master == working^.
>For subsequent updates:
> - Compare the SHA1 hashes for 'working' and 'master^'.
> - If they don't match, throw an error and exit
> - Assuming they match, checkout 'master' and delete 'working'
> - Do a git pull
(See above)
> - Then create a new branch 'working' and checkout
> - Apply the patches to 'working' and commit
>
>
>This would keep the working directory clean and allow future updates to
>occur, if no one commits anything to git 'working'. If they did, the
>script would exit and prevent the update requiring the developer to
>review the commit logs and cherry-pick where necessary.
It wouldn't *completely* prevent changes to working as one could "git
commit --amend" and still have working^ == master. That said, if developers
get creative enough they can probably bypass most measures, at least those
based on a hook.
A privileged process for updates could stash the expected SHA for master and
working somewhere developers can't write. That should prevent even dedicated
developers from making unauthorized changes, modulo security/cryptographic
exploits.
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git - Pushing to a production website
From: 4jxDQ6FQee2H @ 2009-01-10 5:30 UTC (permalink / raw)
To: Boyd Stephen Smith Jr.; +Cc: git
In-Reply-To: <200901092304.51986.bss@iguanasuicide.net>
> > - Do a git pull
>
> I'm not enitirely sure you want post-update doing the pull.
Really?
Let's say the website lives in /srv/www/htdocs
Let's also say the git repository lives in /srv/www/git
All developers pull/push from /srv/www/git (git@server:/srv/www/git)
The website is a clone of /srv/www/git and only tracks 'master'.
Post-update (simplified) changes to /srv/www/htdocs and does 'git pull'.
I'm referencing this article:
http://jblevins.org/log/tools/managing-websites-with-git
Would you recommend a different way to automatically push any changes
to 'master' down to the website?
>
> > - Then create a new branch 'working' and checkout
> > - Apply the patches to 'working' and commit
> >
> >This leaves 'working' == 'master^'
>
> Actually, it leaves HEAD == working and master == working^.
I'm sorry - I mixed up my terminology.
I am referring to the branch's log.
'working' has 1 more log entry than 'master'.
Example:
- git log master | grep ^commit | tail -n 2 | head -n 1
- git log working | grep ^commit | tail -n 1 | head -n 1
Both of these commands should return the same commit hash.
^ permalink raw reply
* Re: Git - Pushing to a production website
From: Boyd Stephen Smith Jr. @ 2009-01-10 5:54 UTC (permalink / raw)
To: 4jxDQ6FQee2H; +Cc: git
In-Reply-To: <20090109233037.31198694@family.dyweni.com>
[-- Attachment #1: Type: text/plain, Size: 1656 bytes --]
On Friday 09 January 2009, 4jxDQ6FQee2H@dyweni.com wrote about 'Re: Git -
Pushing to a production website':
>> > - Do a git pull
>>
>> I'm not enitirely sure you want post-update doing the pull.
>
>Let's say the website lives in /srv/www/htdocs
>Let's also say the git repository lives in /srv/www/git
>
>All developers pull/push from /srv/www/git (git@server:/srv/www/git)
>
>The website is a clone of /srv/www/git and only tracks 'master'.
>Post-update (simplified) changes to /srv/www/htdocs and does 'git pull'.
Ah. I was assuming you were "git pull"ing in the repository that the hook
was running from. In this case you are "git pull"ing in a different
repository, which should be fine.
>> >This leaves 'working' == 'master^'
>>
>> Actually, it leaves HEAD == working and master == working^.
>
>I'm sorry - I mixed up my terminology.
>
>I am referring to the branch's log.
>
>'working' has 1 more log entry than 'master'.
Yes, which means working^ == master.
commit-ish^ means the first parent of commit-ish
commit-ish^2 means the second parent of commit-ish
commit-ish~2 means the "first grandparent" of commit-ish
>Example:
> - git log master | grep ^commit | tail -n 2 | head -n 1
> - git log working | grep ^commit | tail -n 1 | head -n 1
>
>Both of these commands should return the same commit hash.
As would:
- git rev-parse master
- git rev-parse working^
--
Boyd Stephen Smith Jr. ,= ,-_-. =.
bss@iguanasuicide.net ((_/)o o(\_))
ICQ: 514984 YM/AIM: DaTwinkDaddy `-'(. .)`-'
http://iguanasuicide.net/ \_/
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2009, #01; Mon, 05)
From: Junio C Hamano @ 2009-01-10 6:15 UTC (permalink / raw)
To: Jonas Fonseca; +Cc: Miklos Vajna, git
In-Reply-To: <2c6b72b30901092015l2405627aqf928e43c12eabc3c@mail.gmail.com>
"Jonas Fonseca" <jonas.fonseca@gmail.com> writes:
> On Tue, Jan 6, 2009 at 01:33, Junio C Hamano <gitster@pobox.com> wrote:
>> ----------------------------------------------------------------
>> * mv/apply-parse-opt (Sun Dec 28 00:03:57 2008 +0100) 1 commit
>> + parse-opt: migrate builtin-apply.
>
> This broke apply for me after updating to the current "next" earlier
> today. When requesting that the patch be read from stdin I get the
> following error message:
>
> > git diff | git apply -R -
> fatal: can't open patch '-': No such file or directory
Thanks. I think this patch would fix it.
Because the original option parser was incremental and immediate with
respect to "-", we used to be able to say:
$ git apply -p - --stat patch2.txt <patch1.txt
and the use of parseopt breaks such usage, even after this fix.
But I think it is a bit too crazy to support such backward compatibility.
builtin-apply.c | 19 +++++--------------
t/t4106-apply-stdin.sh | 26 ++++++++++++++++++++++++++
2 files changed, 31 insertions(+), 14 deletions(-)
diff --git c/builtin-apply.c w/builtin-apply.c
index cb988a3..2811c0f 100644
--- c/builtin-apply.c
+++ w/builtin-apply.c
@@ -3140,16 +3140,6 @@ static int git_apply_config(const char *var, const char *value, void *cb)
return git_default_config(var, value, cb);
}
-static int option_parse_stdin(const struct option *opt,
- const char *arg, int unset)
-{
- int *errs = opt->value;
-
- *errs |= apply_patch(0, "<stdin>", options);
- read_stdin = 0;
- return 0;
-}
-
static int option_parse_exclude(const struct option *opt,
const char *arg, int unset)
{
@@ -3218,9 +3208,6 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
const char *whitespace_option = NULL;
struct option builtin_apply_options[] = {
- { OPTION_CALLBACK, '-', NULL, &errs, NULL,
- "read the patch from the standard input",
- PARSE_OPT_NOARG, option_parse_stdin },
{ OPTION_CALLBACK, 0, "exclude", NULL, "path",
"don´t apply changes matching the given path",
0, option_parse_exclude },
@@ -3302,7 +3289,11 @@ int cmd_apply(int argc, const char **argv, const char *unused_prefix)
const char *arg = argv[i];
int fd;
- if (0 < prefix_length)
+ if (!strcmp(arg, "-")) {
+ errs |= apply_patch(0, "<stdin>", options);
+ read_stdin = 0;
+ continue;
+ } else if (0 < prefix_length)
arg = prefix_filename(prefix, prefix_length, arg);
fd = open(arg, O_RDONLY);
diff --git c/t/t4106-apply-stdin.sh w/t/t4106-apply-stdin.sh
new file mode 100755
index 0000000..72467a1
--- /dev/null
+++ w/t/t4106-apply-stdin.sh
@@ -0,0 +1,26 @@
+#!/bin/sh
+
+test_description='git apply --numstat - <patch'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ echo hello >text &&
+ git add text &&
+ echo goodbye >text &&
+ git diff >patch
+'
+
+test_expect_success 'git apply --numstat - < patch' '
+ echo "1 1 text" >expect &&
+ git apply --numstat - <patch >actual &&
+ test_cmp expect actual
+'
+
+test_expect_success 'git apply --numstat - < patch patch' '
+ for i in 1 2; do echo "1 1 text"; done >expect &&
+ git apply --numstat - < patch patch >actual &&
+ test_cmp expect actual
+'
+
+test_done
^ permalink raw reply related
* Re: Git - Pushing to a production website
From: Jacob Helwig @ 2009-01-10 6:41 UTC (permalink / raw)
To: Git; +Cc: 4jxDQ6FQee2H
In-Reply-To: <20090109222344.3539138a@family.dyweni.com>
On Fri, Jan 9, 2009 at 20:23, <4jxDQ6FQee2H@dyweni.com> wrote:
> Hi,
>
> Our company's website is stored in a GIT Repository.
>
> The repository is coded for our test server. When we push updates to
> the production server, have manually run a script to patch several
> files to make the code work on the production server (i.e. port
> numbers, etc).
>
Are these all static pages? If they're Perl/PHP/Ruby/whatever, why
not add tests for the Live vs. Dev? Check for an environment
variable, or a file on disk, etc, etc? That way any checks described
below won't get "confused" by the (no longer necessary) patches, and
you won't have to worry about rebasing commits, and any potential
conflicts there.
> I'd like to write a script to email me whenever someone changes files
> on the production server without checking those changes back into git
> (i.e. running 'git status | grep "nothing to commit" ...').
>
> However, this approach get confused by the files patched to work
> correctly.
>
> Is there any way to 'save' those patched files so they don't get
> reported by 'git status', yet not mung up the git history every time
> we push out an update?
>
> Thanks!
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH/RFC v5 1/1] more cache effective symlink/directory detection
From: René Scharfe @ 2009-01-10 10:11 UTC (permalink / raw)
To: Kjetil Barvik; +Cc: git, Pete Harlan, Linus Torvalds, Junio C Hamano
In-Reply-To: <1231527954-868-2-git-send-email-barvik@broadpark.no>
Kjetil Barvik schrieb:
> - Also introduce a 'void clear_lstat_cache(void)' function, which
> should be used to clean the cache before usage. If for instance,
> you have changed the types of directories which should be cached,
> the cache could contain a path which was not wanted.
Is it possible to make the cache detect these situations automatically
by saving track_flags along with the cache contents? Not having to
clear the cache manually would be a major feature.
> --- a/cache.h
> +++ b/cache.h
> @@ -719,7 +719,29 @@ struct checkout {
> };
>
> extern int checkout_entry(struct cache_entry *ce, const struct checkout *state, char *topath);
> -extern int has_symlink_leading_path(int len, const char *name);
> +
> +#define LSTAT_REG (1u << 0)
> +#define LSTAT_DIR (1u << 1)
> +#define LSTAT_NOENT (1u << 2)
> +#define LSTAT_SYMLINK (1u << 3)
> +#define LSTAT_LSTATERR (1u << 4)
> +#define LSTAT_ERR (1u << 5)
> +#define LSTAT_FULLPATH (1u << 6)
> +extern unsigned int lstat_cache(int len, const char *name,
> + unsigned int track_flags, int prefix_len_stat_func);
> +extern void clear_lstat_cache(void);
> +static inline unsigned int has_symlink_leading_path(int len, const char *name)
> +{
> + return lstat_cache(len, name, LSTAT_SYMLINK|LSTAT_DIR, -1) &
> + LSTAT_SYMLINK;
> +}
> +#define clear_symlink_cache() clear_lstat_cache()
> +static inline unsigned int has_symlink_or_noent_leading_path(int len, const char *name)
> +{
> + return lstat_cache(len, name, LSTAT_SYMLINK|LSTAT_NOENT|LSTAT_DIR, -1) &
> + (LSTAT_SYMLINK|LSTAT_NOENT);
> +}
> +#define clear_symlink_or_noent_cache() clear_lstat_cache()
What's the advantage of inlining the wrappers (expressed in units of
space and/or time)? The interface would be much nicer if you exported
the wrappers, only, and not all those constants along with them.
And why define aliases for clear_lstat_cache()?
> diff --git a/entry.c b/entry.c
> index aa2ee46a84033585d8e07a585610c5a697af82c2..293400cf5be63fd66b797a68e17bf953c600fe99 100644
> --- a/entry.c
> +++ b/entry.c
> @@ -8,35 +8,28 @@ static void create_directories(const char *path, const struct checkout *state)
> const char *slash = path;
>
> while ((slash = strchr(slash+1, '/')) != NULL) {
> - struct stat st;
> - int stat_status;
> -
> len = slash - path;
> memcpy(buf, path, len);
> buf[len] = 0;
>
> - if (len <= state->base_dir_len)
> - /*
> - * checkout-index --prefix=<dir>; <dir> is
> - * allowed to be a symlink to an existing
> - * directory.
> - */
> - stat_status = stat(buf, &st);
> - else
> - /*
> - * if there currently is a symlink, we would
> - * want to replace it with a real directory.
> - */
> - stat_status = lstat(buf, &st);
> -
> - if (!stat_status && S_ISDIR(st.st_mode))
> + /* For 'checkout-index --prefix=<dir>', <dir> is
> + * allowed to be a symlink to an existing directory,
> + * therefore we must give 'state->base_dir_len' to the
> + * cache, such that we test path components of the
> + * prefix with stat() instead of lstat()
> + *
> + * We must also tell the cache to test the complete
> + * length of the buffer (the '|LSTAT_FULLPATH' part).
> + */
> + if (lstat_cache(len, buf, LSTAT_DIR|LSTAT_FULLPATH,
> + state->base_dir_len) &
> + LSTAT_DIR)
> continue; /* ok, it is already a directory. */
I'd say this usage is worth another wrapper.
Also, it's probably worth to split this patch up again. First switching
to your improved implementation of has_symlink_leading_path(), then
introducing has_symlink_or_noent_leading_path() and finally adding
LSTAT_FULLPATH and the fourth parameter of lstat_cache() etc. and using
this feature in entry.c seems like a nice incremental progression.
René
^ permalink raw reply
* Re: [BUG PATCH RFC] mailinfo: correctly handle multiline 'Subject:' header
From: Kirill Smelkov @ 2009-01-10 10:12 UTC (permalink / raw)
To: Junio C Hamano, Alexander Potashev; +Cc: git
In-Reply-To: <20090108231135.GB4185@roro3>
On Fri, Jan 09, 2009 at 02:11:35AM +0300, Kirill Smelkov wrote:
> Changes since v1:
>
> o incorporated Junio's description and code about padding
> o incorporated Junio's description and code about LWS between encoded
> words
> o incorporated tests from RFC2047 examples (one testresult is unclear
> -- see patch description)
>
>
> From: Kirill Smelkov <kirr@landau.phys.spbu.ru>
> Subject: mailinfo: correctly handle multiline 'Subject:' header
[...]
Junio, All, just in case this again got spam-detected:
http://marc.info/?l=git&m=123145624611936&w=2
Thanks,
Kirill
^ permalink raw reply
* Re: [PATCH v2] t7501-commit.sh: explicitly check that -F prevents invoking the editor
From: Johannes Schindelin @ 2009-01-10 10:19 UTC (permalink / raw)
To: Adeodato Simó; +Cc: git, gitster
In-Reply-To: <1231522205-10510-1-git-send-email-dato@net.com.org.es>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 945 bytes --]
Hi,
On Fri, 9 Jan 2009, Adeodato Simó wrote:
> diff --git a/t/t7500-commit.sh b/t/t7500-commit.sh
> index 6e18a96..5998baf 100755
> --- a/t/t7500-commit.sh
> +++ b/t/t7500-commit.sh
> @@ -149,10 +149,7 @@ EOF
>
> test_expect_success '--signoff' '
> echo "yet another content *narf*" >> foo &&
> - echo "zort" | (
> - test_set_editor "$TEST_DIRECTORY"/t7500/add-content &&
> - git commit -s -F - foo
> - ) &&
> + echo "zort" | git commit -s -F - foo &&
> git cat-file commit HEAD | sed "1,/^$/d" > output &&
> test_cmp expect output
> '
AFAICT this still tests if -F - launches an editor, except that it _does_
launch the editor, waiting for the user to quit the editor. Which is bad.
In the end I think it is not worth all that effort (as the issue was fixed
long time ago, probably even before builtin-commit entered 'next'), so I'd
just leave the test as-is, documenting why the editor is set to
add-content.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Get format-patch to show first commit after root commit
From: Johannes Schindelin @ 2009-01-10 10:27 UTC (permalink / raw)
To: nathan.panike; +Cc: git
In-Reply-To: <49679f61.1b068e0a.048f.70e4@mx.google.com>
Hi,
your mailing process has a problem; neither the recipients nor the subject
made it into the mail header.
On Fri, 9 Jan 2009, nathan.panike@gmail.com wrote:
> >From 65c4fed27fe9752ffd0e3b7cb6807561a4dd4601 Mon Sep 17 00: 00:00 2001
> From: Nathan W. Panike <nathan.panike@gmail.com>
> Date: Fri, 9 Jan 2009 11:53:43 -0600
> Subject: [PATCH] Get format-patch to show first commit after root commit
>
> Currently, the command
>
> git format-patch -1 e83c5163316f89bfbde
You do not need -1, and using 19 digits seems a bit arbitrary; the
convention seems to be 7 digits (that is what --abbrev-commit does).
>
> in the git repository creates an empty file. Instead, one is
> forced to do
>
> git format-patch -1 --root e83c5163316f89bfbde
>
> This seems arbitrary. This patch fixes this case, so that
>
> git format-patch -1 e83c5163316f89bfbde
>
> will produce an actual patch.
IMHO mentioning --root is misleading, as the real bug is the empty diff.
Apart from that, I like the patch, though.
Thanks,
Dscho
^ permalink raw reply
* Re: collapsing commits with rebase
From: nadim khemir @ 2009-01-10 10:26 UTC (permalink / raw)
To: git
In-Reply-To: <93c3eada0901071608r190a723bma502b68c4ab81a08@mail.gmail.com>
On Thursday 08 January 2009 01.08.44 Geoff Russell wrote:
> Dear gits,
>
> I have a series of commits:
>
> A---B---C---D---E---F
>
> I want to collapse B---C---D into one single commit. git rebase -i B will
> allow me to do this, but I'm looking for a non-interactive incantation.
Hi Geoff, Could you please share with use the final (tested) solution? I'd be
interrested to see how you did implement plan B if you did.
Cheers, Nadim.
^ permalink raw reply
* Re: [PATCH v2] t7501-commit.sh: explicitly check that -F prevents invoking the editor
From: Adeodato Simó @ 2009-01-10 10:32 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, gitster
In-Reply-To: <alpine.DEB.1.00.0901101117100.30769@pacific.mpi-cbg.de>
* Johannes Schindelin [Sat, 10 Jan 2009 11:19:43 +0100]:
> Hi,
Hello,
> > test_expect_success '--signoff' '
> > echo "yet another content *narf*" >> foo &&
> > - echo "zort" | (
> > - test_set_editor "$TEST_DIRECTORY"/t7500/add-content &&
> > - git commit -s -F - foo
> > - ) &&
> > + echo "zort" | git commit -s -F - foo &&
> > git cat-file commit HEAD | sed "1,/^$/d" > output &&
> > test_cmp expect output
> > '
> AFAICT this still tests if -F - launches an editor, except that it _does_
> launch the editor, waiting for the user to quit the editor. Which is bad.
The default value of VISUAL for the test suite is ":" AFAICS. Hence,
even if it's called, it will return immediately.
If it would be called, without my patch the "--signoff" test would fail,
but there would be no obvious reason as to why. Seeing "editor not
invoked if -F is given FAILED" is much more clear IMHO.
Also note that there plenty of places in the test suite where -F is
used, but VISUAL is not set explicitly.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Excuse me for thinking a banana-eating contest was about eating a banana!
-- Paris Geller
^ 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