* [PATCH 0/5] support reading and writing uncompressed loose object
From: Liu Yubao @ 2008-12-02 1:48 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7voczws3np.fsf@gitster.siamese.dyndns.org>
Hi,
In original implementation, git stores loose object like this:
loose object = deflate(typename + <space> + size + data)
The patches below add support to read and write uncompressed loose
object:
loose object = typename + <space> + size + data
The cons and pros to use uncompressed loose object:
cons
* old git can't read these uncompressed loose objects
(I think it's not a big problem because old git can read
pack files generated by new git)
* uncompressed loose objects occupy more disk space
(I also think it's not a big problem because loose objects
aren't too many in general)
pros
* avoid compressing and uncompressing loose objects that are likely
frequently used when coding/merging with git add/diff/diff --cached/
merge/rebase/log.
* the code to read and write uncompressed loose objects is
simpler, although there are now more code paths for compatibility.
* better to share loose objects among multiple git processes because
sha1 files can be used directly after mmapped. The original git
uncompresses loose objects into heap memory area so that they
can't be shared by other processes.
(NOTICE: The patches below doesn't use mmapped sha1 files directly
because I find parse_object() requires a buffer terminated with
zero.)
* easy to grep objects in .git/objects (...stupid use case :-)
If these patches are worth being included into upstream branch,
I will add a new config variable core.uncompressedLooseObject.
Explanation to the patches:
1) avoid parse_sha1_header() accessing memory out of bound
Just for more safety, no inflateInit() to detect errors for
uncompressed loose objects.
2) don't die immediately when convert an invalid type name
So we can fall back to compressed loose objects.
3) optimize parse_sha1_header() a little by detecting object type
To quickly detect whether it seems an uncompressed loose object.
4) support reading uncompressed loose object
The new feature.
5) support writing uncompressed loose object
The new feature, need a git-config variable yet.
The patches are generated against git-1.6.1-rc, I have run the test cases
and it seems ok.
object.c | 14 +++++++++++++-
object.h | 1 +
sha1_file.c | 58 +++++++++++++++++++++++++++++++++++++++++++++-------------
3 files changed, 59 insertions(+), 14 deletions(-)
^ permalink raw reply
* Re: [PATCH] Modified the default git help message to be grouped by topic
From: Junio C Hamano @ 2008-12-02 1:45 UTC (permalink / raw)
To: Jeff King; +Cc: Scott Chacon, git, gitster
In-Reply-To: <20081201183258.GB24443@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Dec 01, 2008 at 09:30:37AM -0800, Scott Chacon wrote:
>
>> It's difficult to process 21 commands (which is what is output
>> by default for git when no command is given). I've re-grouped
>> them into 4 groups of 5 or 6 commands each, which I think is
>> clearer and easier for new users to process.
>
> I like it (and I think the categorizations look reasonable, which is
> something that I recall caused some discussion at the GitTogether).
>
> The only downside I see is that we're now >24 lines.
If this list is meant to show "the most commonly used" basics, then you
can trim the list somewhat. For example, "rm" and "mv" can be safely
discarded, "status" can be replaced with "diff", and "diff" can be removed
from "History Commands".
^ permalink raw reply
* Re: [PATCH] added a built-in alias for 'stage' to the 'add' command
From: Junio C Hamano @ 2008-12-02 1:38 UTC (permalink / raw)
To: Scott Chacon; +Cc: git, gitster
In-Reply-To: <20081201172902.GA41963@agadorsparticus>
Scott Chacon <schacon@gmail.com> writes:
> Subject: Re: [PATCH] added a built-in alias for 'stage' to the 'add' command
s/added/Add/;
Write your commit log message in present tense (recall David Brown's talk
at GitTogether '08? ;-)
> this comes from conversation at the GitTogether where we thought it would
s/this/This/;
> be helpful to be able to teach people to 'stage' files because it tends
> to cause confusion when told that they have to keep 'add'ing them.
>
> This continues the movement to start referring to the index as a
> staging area (eg: the --staged alias to 'git diff'). Also added a
> doc file for 'git stage' that basically points to the docs for
> 'git add'.
>
> Signed-off-by: Scott Chacon <schacon@gmail.com>
I think this is fine but I'd rather not risk the documentation getting
stale over time, so...
> +SYNOPSIS
> +--------
> +[verse]
> +'git stage' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
> + [--all | [--update | -u]] [--intent-to-add | -N]
> + [--refresh] [--ignore-errors] [--] <filepattern>...
...I think this should read something like
'git stage' args...
^ permalink raw reply
* Re: Managing websites with git
From: Leo Razoumov @ 2008-12-02 1:36 UTC (permalink / raw)
To: Jason Riedy, git; +Cc: Jeff King, David Bryson, Felix Andersen
In-Reply-To: <87k5ajflp0.fsf@sparse.dyndns.org>
On 12/1/08, Jason Riedy <jason@acm.org> wrote:
> And David Bryson writes:
> > One really should not push to a non-bare repo.
>
>
> WHAT?!?!?!
>
> And Jeff King responds:
>
> > It's in master and should be in 1.6.1, but it is a config option that
> > defaults to "warn" for now, so as not to break existing setups.
>
>
> WHAT?!?!?!
>
> I do this all the time. I clone from my main working directory
> onto some cluster / MPP where the build system is all wonky.
> Once I get everything building, I push back to a branch (often
> new) in my main working directory. Then I can merge the build
> changes whenever I get a chance.
>
> Pushing from these systems often is much, much easier than
> pulling from the origin. Sometimes you're working in temporary
> space on a back-end node; you can connect out but you cannot
> connect in.
>
> I've gotten a few people interested in git for managing these
> nearly one-off build problems. git is the first system that has
> "just worked" for them. Their having to configure each repo
> eliminates the "just works" factor.
>
> It feels like newer gits make more and more decisions about what
> I shouldn't do.
>
>
> Jason
>
I second Jason's opinion. I also frequently push to non-bare
intermediary repos. This functionality is essential for several of my
work flows. Please, please, do not handicap git-push operation!!
--Leo--
^ permalink raw reply
* Re: [PATCH 0/6 (v2)] Detecting HEAD more reliably while cloning
From: Junio C Hamano @ 2008-12-02 1:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4934082B.5050802@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Junio C Hamano schrieb:
>> Instead of introducing a full-fledged protocol extension, this round hides
>> the new information in the same place as the server capabilities list that
>> is used to implement protocol extension is hidden from older clients.
>
> Not that it makes a lot of difference, but why do you want to *hide* the
> information? Can't we just have a capability-with-parameter:
>
> ... shallow no-progress include-tag head=refs/heads/foo\ bar ...
>
> (with spaces and backslashes escaped)?
The ref namespace is reasonably tight (most importantly I do not think you
can have space) so there is no need for quoting. If we were to go that
route of making them extended "capabilities", the right syntax would be
... symref-HEAD=refs/heads/master symref-refs/remotes/origin/HEAD=refs/remotes/origin/master ...
or something like that.
^ permalink raw reply
* Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information
From: Junio C Hamano @ 2008-12-02 1:31 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081201174414.GA22185@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Mon, Dec 01, 2008 at 06:12:54AM -0800, Junio C Hamano wrote:
>
>> + packet_write(1, "%s %s%c%s%c%s\n", sha1_to_hex(sha1), refname,
>> + 0, capabilities, 0, target);
>
> Yuck. My two complaints are:
>
> (1) this implicitly handles only the HEAD symref.
But this information *is* on the "40-hex name" line that describes the
HEAD ;-)
You can trivially extend it to add this to other symbolic refs if you are
interested. I wasn't.
^ permalink raw reply
* Re: Managing websites with git
From: Jason Riedy @ 2008-12-02 0:46 UTC (permalink / raw)
To: Jeff King; +Cc: David Bryson, Felix Andersen, git
In-Reply-To: <20081130172717.GA7047@coredump.intra.peff.net>
And David Bryson writes:
> One really should not push to a non-bare repo.
WHAT?!?!?!
And Jeff King responds:
> It's in master and should be in 1.6.1, but it is a config option that
> defaults to "warn" for now, so as not to break existing setups.
WHAT?!?!?!
I do this all the time. I clone from my main working directory
onto some cluster / MPP where the build system is all wonky.
Once I get everything building, I push back to a branch (often
new) in my main working directory. Then I can merge the build
changes whenever I get a chance.
Pushing from these systems often is much, much easier than
pulling from the origin. Sometimes you're working in temporary
space on a back-end node; you can connect out but you cannot
connect in.
I've gotten a few people interested in git for managing these
nearly one-off build problems. git is the first system that has
"just worked" for them. Their having to configure each repo
eliminates the "just works" factor.
It feels like newer gits make more and more decisions about what
I shouldn't do.
Jason
^ permalink raw reply
* [PATCH] gitk: map / to focus the search box
From: Giuseppe Bilotta @ 2008-12-02 1:19 UTC (permalink / raw)
To: git; +Cc: Paul Mackerras, Junio C Hamano, Giuseppe Bilotta
In-Reply-To: <18740.26151.55900.953153@cargo.ozlabs.ibm.com>
The / key is often used to initiate searches (less, vim, some web
browsers). We change the binding for the / (slash) key from 'find next'
to 'focus the search box' to follow this convention.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Like this?
gitk-git/gitk | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 6b671a6..0c0350b 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2271,7 +2271,7 @@ proc makewindow {} {
bindkey b prevfile
bindkey d "$ctext yview scroll 18 units"
bindkey u "$ctext yview scroll -18 units"
- bindkey / {dofind 1 1}
+ bindkey / {focus $fstring}
bindkey <Key-Return> {dofind 1 1}
bindkey ? {dofind -1 1}
bindkey f nextfile
@@ -2652,7 +2652,7 @@ proc keys {} {
[mc "<%s-F> Find" $M1T]
[mc "<%s-G> Move to next find hit" $M1T]
[mc "<Return> Move to next find hit"]
-[mc "/ Move to next find hit, or redo find"]
+[mc "/ Focus the search box"]
[mc "? Move to previous find hit"]
[mc "f Scroll diff view to next file"]
[mc "<%s-S> Search for next hit in diff view" $M1T]
--
1.5.6.5
^ permalink raw reply related
* [PATCH] gitk: map / to focus the search box
From: Giuseppe Bilotta @ 2008-12-02 1:18 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Giuseppe Bilotta
The / key is often used to initiate searches (less, vim, some web
browsers). We change the binding for the / (slash) key from 'find next'
to 'focus the search box' to follow this convention.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
---
Like this?
gitk-git/gitk | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index 6b671a6..0c0350b 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -2271,7 +2271,7 @@ proc makewindow {} {
bindkey b prevfile
bindkey d "$ctext yview scroll 18 units"
bindkey u "$ctext yview scroll -18 units"
- bindkey / {dofind 1 1}
+ bindkey / {focus $fstring}
bindkey <Key-Return> {dofind 1 1}
bindkey ? {dofind -1 1}
bindkey f nextfile
@@ -2652,7 +2652,7 @@ proc keys {} {
[mc "<%s-F> Find" $M1T]
[mc "<%s-G> Move to next find hit" $M1T]
[mc "<Return> Move to next find hit"]
-[mc "/ Move to next find hit, or redo find"]
+[mc "/ Focus the search box"]
[mc "? Move to previous find hit"]
[mc "f Scroll diff view to next file"]
[mc "<%s-S> Search for next hit in diff view" $M1T]
--
1.5.6.5
^ permalink raw reply related
* Re: Managing websites with git
From: Jeff King @ 2008-12-02 1:11 UTC (permalink / raw)
To: Jason Riedy; +Cc: David Bryson, Felix Andersen, git
In-Reply-To: <87k5ajflp0.fsf@sparse.dyndns.org>
On Mon, Dec 01, 2008 at 07:46:35PM -0500, Jason Riedy wrote:
> And David Bryson writes:
> > One really should not push to a non-bare repo.
> WHAT?!?!?!
To clarify: one should not push to the _current branch_ of a non-bare
repo...
> And Jeff King responds:
> > It's in master and should be in 1.6.1, but it is a config option that
> > defaults to "warn" for now, so as not to break existing setups.
> WHAT?!?!?!
...and that is what 1.6.1 will warn about.
> I do this all the time. I clone from my main working directory
> onto some cluster / MPP where the build system is all wonky.
> Once I get everything building, I push back to a branch (often
> new) in my main working directory. Then I can merge the build
> changes whenever I get a chance.
As long as you are not pushing to the currently checked-out branch, then
you will see no change in behavior. If you are pushing to the currently
checked-out branch, then what are you doing to reconcile the resulting
mismatch between the index and HEAD?
> Pushing from these systems often is much, much easier than
> pulling from the origin. Sometimes you're working in temporary
> space on a back-end node; you can connect out but you cannot
> connect in.
Of course. The recommended thing to do is:
# on pusher
git push $remote HEAD:some-branch-that-is-not-checked-out
# on $remote
git merge some-branch-that-is-not-checked-out
where an obvious choice for branch name is "incoming/master" or whatever
suits your workflow. You can also do:
# on pusher
git push $remote HEAD:branch-that-is-checked-out
# on $remote
git reset --hard
but that throws away anything else going on in that branch on $remote.
> It feels like newer gits make more and more decisions about what
> I shouldn't do.
Doing
git push $remote HEAD:branch-that-is-checked-out
has _never_ worked without further action on $remote. Now we're warning
about it.
If you have other specific complaints about new git behavior, I'm sure
the list would be happy to hear about it. Almost every behavior change
is in response to user complaints, and a lot of effort is put into
maintaining backwards compatibility. If we've screwed up somewhere, it
would be good to know.
-Peff
^ permalink raw reply
* [PATCH] git-stash: use git rev-parse -q
From: Miklos Vajna @ 2008-12-02 0:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Don't redirect stderr to /dev/null, use -q to suppress the output on
stderr.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
git-stash.sh | 12 ++++++------
1 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index b9ace99..c0532e8 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -30,7 +30,7 @@ clear_stash () {
then
die "git stash clear with parameters is unimplemented"
fi
- if current=$(git rev-parse --verify $ref_stash 2>/dev/null)
+ if current=$(git rev-parse -q --verify $ref_stash)
then
git update-ref -d $ref_stash $current
fi
@@ -129,7 +129,7 @@ save_stash () {
}
have_stash () {
- git rev-parse --verify $ref_stash >/dev/null 2>&1
+ git rev-parse -q --verify $ref_stash >/dev/null
}
list_stash () {
@@ -229,16 +229,16 @@ drop_stash () {
fi
# Verify supplied argument looks like a stash entry
s=$(git rev-parse --verify "$@") &&
- git rev-parse --verify "$s:" > /dev/null 2>&1 &&
- git rev-parse --verify "$s^1:" > /dev/null 2>&1 &&
- git rev-parse --verify "$s^2:" > /dev/null 2>&1 ||
+ git rev-parse -q --verify "$s:" > /dev/null &&
+ git rev-parse -q --verify "$s^1:" > /dev/null &&
+ git rev-parse -q --verify "$s^2:" > /dev/null ||
die "$*: not a valid stashed state"
git reflog delete --updateref --rewrite "$@" &&
echo "Dropped $* ($s)" || die "$*: Could not drop stash entry"
# clear_stash if we just dropped the last stash entry
- git rev-parse --verify "$ref_stash@{0}" > /dev/null 2>&1 || clear_stash
+ git rev-parse -q --verify "$ref_stash@{0}" > /dev/null || clear_stash
}
apply_to_branch () {
--
1.6.0.4
^ permalink raw reply related
* Re: [JGIT PATCH 0/4] RepositoryTestCase cleanups
From: Johannes Schindelin @ 2008-12-01 23:18 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: Shawn O. Pearce, git, fonseca
In-Reply-To: <200811291301.12095.robin.rosenberg@dewire.com>
Hi,
On Sat, 29 Nov 2008, Robin Rosenberg wrote:
> [Repository refactoring] Would be cool, but having that diff engine is
> more important to me.
Stay tuned. I have something that outputs something resembling a diff
now. Of course, the output is not correct yet, due to bugs I introduced
cunnily when trying to fix another bug.
I'll keep you posted,
Dscho
^ permalink raw reply
* Re: [PATCH (GITK FIX)] gitk: Fix the "notflag: no such variable" error in --not processing.
From: Paul Mackerras @ 2008-12-01 22:45 UTC (permalink / raw)
To: Alexander Gavrilov; +Cc: Johannes Sixt, Git Mailing List
In-Reply-To: <200812012025.25286.angavrilov@gmail.com>
Alexander Gavrilov writes:
> This patch initializes it. Note that actually it is also possible to
> remove it completely, because currently nobody uses the value.
Thanks. I actually committed a change to remove it completely.
Paul.
^ permalink raw reply
* Re: [PATCH] gitk: map / to focus the search box
From: Paul Mackerras @ 2008-12-01 22:33 UTC (permalink / raw)
To: Giuseppe Bilotta; +Cc: git, Junio C Hamano
In-Reply-To: <1227459690-9896-1-git-send-email-giuseppe.bilotta@gmail.com>
Giuseppe Bilotta writes:
> The / key is often used to initiate searches (less, vim, some web
> browsers). We change the binding for the / (slash) key from 'find next'
> to 'focus the search box' to follow this convention.
I think that's reasonable, but the patch needs to update the key
bindings help text as well.
Thanks,
Paul.
^ permalink raw reply
* Re: Is rebase always destructive?
From: Robin Rosenberg @ 2008-12-01 20:19 UTC (permalink / raw)
To: Csaba Henk; +Cc: git
In-Reply-To: <slrngj8884.2srb.csaba-ml@beastie.creo.hu>
måndag 01 december 2008 18:37:43 skrev Csaba Henk:
> On 2008-12-01, Nick Andrew <nick@nick-andrew.net> wrote:
> > On Mon, Dec 01, 2008 at 11:41:39AM +0000, Csaba Henk wrote:
> >> I can't see any option for rebase which would yield this cp-like
> >> behaviour. Am I missing something?
> >
> > How about this:
> >
> > git checkout topic
> > git branch keepme
> > git rebase master
>
> OK, thanks guys, now I'm enlightened (a little bit more than before).
And if you forgot to create the keepme branch you can access the previous
version using the topic@{1} or topic@{'1 hour ago'} etc. This uses the reflog
that tracks all "versions" of your branch. Keeping gitk running is nice way
to see previous versions (press F5 after rebase).
-- robin
^ permalink raw reply
* Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information
From: Junio C Hamano @ 2008-12-01 19:54 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20081201162011.GI23984@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Maybe we put on the first capability line a flag that lets the
> client know we have symref data in the advertised list, and then
> instead of sticking only HEAD into that first ref we put the names
> of the symrefs after the ref they point to.
>
> So we might see something like:
>
> xxxx......................... refs/heads/boo\0with-symref\0
> xxxx......................... refs/heads/master\0HEAD\0
> xxxx......................... refs/remotes/origin/HEAD\0refs/remotes/origin/master\0
>
> etc. Its probably harder to produce the output for, but it permits
> advertising all of the symrefs on the remote side, which may be good
> for --mirror, among other uses. It also should make it easier to put
> multiple symrefs down pointing at the same real ref, they could just
> be a space delimited list stored after the ref name, and if its the
> first ref in the stream, after the other capability advertisement.
It certainly is possible, and I think the arrangement v2 code makes
already keeps that option to talk about symrefs other than HEAD open. If
you want to send all the symref information, you would show something
like:
xxxx... HEAD\0<caps>\0refs/heads/master\n
xxxx... refs/heads/master\n
xxxx... refs/remotes/origin/HEAD\0<caps>\0refs/remotes/origin/master\n
xxxx... refs/remotes/origin/master\n
But in this round I am not interested in giving any "random symref"
information but "HEAD", so I omitted it from the code.
Notice that you need to repeat the capabilities list on each and every
line that describes a symbolic ref for that to work (and you do not need
"with-symref"), though. See what ll. 80-84 in connect.c does.
if (len != name_len + 41) {
free(server_capabilities);
server_capabilities = xstrdup(name + name_len + 1);
}
Historical accident mandates that the first hidden piece of information on
each and all of these lines _must_ be the capabilities list.
^ permalink raw reply
* Re: git configure script
From: Neale T. Pickett @ 2008-12-01 19:12 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpq7i6q8azp.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@imag.fr> writes:
> It does, since it includes config.mak.autogen which overrides prefix
> defined in Makefile.
>
> I'm 99% sure you did something wrong. You should investigate by
> looking into config.mak.autogen after running configure.
This gave me the tip I needed. I was doing this in my Makefile:
make -C git-1.6.0.4 install
Instead of this:
cd git-1.6.0.4 && make install
Since the include was prefixed with "-", I didn't get any warnings or
errors about not being able to find config.mak.autogen, and it fell back
to the default.
I'm not sure using the -C option to make is "something wrong", but then
again I am apparently the first person to run into this problem, so it's
probably not a big deal.
Thanks for your help :)
Neale
^ permalink raw reply
* [PATCH] User's Manual: remove duplicated url at the end of Appendix B
From: Miklos Vajna @ 2008-12-01 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: J. Bruce Fields, git
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/user-manual.txt | 1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index da9c6b2..9f527d3 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -4572,4 +4572,3 @@ Alternates, clone -reference, etc.
More on recovery from repository corruption. See:
http://marc.theaimsgroup.com/?l=git&m=117263864820799&w=2
http://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2
- http://marc.theaimsgroup.com/?l=git&m=117147855503798&w=2
--
1.6.0.4
^ permalink raw reply related
* Re: [PATCH] Modified the default git help message to be grouped by topic
From: Jeff King @ 2008-12-01 18:32 UTC (permalink / raw)
To: Scott Chacon; +Cc: git, gitster
In-Reply-To: <20081201173037.GA41967@agadorsparticus>
On Mon, Dec 01, 2008 at 09:30:37AM -0800, Scott Chacon wrote:
> It's difficult to process 21 commands (which is what is output
> by default for git when no command is given). I've re-grouped
> them into 4 groups of 5 or 6 commands each, which I think is
> clearer and easier for new users to process.
I like it (and I think the categorizations look reasonable, which is
something that I recall caused some discussion at the GitTogether).
The only downside I see is that we're now >24 lines.
> This won't automatically update with the common-commands.txt file,
> but I think it is easier to parse for the command you may be looking
> for.
Personally, I don't see a big problem. This is not a list that should
change very frequently, and there is extra information here that would
be annoying to encode in the list. But since the "common" flag in
command-list.txt and the common-cmds.h file would no longer be used,
they should probably be removed.
-Peff
^ permalink raw reply
* Re: [PATCH] added a built-in alias for 'stage' to the 'add' command
From: Jeff King @ 2008-12-01 18:25 UTC (permalink / raw)
To: Scott Chacon; +Cc: git, gitster
In-Reply-To: <20081201172902.GA41963@agadorsparticus>
On Mon, Dec 01, 2008 at 09:29:02AM -0800, Scott Chacon wrote:
> this comes from conversation at the GitTogether where we thought it would
> be helpful to be able to teach people to 'stage' files because it tends
> to cause confusion when told that they have to keep 'add'ing them.
>
> This continues the movement to start referring to the index as a
> staging area (eg: the --staged alias to 'git diff'). Also added a
> doc file for 'git stage' that basically points to the docs for
> 'git add'.
FWIW, I think this is a step in the right direction. Or at least if it's
the wrong direction, I don't think we're actually _hurting_ anybody,
since we're not changing existing commands.
Out of curiosity, have you had any experiences referring to this as "git
stage" (maybe just by setting a per-user alias) with new users?
> +SYNOPSIS
> +--------
> +[verse]
> +'git stage' [-n] [-v] [--force | -f] [--interactive | -i] [--patch | -p]
> + [--all | [--update | -u]] [--intent-to-add | -N]
> + [--refresh] [--ignore-errors] [--] <filepattern>...
It seems like this might get stale with respect to git-add(1). Since
we're not hiding the fact that this is really an alias for "add", maybe
it would be better to just have "git stage [options] [--]
<filepattern>" (or maybe even something simpler).
-Peff
^ permalink raw reply
* Re: Add 'sane' mode to 'git reset'
From: Linus Torvalds @ 2008-12-01 18:06 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <32541b130812010944k3dd825e4pfa8c270ecc75d539@mail.gmail.com>
On Mon, 1 Dec 2008, Avery Pennarun wrote:
>
> For reference, I advised someone just yesterday to use "git reset
> HEAD^" to undo an accidental "commit -a" instead of just "commit".
Yeah, I guess the --mixed default of "git reset" is occasionally useful.
> Also, as far as I know, "git reset HEAD filename" is the only
> recommended way to undo an accidental "git add".
The path-name based ones are actually a totally different animal than the
non-pathname version of "git reset". With pathnames, it won't change the
actual HEAD, so it's really a totally different class of command, just
sharing a name.
But:
> How about calling it --merge instead? That's really what it does:
> merges the diffs from (your current index) to (the requested index)
> into (your working tree and your index).
Sure, "git reset --merge" would probably be a fine form.
Linus
^ permalink raw reply
* Re: Add 'sane' mode to 'git reset'
From: Jakub Narebski @ 2008-12-01 18:04 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130812010944k3dd825e4pfa8c270ecc75d539@mail.gmail.com>
Avery Pennarun wrote:
> On Mon, Dec 1, 2008 at 12:30 PM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
>> So add this kind of mode to "git reset", and since it's probably the
>> sanest form of reset (it will not throw any state away), just call it
>> that: "git reset --sane". It should probably be the default, but we likely
>> cannot change the semantics of a regular "git reset", even though it is
>> unlikely that very many people really use the current (insane) default
>> mode of "--mixed" that only resets the index.
[...]
> How about calling it --merge instead? That's really what it does:
> merges the diffs from (your current index) to (the requested index)
> into (your working tree and your index).
I like it, because it is similar to how "git checkout --merge" works.
> Or --keep, because it keeps your working tree changes.
That is also better than --sane...
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* [PATCH] gitweb: Fix handling of non-ASCII characters in inserted HTML files
From: Jakub Narebski @ 2008-12-01 18:01 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano, Tatsuki Sugiura, Gerrit Pape, Recai Oktas
In-Reply-To: <200811171140.45884.jnareb@gmail.com>
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)".
Note that inserting README.html lost one of checks for simplicity.
Noticed-by: Tatsuki Sugiura <sugi@nemui.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
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
but it is in principle the same solution.
I think this one as it is a bugfix should go in git 1.6.1
gitweb/gitweb.perl | 33 +++++++++++++++++----------------
1 files changed, 17 insertions(+), 16 deletions(-)
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 933e137..82262a3 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -2740,6 +2740,15 @@ sub get_file_owner {
return to_utf8($owner);
}
+# assume that file exists
+sub insert_file {
+ my $filename = shift;
+
+ open my $fd, '<', $filename;
+ print map(to_utf8, <$fd>);
+ close $fd;
+}
+
## ......................................................................
## mimetype related functions
@@ -2928,9 +2937,7 @@ EOF
"<body>\n";
if (-f $site_header) {
- open (my $fd, $site_header);
- print <$fd>;
- close $fd;
+ insert_file($site_header);
}
print "<div class=\"page_header\">\n" .
@@ -3017,9 +3024,7 @@ sub git_footer_html {
print "</div>\n"; # class="page_footer"
if (-f $site_footer) {
- open (my $fd, $site_footer);
- print <$fd>;
- close $fd;
+ insert_file($site_footer);
}
print "</body>\n" .
@@ -4358,9 +4363,7 @@ sub git_project_list {
git_header_html();
if (-f $home_text) {
print "<div class=\"index_include\">\n";
- open (my $fd, $home_text);
- print <$fd>;
- close $fd;
+ insert_file($home_text);
print "</div>\n";
}
print $cgi->startform(-method => "get") .
@@ -4472,13 +4475,11 @@ sub git_summary {
print "</table>\n";
if (-s "$projectroot/$project/README.html") {
- if (open my $fd, "$projectroot/$project/README.html") {
- print "<div class=\"title\">readme</div>\n" .
- "<div class=\"readme\">\n";
- print $_ while (<$fd>);
- print "\n</div>\n"; # class="readme"
- close $fd;
- }
+ print "<div class=\"title\">readme</div>\n" .
+ "<div class=\"readme\">\n";
+ insert_file("$projectroot/$project/README.html");
+ print "\n</div>\n"; # class="readme"
+ close $fd;
}
# we need to request one more than 16 (0..15) to check if
^ permalink raw reply related
* Re: Add 'sane' mode to 'git reset'
From: Avery Pennarun @ 2008-12-01 17:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0812010908120.3256@nehalem.linux-foundation.org>
On Mon, Dec 1, 2008 at 12:30 PM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> So add this kind of mode to "git reset", and since it's probably the
> sanest form of reset (it will not throw any state away), just call it
> that: "git reset --sane". It should probably be the default, but we likely
> cannot change the semantics of a regular "git reset", even though it is
> unlikely that very many people really use the current (insane) default
> mode of "--mixed" that only resets the index.
For reference, I advised someone just yesterday to use "git reset
HEAD^" to undo an accidental "commit -a" instead of just "commit".
Also, as far as I know, "git reset HEAD filename" is the only
recommended way to undo an accidental "git add". (Which I do
sometimes when I meant to write "git add -p".) Those two options are
pretty common, I think, and are also perfectly "sane".
How about calling it --merge instead? That's really what it does:
merges the diffs from (your current index) to (the requested index)
into (your working tree and your index).
Or --keep, because it keeps your working tree changes.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information
From: Jeff King @ 2008-12-01 17:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <1228140775-29212-6-git-send-email-gitster@pobox.com>
On Mon, Dec 01, 2008 at 06:12:54AM -0800, Junio C Hamano wrote:
> + packet_write(1, "%s %s%c%s%c%s\n", sha1_to_hex(sha1), refname,
> + 0, capabilities, 0, target);
Yuck. My two complaints are:
(1) this implicitly handles only the HEAD symref. I don't think any
others are in common use, but the rest of git handles arbitrary
symrefs just fine. It would be a shame to needlessly limit the
protocol. Can we at least make it <ref>:<ref> to allow later
expansion to other symrefs?
(1a) As a follow-on to that, because the client is not requesting
anything, how would we ask for other symrefs if we want to do so
later? I think it would be nice to eventually allow copying of
arbitrary symrefs within the refs/* hierarchy (e.g.,
project-specific branch aliases). Sending all symrefs right off
the bat is potentially large and wasteful.
(2) You've used up the first such expansion slot forever. Now it's "if
I want to tell you the symref, there is an extra slot, and
otherwise none". But if we ever want to use the _next_ slot, then
you will always have to send this slot (blank, I guess?). It gets
even more complicated if you ever want to an arbitrary number of
symref mappings. Maybe a short header to say "this slot contains a
symref target"?
So (1) and (2) together would make it something like:
<capabilities>\0
symref HEAD:refs/heads/master\0
symref refs/heads/alias:refs/heads/branch\n
which would make adding any new features in the expansion slots easier.
But that still doesn't address (1a). I really like the other proposal a
lot better.
-Peff
^ 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