* [PATCH] Add a built-in alias for 'stage' to the 'add' command
From: Scott Chacon @ 2008-12-02 6:14 UTC (permalink / raw)
To: gitster; +Cc: git, peff
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 adds a
doc file for 'git stage' that basically points to the docs for
'git add'.
Signed-off-by: Scott Chacon <schacon@gmail.com>
---
I changed the tense of a few things in the commit message and modified
the help file to be simpler.
Documentation/git-stage.txt | 19 +++++++++++++++++++
git.c | 1 +
2 files changed, 20 insertions(+), 0 deletions(-)
create mode 100644 Documentation/git-stage.txt
diff --git a/Documentation/git-stage.txt b/Documentation/git-stage.txt
new file mode 100644
index 0000000..7f251a5
--- /dev/null
+++ b/Documentation/git-stage.txt
@@ -0,0 +1,19 @@
+git-stage(1)
+==============
+
+NAME
+----
+git-stage - Add file contents to the staging area
+
+
+SYNOPSIS
+--------
+[verse]
+'git stage' args...
+
+
+DESCRIPTION
+-----------
+
+This is a synonym for linkgit:git-add[1]. Please refer to the
+documentation of that command.
diff --git a/git.c b/git.c
index 89feb0b..9e5813c 100644
--- a/git.c
+++ b/git.c
@@ -266,6 +266,7 @@ static void handle_internal_command(int argc, const char **argv)
const char *cmd = argv[0];
static struct cmd_struct commands[] = {
{ "add", cmd_add, RUN_SETUP | NEED_WORK_TREE },
+ { "stage", cmd_add, RUN_SETUP | NEED_WORK_TREE },
{ "annotate", cmd_annotate, RUN_SETUP },
{ "apply", cmd_apply },
{ "archive", cmd_archive },
--
1.6.0.8.gc9c8
^ permalink raw reply related
* Re: [PATCH] Modified the default git help message to be grouped by topic
From: Scott Chacon @ 2008-12-02 6:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v7i6jqriv.fsf@gitster.siamese.dyndns.org>
Hi,
On Mon, Dec 1, 2008 at 5:45 PM, Junio C Hamano <gitster@pobox.com> wrote:
> 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".
>
I sent a new patch that removes 'rm' and 'mv' and removes the
common-cmd.h build process. I did keep the 'status' command, since in
my personal experience people tend to like having that command.
Scott
^ permalink raw reply
* [PATCH] Modifies the default git help message to be grouped by topic
From: Scott Chacon @ 2008-12-02 6:05 UTC (permalink / raw)
To: gitster; +Cc: git, peff
It's difficult to process 21 commands (which is what is output
by default for git when no command is given). They have been
re-grouped into 4 groups of 5-6 commands each, which is clearer
and easier for new users to process.
Also removes the common-cmd.h generation process, including
parts of the Makefile and the generate-cmdlist.sh file.
As discussed at the GitTogether.
Signed-off-by: Scott Chacon <schacon@gmail.com>
---
This is a followup patch based on Junio and Jeffs feedback.
It also should apply cleanly which the other one would no
longer to, since it was from the GitTogether and then resent.
Makefile | 13 ++++---------
builtin-help.c | 40 ++++++++++++++++++++++++++--------------
generate-cmdlist.sh | 24 ------------------------
3 files changed, 30 insertions(+), 47 deletions(-)
delete mode 100755 generate-cmdlist.sh
diff --git a/Makefile b/Makefile
index 649cfb8..9a564cb 100644
--- a/Makefile
+++ b/Makefile
@@ -1117,7 +1117,7 @@ shell_compatibility_test: please_set_SHELL_PATH_to_a_more_modern_shell
strip: $(PROGRAMS) git$X
$(STRIP) $(STRIP_OPTS) $(PROGRAMS) git$X
-git.o: git.c common-cmds.h GIT-CFLAGS
+git.o: git.c GIT-CFLAGS
$(QUIET_CC)$(CC) -DGIT_VERSION='"$(GIT_VERSION)"' \
$(ALL_CFLAGS) -c $(filter %.c,$^)
@@ -1125,7 +1125,7 @@ git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
-builtin-help.o: builtin-help.c common-cmds.h GIT-CFLAGS
+builtin-help.o: builtin-help.c GIT-CFLAGS
$(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) \
'-DGIT_HTML_PATH="$(htmldir_SQ)"' \
'-DGIT_MAN_PATH="$(mandir_SQ)"' \
@@ -1137,11 +1137,6 @@ $(BUILT_INS): git$X
ln -s git$X $@ 2>/dev/null || \
cp git$X $@
-common-cmds.h: ./generate-cmdlist.sh command-list.txt
-
-common-cmds.h: $(wildcard Documentation/git-*.txt)
- $(QUIET_GEN)./generate-cmdlist.sh > $@+ && mv $@+ $@
-
$(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
$(QUIET_GEN)$(RM) $@ $@+ && \
sed -e '1s|#!.*/sh|#!$(SHELL_PATH_SQ)|' \
@@ -1363,7 +1358,7 @@ test-%$X: test-%.o $(GITLIBS)
check-sha1:: test-sha1$X
./test-sha1.sh
-check: common-cmds.h
+check:
if sparse; \
then \
for i in *.c; \
@@ -1498,7 +1493,7 @@ clean:
$(LIB_FILE) $(XDIFF_LIB)
$(RM) $(ALL_PROGRAMS) $(BUILT_INS) git$X
$(RM) $(TEST_PROGRAMS)
- $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo common-cmds.h TAGS tags cscope*
+ $(RM) *.spec *.pyc *.pyo */*.pyc */*.pyo TAGS tags cscope*
$(RM) -r autom4te.cache
$(RM) config.log config.mak.autogen config.mak.append config.status config.cache
$(RM) -r $(GIT_TARNAME) .doc-tmp-dir
diff --git a/builtin-help.c b/builtin-help.c
index f076efa..537534a 100644
--- a/builtin-help.c
+++ b/builtin-help.c
@@ -6,7 +6,6 @@
#include "cache.h"
#include "builtin.h"
#include "exec_cmd.h"
-#include "common-cmds.h"
#include "parse-options.h"
#include "run-command.h"
#include "help.h"
@@ -277,19 +276,32 @@ static struct cmdnames main_cmds, other_cmds;
void list_common_cmds_help(void)
{
- int i, longest = 0;
-
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- if (longest < strlen(common_cmds[i].name))
- longest = strlen(common_cmds[i].name);
- }
-
- puts("The most commonly used git commands are:");
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- printf(" %s ", common_cmds[i].name);
- mput_char(' ', longest - strlen(common_cmds[i].name));
- puts(common_cmds[i].help);
- }
+ puts("The most commonly used git commands are:\n\
+\n\
+Basic Commands\n\
+ init Create an empty git repository or reinitialize an existing one\n\
+ add Add file contents to the staging area\n\
+ status Show the working tree and staging area status\n\
+ commit Record changes in the staging area to the repository\n\
+\n\
+History Commands\n\
+ log Show commit log history\n\
+ diff Show changes between commits, commit and working tree, etc\n\
+ reset Reset your staging area or working directory to a specified state\n\
+ show Show various types of objects\n\
+\n\
+Branch Commands\n\
+ checkout Checkout a branch or paths to the working tree\n\
+ branch List, create, or delete branches\n\
+ merge Join two or more development histories together\n\
+ rebase Apply changes introduced in one branch onto another\n\
+ tag Create, list, delete or verify a tag object signed with GPG\n\
+\n\
+Remote Commands\n\
+ clone Clone a repository into a new directory\n\
+ fetch Download objects and refs from another repository\n\
+ pull Fetch from and merge with another repository or a local branch\n\
+ push Update remote refs along with associated objects");
}
static int is_git_command(const char *s)
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
deleted file mode 100755
index a2913c2..0000000
--- a/generate-cmdlist.sh
+++ /dev/null
@@ -1,24 +0,0 @@
-#!/bin/sh
-
-echo "/* Automatically generated by $0 */
-struct cmdname_help
-{
- char name[16];
- char help[80];
-};
-
-static struct cmdname_help common_cmds[] = {"
-
-sed -n -e 's/^git-\([^ ]*\)[ ].* common.*/\1/p' command-list.txt |
-sort |
-while read cmd
-do
- sed -n '
- /NAME/,/git-'"$cmd"'/H
- ${
- x
- s/.*git-'"$cmd"' - \(.*\)/ {"'"$cmd"'", "\1"},/
- p
- }' "Documentation/git-$cmd.txt"
-done
-echo "};"
--
1.6.0.8.gc9c8
^ permalink raw reply related
* Re: more merge strategies : feature request
From: Jeff King @ 2008-12-02 3:30 UTC (permalink / raw)
To: Caleb Cushing; +Cc: Andreas Ericsson, git
In-Reply-To: <81bfc67a0812011838m68100020v727da1c06f0bcee4@mail.gmail.com>
On Mon, Dec 01, 2008 at 09:38:07PM -0500, Caleb Cushing wrote:
> conflict: when auto-merging isn't merging the way you want it too, but
> you still want to see the diffs and handle them by hand. no commit
> won't do this, it just doesn't commit. I've had 2 situations now where
> git's fast-forward has overwritten changes in a branch I didn't want
> it to, it would have been better if I could handle them by hand
> without having to have 1 terminal open to the diff and the other open
> to the editor to fix it. and yes git was right by it's perspective,
> but the code it created was wrong by what I wanted and needed. I'm not
> really sure what more of a use case is needed for this.
It's not clear to me exactly what you want. Let's say I have a file
'foo' with changes from my merged branches in two different spots.
For example:
merge base branch A branch B
1 2 1
2 3 2
3 4 3
4 5 4
5
Did you want conflict markers in the resulting file? If so, what should
the conflict markers look like, since there isn't actually a conflict?
Alternatively, you could have git leave the file in an unmerged state,
and then access the base, ours, and theirs version from the index (or
even use git mergetool). Then you would get your desired versions into
the merging tool of your choice.
Of course, you could also just use a custom merge driver to accomplish
the same thing:
git config merge.xxdiff.driver 'xxdiff %A %O %B'
echo '* merge=xxdiff' >.gitattributes
git merge your-branch
and of course you can specify whatever subset of files you want to
actually do this for instead of '*'.
-Peff
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Leo Razoumov @ 2008-12-02 3:08 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <20081202024837.GB6804@coredump.intra.peff.net>
On 12/1/08, Jeff King <peff@peff.net> wrote:
> [..snip..]
> >
> Er, what? git-fetch takes a refspec very similar to the ones used by
> git-push. The real reason that (2) is not an acceptable solution is that
> you can't necessarily connect to the source repo (e.g., it is on your
> workstation with no ssh or git server running).
>
> -Peff
I am sorry, I had to be more accurate in my wording. "git fetch" with
no explicit refspecs fetches everything in. It is quite cumbersome to
form a refspec for git-fetch operation if you are not logged in into
the "source repo" machine. git-fetch does not have a --dry-run option
to help discover all the branch/tag names on the source side needed
for a meaningful refspec. "git-push -v --dry-run" allows one to
experiment and see what branches/tags exist at the destination and
form refspecs selectively. To the best of my knowledge, git-fetch does
not provide such discovery tools.
--Leo--
^ permalink raw reply
* Re: [PATCH 0/5] support reading and writing uncompressed loose object
From: Liu Yubao @ 2008-12-02 3:11 UTC (permalink / raw)
To: git list; +Cc: Junio C Hamano
In-Reply-To: <7voczws3np.fsf@gitster.siamese.dyndns.org>
Hi all,
It seems my patch series are not in one mail thread, I'm very sorry
for that, I replied this thread and paste my patches into Thunderbird
with external editor plugin, don't know why they become separate topics.
Best regards,
Liu Yubao
^ permalink raw reply
* Re: Git as a BuildRequires (packaging)
From: Jeff King @ 2008-12-02 3:09 UTC (permalink / raw)
To: Josh Boyer; +Cc: git, skvidal
In-Reply-To: <20081202023004.GA30372@zod.rchland.ibm.com>
On Mon, Dec 01, 2008 at 09:30:04PM -0500, Josh Boyer wrote:
> Recently we've hit an issue where a new package being reviewed for
> Fedora (cgit) needs to build against the git headers. The problem
> is that these headers aren't typically installed with the git
> package itself, and we have no git-devel subpackage either. This
> is mostly due to the fact that from what I can tell the upstream
> git Makefile doesn't install the headers anywhere.
I don't think Linus, Junio, or anybody involved with git has _ever_
advocated using git source files as a library. The expected method for
interfacing with git is the plumbing API, which is stable and available
via the installed git programs.
That being said, I think linking with libgit.a has been discussed on the
list, and Lars took part in the discussion. So I think he is aware that
what cgit does is not officially supported, that there is no stable
library API, and that he is taking his chances.
> There are a few options here. The first is to install the git
> headers and create a git-devel subpackage. That seems like
> overkill, given that the git headers are generically named and
> would have to be installed to something like /usr/include/git/.
I think that is a mistake; the headers are subject to change in ways that
will break calling code, and creating a -devel package creates the
impression that it's OK to link against it.
> The second option is to create a patch file that includes all
> the needed headers and use that in the cgit package. That is
> [...]
> The third option is to include the entire git tarball as part of
> the sources for the package. That is pretty easily done with the
> Fedora infrastructure, but isn't exactly clean from a packaging
> standpoint.
I don't know how one is usually expected to build cgit. But yes, you are
always going to have a problem with upgrading git. I would think each
cgit release would be tested based on a particular git version. And you
should rely on cgit upstream to figure that out and just package (either
in whole or as patches, as appropriate) the upstream git headers with
it.
> So, what do the git gurus recommend? I'm not sure if other
> distros have tackled this problem before, but some kind of
> commonality for the 'how do you package things that need to build
> against git' question would be nice.
AFAIK, cgit is the only program that behaves in this way, and it doesn't
seem to be in Debian at all. So you might be the first to deal with it.
:)
-Peff
^ permalink raw reply
* Re: two questions about the format of loose object
From: Liu Yubao @ 2008-12-02 3:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git list
In-Reply-To: <20081201153211.GH23984@spearce.org>
Shawn O. Pearce wrote:
> Liu Yubao <yubao.liu@gmail.com> wrote:
>> In current implementation the loose objects are compressed:
>>
>> loose object = deflate(typename + <space> + size + '\0' + data)
> ...
>> * Question 1:
>>
>> Why not use the format below for loose object?
>> loose object = typename + <space> + size + '\0' + deflate(data)
>
> Historical accident. We really should have used a format more
> like what you are asking here, because it makes inflation easier.
> The pack file format uses a header structure sort of like this,
> for exactly that reason. IOW we did learn our mistakes and fix them.
>
> If you look up the new style loose object code you'll see that it
> has a format like this (sort of), the header is actually the same
> format that is used in the pack files, making it smaller than what
> you propose but also easier to unpack as the code can be reused
> with the pack reading code.
>
> Unfortunately the new style loose object was phased out; it never
> really took off and it made the code much more complex. So it was
> pulled in commit 726f852b0ed7e03e88c419a9996c3815911c9db1:
>
In fact the format I proposed in my patches is uncompressed loose
object, not uncompressed loose object header, that's to say I
proposed format 2 in my question 2, I am just curious why the
loose object header is compressed in question 1.
I did a test to add all files of git-1.6.1-rc1 with git-add, the
time spent decreased by half. Other commands like git diff,
git diff --cached, git diff HEAD~ HEAD should be faster now
although the change may be not noticable for small and medium project.
> Author: Nicolas Pitre <nico@cam.org>:
> > deprecate the new loose object header format
> >
> > Now that we encourage and actively preserve objects in a packed form
> > more agressively than we did at the time the new loose object format and
> > core.legacyheaders were introduced, that extra loose object format
> > doesn't appear to be worth it anymore.
> >
> > Because the packing of loose objects has to go through the delta match
> > loop anyway, and since most of them should end up being deltified in
> > most cases, there is really little advantage to have this parallel loose
> > object format as the CPU savings it might provide is rather lost in the
> > noise in the end.
> >
> > This patch gets rid of core.legacyheaders, preserve the legacy format as
> > the only writable loose object format and deprecate the other one to
> > keep things simpler.
>
Thank you for dig it out for me!
Best regards,
Liu Yubao
^ permalink raw reply
* Re: more merge strategies : feature request
From: Leo Razoumov @ 2008-12-02 2:49 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Caleb Cushing, git
In-Reply-To: <4933AC03.6050300@op5.se>
On 12/1/08, Andreas Ericsson <ae@op5.se> wrote:
> Caleb Cushing wrote:
>
> > conflict: this strategy would always resolve in a merge conflict
> > allowing you to use git mergetool to piece the files back together.
> >
> > no-overwrite: if a change from the branch being merged in would
> > overwrite something in the current branch don't merge it. (I think it
> > needs a better name)
> >
I guess that "no-overwrite" can be achieved by
git merge -s ours --no-commit
--Leo--
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Jeff King @ 2008-12-02 2:48 UTC (permalink / raw)
To: Leo Razoumov; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <ee2a733e0812011822r4cef6a44ra68d6e84f9e30a90@mail.gmail.com>
On Mon, Dec 01, 2008 at 09:22:43PM -0500, Leo Razoumov wrote:
> I do not think that having a work-flow different from yours deserves a
> "somewhat insane" label. But let us consider the consequences of
a) you are responding to a nearly month-old message. Please read the
rest of the thread where we decide that it is not so insane, and
that the behavior should be configurable with a default of "warn"
at least for now.
b) My comment was not that it is insane simply because it is different
from mine. It is because it creates a dangerous situation (where
dangerous implies changes might be silently lost) which requires
manual intervention to fix, and which the user was given no warning
whatsoever about. It is a direct response to frequent complaints on
the list about users getting bit by this.
> (1) Switch target's current branch to something else (prevent a
> conflict) before pushing and then restore it back after the push
>
> (2) Use git-fetch from the target.
(3) Use git-reset --hard, but set a config variable that says "I know
what I'm doing." You don't even have to do it per-repo, you can do it
per-user.
(4) Push into a non-current branch and merge from the target.
> Method (2) is even worse, because git-fetch provides no control of
> what branches/tags to fetch, it sucks everything in from all branches.
> "git-push", OTOH, can be instructed to be very selective.
Er, what? git-fetch takes a refspec very similar to the ones used by
git-push. The real reason that (2) is not an acceptable solution is that
you can't necessarily connect to the source repo (e.g., it is on your
workstation with no ssh or git server running).
-Peff
^ permalink raw reply
* Re: two questions about the format of loose object
From: Liu Yubao @ 2008-12-02 2:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git list
In-Reply-To: <20081201152148.GG23984@spearce.org>
Shawn O. Pearce wrote:
> Liu Yubao <yubao.liu@gmail.com> wrote:
>> Thanks for your explanation, but I doubt if it's too costly to change the
>> format of loose object, after all this doesn't change the format of pack
>> file and affect git-pull/fetch of old git client.
>
> It is too costly; Jakub pointed out the dumb protocol clients
> would have issues with the new format. Anyone copying a repository
> between machines using scp or a USB memory stick may also run into
> a problem. Etc.
>
Yes, exceptional case, is it acceptable that core.uncompressedLooseObject
is set to false by default especially for NFS file system?
>> Some cons and pros.
>>
>> cons:
>>
>> * old git client can't read loose objects in new format
>> (People degrade git rarely and old git can read pack files
>> generated by new git, so it's not a big problem)
>
> That's a pretty big con. We can also add slower performance on NFS,
> as has been reported already by others.
>
I mean to add a format, not to replace the current format of loose object.
>> pros:
>>
>> * avoid compressing and uncompressing loose objects that are likely
>> frequently used when you are coding/merging
>
> True, loose objects are among the more frequently accessed items.
>
>> * share loose objects among multipe git processes
>
> Probably not a huge issue. How many concurrent git processes are
> you running on the same object store at once? During development?
> Its probably not more than 1. So sharing the objects doesn't make
> a very compelling argument.
>
In my company we have a central server to host source code repository
managed by git+ssh. Some collegues also work on the same machine (maybe
not a good practice) and set alternates to the central repository, so
there can be multiple git processes operating same git object database.
In fact we have a wrapper script of git to make git fit our development
process better because git's submodule support isn't good enough. One
command in the wrapper script can execute many git commands in a short
time.
>> * the new code path is simpler although we will have more code paths for
>> compatibility
>
> The new code path is more complex, because although one branch is
> very simple (mmap and use) the other code paths have to stay for
> backwards compatibility. Every time you add a branch point the
> code gets more complex. It works well enough now, and is at least
> one branch point simpler than what you are proposing. So I'm not
> really interested in seeing the change made.
>
Could you review my patches sent just a moment ago? The key changes are
rather small.
Best regards,
Liu Yubao
^ permalink raw reply
* [PATCH] git-svn: Make branch use correct svn-remote
From: Deskin Miller @ 2008-12-02 2:43 UTC (permalink / raw)
To: git; +Cc: gitster, normalperson, Deskin Miller
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>
---
Applies on v1.6.1-rc1. Apologies for not catching this when first
writing testcases for the branch subcommand.
Deskin Miller
git-svn.perl | 2 +-
t/t9128-git-svn-cmd-branch.sh | 17 +++++++++++++++++
2 files changed, 18 insertions(+), 1 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 914c707..e64e97b 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -558,7 +558,7 @@ sub cmd_branch {
my ($src, $rev, undef, $gs) = working_head_info($head);
- my $remote = Git::SVN::read_all_remotes()->{svn};
+ my $remote = Git::SVN::read_all_remotes()->{$gs->{repo_id}};
my $glob = $remote->{ $_tag ? 'tags' : 'branches' };
my ($lft, $rgt) = @{ $glob->{path} }{qw/left right/};
my $dst = join '/', $remote->{url}, $lft, $branch_name, ($rgt || ());
diff --git a/t/t9128-git-svn-cmd-branch.sh b/t/t9128-git-svn-cmd-branch.sh
index 47c4d4d..e2b6696 100755
--- a/t/t9128-git-svn-cmd-branch.sh
+++ b/t/t9128-git-svn-cmd-branch.sh
@@ -56,4 +56,21 @@ test_expect_success 'git svn branch tests' '
test_must_fail git svn tag tag1
'
+test_expect_success 'branch uses correct svn-remote' '
+ (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
+'
+
test_done
--
1.6.1.rc1
^ permalink raw reply related
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Leo Razoumov @ 2008-12-02 2:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git, Sam Vilain
In-Reply-To: <7vtz9npawn.fsf@gitster.siamese.dyndns.org>
On 12/1/08, Junio C Hamano <gitster@pobox.com> wrote:
> "Leo Razoumov" <slonik.az@gmail.com> writes:
>
> > On 11/8/08, Jeff King <peff@peff.net> wrote:
> >> On Fri, Nov 07, 2008 at 03:16:53PM -0800, Junio C Hamano wrote:
> >>
> >> > > The FAQ even says "don't do this until you know what you are doing." So
> >> > > the safety valve is configurable, so that those who know what they are
> >> > > doing can switch it off.
> >> >
> >> > "We are breaking your existing working setup but you can add a new
> >> > configuration to unbreak it" should not be done lightly. I think as the
> >> > end result it is a reasonable thing to aim for for this particular
> >> > feature, but we do need a transition plan patch in between that introduces
> >> > a step that warns but not forbids. We can ship 1.6.1 with it and then
> >> > switch the default to forbid in 1.6.3, for example.
> >>
> >>
> >> Yeah, I was kind of hoping we could assume that anybody relying on this
> >> behavior was somewhat insane, and wouldn't be too upset when it broke.
> >
> > I do not think that having a work-flow different from yours deserves a
> > "somewhat insane" label. But let us consider the consequences of
> > banning push into a (current branch) non-bare repo. To propagate
> > changes to such a non-bare repo there are two remaining alternatives
> > neither of which is fully satisfactory:
> >
> > (1) Switch target's current branch to something else (prevent a
> > conflict) before pushing and then restore it back after the push
> >
> > (2) Use git-fetch from the target.
>
>
> (3) set the config in the target repository to allow such a push
> regardless of the git version.
>
> Remember, I am in the third camp in this topic myself.
Junio,
thanks for supporting the "third way". I am not sure whether I
interpret it correctly but in the same thread several message earlier
you wrote "We can ship 1.6.1 with it and then switch the default to
forbid in 1.6.3, for example". With the default set to "deny" it would
be useful if the git-push error message will indicate what config
variable to set in order to reverse the denial.
--Leo--
^ permalink raw reply
* Re: more merge strategies : feature request
From: Caleb Cushing @ 2008-12-02 2:38 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4933AC03.6050300@op5.se>
> If you could come up with use-cases where each would be useful, I
> think you'd have a much easier time to gain acceptance for your
> suggestions. Right now, you're saying "I want a red button" but
> you're not explaining what it's for.
conflict: when auto-merging isn't merging the way you want it too, but
you still want to see the diffs and handle them by hand. no commit
won't do this, it just doesn't commit. I've had 2 situations now where
git's fast-forward has overwritten changes in a branch I didn't want
it to, it would have been better if I could handle them by hand
without having to have 1 terminal open to the diff and the other open
to the editor to fix it. and yes git was right by it's perspective,
but the code it created was wrong by what I wanted and needed. I'm not
really sure what more of a use case is needed for this.
no-overwrite: it's basically my way of saying that even though git
thinks it's changes are newer and better than the ones in my branch I
know they aren't. I only want the new stuff from the other branch. In
the second situation mentioned above I have 2 branches that I like to
merge back and forth, each needing a specific set of changes to
certain files however most changes are shared. when I merge them I
often have to change those specific changes back, if it didn't
ovewrite them I wouldn't have a problem.
for example I'm tracking my dot files with git, in my main user
account I set umask 077 however in my web development account I need
umask 027 so apache can read the files I create. when I create a
change in webdev and need to merge it back into master it overwrites
the 077 umask which I then change back. when I create a change in
master that I want in webdev it then changes webdev's umask. very
annoying.
the other problem I had was where I'd overwritten a file in another
branch just for the point of merging it into the master branch so I
could see the differences, and handle them properly (as I see it)
unfortunately git felt that this file was newer and simply overwrote
the changes in master. this was incorrect they were simply different
versions of the same type of file, like comparing an httpd.conf from a
gentoo and another from a fedora system. I was merely trying to figure
the best of both files to get the results I wanted.
technically the conflict strategy I propose would be adequate for both
but the no-overwrite seems like a good idea as well.
--
Caleb Cushing
^ permalink raw reply
* Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information
From: Jeff King @ 2008-12-02 2:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vwrqpvf.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 01, 2008 at 06:20:52PM -0800, Junio C Hamano wrote:
> I think sending 0{40} would break older clients, but older clients cannot
> clone from an empty repository anyway, so that should not be so bad. I
> however do not think it is such a big thing to be able to clone void
> anyway.
>
> You just have to train yourself to announce that your repository is
> clonable _after_ making it actually clonable.
I disagree. 99% of the time we see people complain about this, it is not
"I tried to announce my repo to people but it didn't have any commits"
but rather "why must I hack, init remote, then push, instead of init
remote, hack, push"[1].
That is, some segment of people (myself included) want to say first "I'm
starting a new project, and so I'm going to create a spot for it on my
server". Of course we can train ourselves to do it in the other order,
but it is an unnecessary complication.
-Peff
[1] Actually, it is more than just arbitrary preference. It is less
typing to do:
ssh remote 'mkdir foo && cd foo && git init --bare'
git clone remote:foo
hack hack hack; commit
git push
than
git init
hack hack hack; commit
ssh remote 'mkdir foo && cd foo && git init --bare'
git push
git remote add -m refs/heads/master origin remote:foo
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Junio C Hamano @ 2008-12-02 2:29 UTC (permalink / raw)
To: SLONIK.AZ; +Cc: Jeff King, Junio C Hamano, git, Sam Vilain
In-Reply-To: <ee2a733e0812011822r4cef6a44ra68d6e84f9e30a90@mail.gmail.com>
"Leo Razoumov" <slonik.az@gmail.com> writes:
> On 11/8/08, Jeff King <peff@peff.net> wrote:
>> On Fri, Nov 07, 2008 at 03:16:53PM -0800, Junio C Hamano wrote:
>>
>> > > The FAQ even says "don't do this until you know what you are doing." So
>> > > the safety valve is configurable, so that those who know what they are
>> > > doing can switch it off.
>> >
>> > "We are breaking your existing working setup but you can add a new
>> > configuration to unbreak it" should not be done lightly. I think as the
>> > end result it is a reasonable thing to aim for for this particular
>> > feature, but we do need a transition plan patch in between that introduces
>> > a step that warns but not forbids. We can ship 1.6.1 with it and then
>> > switch the default to forbid in 1.6.3, for example.
>>
>>
>> Yeah, I was kind of hoping we could assume that anybody relying on this
>> behavior was somewhat insane, and wouldn't be too upset when it broke.
>
> I do not think that having a work-flow different from yours deserves a
> "somewhat insane" label. But let us consider the consequences of
> banning push into a (current branch) non-bare repo. To propagate
> changes to such a non-bare repo there are two remaining alternatives
> neither of which is fully satisfactory:
>
> (1) Switch target's current branch to something else (prevent a
> conflict) before pushing and then restore it back after the push
>
> (2) Use git-fetch from the target.
(3) set the config in the target repository to allow such a push
regardless of the git version.
Remember, I am in the third camp in this topic myself.
^ permalink raw reply
* Git as a BuildRequires (packaging)
From: Josh Boyer @ 2008-12-02 2:30 UTC (permalink / raw)
To: git; +Cc: skvidal
Hi All,
Recently we've hit an issue where a new package being reviewed for
Fedora (cgit) needs to build against the git headers. The problem
is that these headers aren't typically installed with the git
package itself, and we have no git-devel subpackage either. This
is mostly due to the fact that from what I can tell the upstream
git Makefile doesn't install the headers anywhere.
There are a few options here. The first is to install the git
headers and create a git-devel subpackage. That seems like
overkill, given that the git headers are generically named and
would have to be installed to something like /usr/include/git/.
The second option is to create a patch file that includes all
the needed headers and use that in the cgit package. That is
sort of sub-optimal given that you'd have to keep checking
(and possibly regenerating) the patch for correctness every time
a new version of git comes out.
The third option is to include the entire git tarball as part of
the sources for the package. That is pretty easily done with the
Fedora infrastructure, but isn't exactly clean from a packaging
standpoint.
So, what do the git gurus recommend? I'm not sure if other
distros have tackled this problem before, but some kind of
commonality for the 'how do you package things that need to build
against git' question would be nice.
(Please CC me. I can't remember if I'm still subscribed to the
git list or not.)
thx,
josh
^ permalink raw reply
* Re: two questions about the format of loose object
From: Liu Yubao @ 2008-12-02 2:26 UTC (permalink / raw)
To: Nick Andrew; +Cc: git list
In-Reply-To: <20081201121611.GC32415@mail.local.tull.net>
Nick Andrew wrote:
> On Mon, Dec 01, 2008 at 04:00:55PM +0800, Liu Yubao wrote:
>> I did a simple benchmark on my notebook and a server in my company,
>> writing a big file to disk is faster than compressing it first and
>> writing the result out. The former's performance for reading should
>> also be better because of file cache.
>
> In a corporate environment (and not related to git) I found the
> opposite. The disk was fairly slow (over NFS) and it was in fact
> quicker to read and write compressed files.
>
> Nick.
>
Ok, there must be exceptional cases, for these cases you can turn
off core.uncompressedLooseObject (if there will be this config).
Best regards,
Liu Yubao
^ permalink raw reply
* Re: [RFC PATCH 0/4] deny push to current branch of non-bare repo
From: Leo Razoumov @ 2008-12-02 2:22 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git, Sam Vilain
In-Reply-To: <20081108142756.GC17100@coredump.intra.peff.net>
On 11/8/08, Jeff King <peff@peff.net> wrote:
> On Fri, Nov 07, 2008 at 03:16:53PM -0800, Junio C Hamano wrote:
>
> > > The FAQ even says "don't do this until you know what you are doing." So
> > > the safety valve is configurable, so that those who know what they are
> > > doing can switch it off.
> >
> > "We are breaking your existing working setup but you can add a new
> > configuration to unbreak it" should not be done lightly. I think as the
> > end result it is a reasonable thing to aim for for this particular
> > feature, but we do need a transition plan patch in between that introduces
> > a step that warns but not forbids. We can ship 1.6.1 with it and then
> > switch the default to forbid in 1.6.3, for example.
>
>
> Yeah, I was kind of hoping we could assume that anybody relying on this
> behavior was somewhat insane, and wouldn't be too upset when it broke.
I do not think that having a work-flow different from yours deserves a
"somewhat insane" label. But let us consider the consequences of
banning push into a (current branch) non-bare repo. To propagate
changes to such a non-bare repo there are two remaining alternatives
neither of which is fully satisfactory:
(1) Switch target's current branch to something else (prevent a
conflict) before pushing and then restore it back after the push
(2) Use git-fetch from the target.
Method (1) is no better than what is available today with "git reset
--hard" to sync working directory.
Method (2) is even worse, because git-fetch provides no control of
what branches/tags to fetch, it sucks everything in from all branches.
"git-push", OTOH, can be instructed to be very selective.
Here is an example of such a work-flow
Foo.git -- main bare repo of the project
Foo.wip -- everyday "work in progress" repo. Cloned from Foo.git.
Pushes to Foo.git
Foo.wip.insane -- experimental "crazy" stuff cloned from Foo.wip.
Pushed to Foo.wip
Proposed patch makes this work flow impossible (cannot push from
Foo.wip.insane to Foo.wip)
--Leo--
^ permalink raw reply
* Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information
From: Junio C Hamano @ 2008-12-02 2:20 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20081202015924.GA6529@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> (1) If there are multiple symrefs to report, we have to keep
> re-sending the server capabilities (I think you mentioned this in
> the subthread with Shawn).
This is nothing new, so there is nothing to complain about here.
The ref advertisement section is not very extensible to begin with and we
should consider ourselves lucky that Sergey Vlasov found the hole
(cf. $gmane/10710) we are exploiting to carry "server capabilities"; I do
not think we should nor can stuff any more than absolute minimum in the
section.
> (3) If HEAD doesn't point to a valid object, we have no place to put
> the symref. Or is it kosher to say
>
> 0000000000000000000000000000000000000000 HEAD\0...\0refs/heads/master
>
> ? I think it would be nice eventually to be able to clone a HEAD
> pointing to yet-to-be-born branch.
I think sending 0{40} would break older clients, but older clients cannot
clone from an empty repository anyway, so that should not be so bad. I
however do not think it is such a big thing to be able to clone void
anyway.
You just have to train yourself to announce that your repository is
clonable _after_ making it actually clonable.
^ permalink raw reply
* Re: two questions about the format of loose object
From: Liu Yubao @ 2008-12-02 2:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, git list
In-Reply-To: <m33ah8jfm2.fsf@localhost.localdomain>
Jakub Narebski wrote:
> Liu Yubao <yubao.liu@gmail.com> writes:
>
>> cons:
>>
>> * old git client can't read loose objects in new format
>> (People degrade git rarely and old git can read pack files
>> generated by new git, so it's not a big problem)
>
> You forgot about "dumb" protocols, namely HTTP and (deprecated) rsync
> (and IIRC also FTP), which doesn't generate packfiles, and would get
> loose object in format intelligible for old clients.
>
> IIRC this was main reason why core.legacyHeaders = false was abandoned.
>
The server can keep an old git or set core.uncompressedLooseObject = false.
Even the pack file format can be changed so that forward compatability will
be broken, I think it's unavoidable.
I'm not clear about the story of core.legacyHeaders, I'll dig the mail
list archive.
Thanks for reminding me of the dumb protocols.
Best regards,
Liu Yubao
^ permalink raw reply
* [PATCH 5/5] support writing uncompressed loose object
From: Liu Yubao @ 2008-12-02 2:03 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7voczws3np.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Liu Yubao <yubao.liu@gmail.com>
---
sha1_file.c | 16 ++++++++++++----
1 files changed, 12 insertions(+), 4 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 05a9fa3..053b564 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -2328,7 +2328,7 @@ static int create_tmpfile(char *buffer, size_t bufsiz, const char *filename)
}
static int write_loose_object(const unsigned char *sha1, char *hdr, int hdrlen,
- void *buf, unsigned long len, time_t mtime)
+ void *buf, unsigned long len, time_t mtime, int dont_deflate)
{
int fd, size, ret;
unsigned char *compressed;
@@ -2345,6 +2345,12 @@ static int write_loose_object(const unsigned char *sha1, char *hdr, int hdrlen,
return error("unable to create temporary sha1 filename %s: %s\n", tmpfile, strerror(errno));
}
+ if (dont_deflate) {
+ if (write_buffer(fd, hdr, hdrlen) < 0 || write_buffer(fd, buf, len) < 0)
+ die("unable to write sha1 file");
+ goto L_close_file;
+ }
+
/* Set it up */
memset(&stream, 0, sizeof(stream));
deflateInit(&stream, zlib_compression_level);
@@ -2376,9 +2382,11 @@ static int write_loose_object(const unsigned char *sha1, char *hdr, int hdrlen,
if (write_buffer(fd, compressed, size) < 0)
die("unable to write sha1 file");
- close_sha1_file(fd);
free(compressed);
+L_close_file:
+ close_sha1_file(fd);
+
if (mtime) {
struct utimbuf utb;
utb.actime = mtime;
@@ -2405,7 +2413,7 @@ int write_sha1_file(void *buf, unsigned long len, const char *type, unsigned cha
hashcpy(returnsha1, sha1);
if (has_sha1_file(sha1))
return 0;
- return write_loose_object(sha1, hdr, hdrlen, buf, len, 0);
+ return write_loose_object(sha1, hdr, hdrlen, buf, len, 0, 1);
}
int force_object_loose(const unsigned char *sha1, time_t mtime)
@@ -2423,7 +2431,7 @@ int force_object_loose(const unsigned char *sha1, time_t mtime)
if (!buf)
return error("cannot read sha1_file for %s", sha1_to_hex(sha1));
hdrlen = sprintf(hdr, "%s %lu", typename(type), len) + 1;
- ret = write_loose_object(sha1, hdr, hdrlen, buf, len, mtime);
+ ret = write_loose_object(sha1, hdr, hdrlen, buf, len, mtime, 1);
free(buf);
return ret;
--
1.6.1.rc1.5.gde86c
^ permalink raw reply related
* Re: [PATCH 5/6 (v2)] upload-pack: send the HEAD information
From: Jeff King @ 2008-12-02 1:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5ajqs63.fsf@gitster.siamese.dyndns.org>
On Mon, Dec 01, 2008 at 05:31:16PM -0800, Junio C Hamano wrote:
> > 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 ;-)
Ahhh. OK. I see, I misunderstood the protocol a bit. So let me revise my
complaints. ;)
(1) If there are multiple symrefs to report, we have to keep
re-sending the server capabilities (I think you mentioned this in
the subthread with Shawn).
(2) Similar to (2) before. If we ever add a _third_ extra slot, we
will be stuck sending the symref field each time we want to use
that third slot (though if the client properly treats an empty
slot the same as non-existent, this only wastes a single byte for
the NUL).
(3) If HEAD doesn't point to a valid object, we have no place to put
the symref. Or is it kosher to say
0000000000000000000000000000000000000000 HEAD\0...\0refs/heads/master
? I think it would be nice eventually to be able to clone a HEAD
pointing to yet-to-be-born branch.
-Peff
^ permalink raw reply
* [PATCH 4/5] support reading uncompressed loose object
From: Liu Yubao @ 2008-12-02 1:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7voczws3np.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Liu Yubao <yubao.liu@gmail.com>
---
sha1_file.c | 20 +++++++++++++++++++-
1 files changed, 19 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index 79062f0..05a9fa3 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1985,6 +1985,16 @@ static int sha1_loose_object_info(const unsigned char *sha1, unsigned long *size
map = map_sha1_file(sha1, &mapsize);
if (!map)
return error("unable to find %s", sha1_to_hex(sha1));
+
+ /*
+ * Is it an uncompressed loose objects?
+ */
+ if ((status = parse_sha1_header(map, mapsize, &size)) >= 0) {
+ if (sizep)
+ *sizep = size;
+ goto L_leave;
+ }
+
if (unpack_sha1_header(&stream, map, mapsize, hdr, sizeof(hdr)) < 0)
status = error("unable to unpack %s header",
sha1_to_hex(sha1));
@@ -1993,6 +2003,8 @@ static int sha1_loose_object_info(const unsigned char *sha1, unsigned long *size
else if (sizep)
*sizep = size;
inflateEnd(&stream);
+
+L_leave:
munmap(map, mapsize);
return status;
}
@@ -2124,7 +2136,13 @@ void *read_object(const unsigned char *sha1, enum object_type *type,
return buf;
map = map_sha1_file(sha1, &mapsize);
if (map) {
- buf = unpack_sha1_file(map, mapsize, type, size, sha1);
+ /*
+ * Is it an uncompressed loose object?
+ */
+ if ((*type = parse_sha1_header(map, mapsize, size)) >= 0)
+ buf = xmemdupz(map + strlen(map) + 1, *size);
+ else
+ buf = unpack_sha1_file(map, mapsize, type, size, sha1);
munmap(map, mapsize);
return buf;
}
--
1.6.1.rc1.5.gde86c
^ permalink raw reply related
* [PATCH 3/5] optimize parse_sha1_header() a little by detecting object type
From: Liu Yubao @ 2008-12-02 1:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git list
In-Reply-To: <7voczws3np.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Liu Yubao <yubao.liu@gmail.com>
---
sha1_file.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/sha1_file.c b/sha1_file.c
index dccc455..79062f0 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -1099,7 +1099,8 @@ static void *map_sha1_file(const unsigned char *sha1, unsigned long *size)
if (!fstat(fd, &st)) {
*size = xsize_t(st.st_size);
- map = xmmap(NULL, *size, PROT_READ, MAP_PRIVATE, fd, 0);
+ if (*size > 0)
+ map = xmmap(NULL, *size, PROT_READ, MAP_PRIVATE, fd, 0);
}
close(fd);
}
@@ -1257,6 +1258,8 @@ static int parse_sha1_header(const char *hdr, unsigned long length, unsigned lon
* terminating '\0' that we add), and is followed by
* a space, at least one byte for size, and a '\0'.
*/
+ if ('b' != *hdr && 'c' != *hdr && 't' != *hdr) /* blob/commit/tag/tree */
+ return -1;
i = 0;
while (hdr < hdr_end - 2) {
char c = *hdr++;
--
1.6.1.rc1.5.gde86c
^ permalink raw reply related
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