* [PATCH] bash completion: Remove dashed command completion support
From: Shawn O. Pearce @ 2008-07-15 5:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Since only 'git' and 'gitk' are in the user's $PATH now we do not
expect users to need completion support for git-fetch, and expect
they will instead rely upon the completion support for 'git fetch'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 53 --------------------------------
1 files changed, 0 insertions(+), 53 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 5844804..0e493a4 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1440,64 +1440,11 @@ _gitk ()
complete -o default -o nospace -F _git git
complete -o default -o nospace -F _gitk gitk
-complete -o default -o nospace -F _git_am git-am
-complete -o default -o nospace -F _git_apply git-apply
-complete -o default -o nospace -F _git_bisect git-bisect
-complete -o default -o nospace -F _git_branch git-branch
-complete -o default -o nospace -F _git_bundle git-bundle
-complete -o default -o nospace -F _git_checkout git-checkout
-complete -o default -o nospace -F _git_cherry git-cherry
-complete -o default -o nospace -F _git_cherry_pick git-cherry-pick
-complete -o default -o nospace -F _git_commit git-commit
-complete -o default -o nospace -F _git_describe git-describe
-complete -o default -o nospace -F _git_diff git-diff
-complete -o default -o nospace -F _git_fetch git-fetch
-complete -o default -o nospace -F _git_format_patch git-format-patch
-complete -o default -o nospace -F _git_gc git-gc
-complete -o default -o nospace -F _git_log git-log
-complete -o default -o nospace -F _git_ls_remote git-ls-remote
-complete -o default -o nospace -F _git_ls_tree git-ls-tree
-complete -o default -o nospace -F _git_merge git-merge
-complete -o default -o nospace -F _git_merge_base git-merge-base
-complete -o default -o nospace -F _git_name_rev git-name-rev
-complete -o default -o nospace -F _git_pull git-pull
-complete -o default -o nospace -F _git_push git-push
-complete -o default -o nospace -F _git_rebase git-rebase
-complete -o default -o nospace -F _git_config git-config
-complete -o default -o nospace -F _git_remote git-remote
-complete -o default -o nospace -F _git_reset git-reset
-complete -o default -o nospace -F _git_shortlog git-shortlog
-complete -o default -o nospace -F _git_show git-show
-complete -o default -o nospace -F _git_stash git-stash
-complete -o default -o nospace -F _git_submodule git-submodule
-complete -o default -o nospace -F _git_svn git-svn
-complete -o default -o nospace -F _git_log git-show-branch
-complete -o default -o nospace -F _git_tag git-tag
-complete -o default -o nospace -F _git_log git-whatchanged
# The following are necessary only for Cygwin, and only are needed
# when the user has tab-completed the executable name and consequently
# included the '.exe' suffix.
#
if [ Cygwin = "$(uname -o 2>/dev/null)" ]; then
-complete -o default -o nospace -F _git_add git-add.exe
-complete -o default -o nospace -F _git_apply git-apply.exe
complete -o default -o nospace -F _git git.exe
-complete -o default -o nospace -F _git_branch git-branch.exe
-complete -o default -o nospace -F _git_bundle git-bundle.exe
-complete -o default -o nospace -F _git_cherry git-cherry.exe
-complete -o default -o nospace -F _git_describe git-describe.exe
-complete -o default -o nospace -F _git_diff git-diff.exe
-complete -o default -o nospace -F _git_format_patch git-format-patch.exe
-complete -o default -o nospace -F _git_log git-log.exe
-complete -o default -o nospace -F _git_ls_tree git-ls-tree.exe
-complete -o default -o nospace -F _git_merge_base git-merge-base.exe
-complete -o default -o nospace -F _git_name_rev git-name-rev.exe
-complete -o default -o nospace -F _git_push git-push.exe
-complete -o default -o nospace -F _git_config git-config
-complete -o default -o nospace -F _git_shortlog git-shortlog.exe
-complete -o default -o nospace -F _git_show git-show.exe
-complete -o default -o nospace -F _git_log git-show-branch.exe
-complete -o default -o nospace -F _git_tag git-tag.exe
-complete -o default -o nospace -F _git_log git-whatchanged.exe
fi
--
1.5.6.2.393.g45096
^ permalink raw reply related
* Increased maintainer work during Summer of Code
From: Shawn O. Pearce @ 2008-07-15 6:04 UTC (permalink / raw)
To: Junio C Hamano
Cc: Christian Couder, Daniel Barkalow, Johannes Schindelin, J.H.,
Sam Vilain, git
In reading through the submitted mid-term surveys from students I
found this excellent answer from Stephan Beyer:
Q: What advice would you give to future would-be Summer of Code
mentoring organizations?
> I am wondering about one thing in git which is perhaps true for
> a lot of other mentoring organizations: There is one person, the
> maintainer, that is the final authority of deciding what patches
> go into the repositories and what not. (This is ok and good and if
> somebody disagrees a lot with such decisions he or she can make up
> a fork repo without problems.) But the point is that the maintainer
> has to review and add a lot of patches each day and _during GSoC
> this is even a lot more_. I sometimes wonder how the maintainer is
> able to handle that much work ;-) So my "advice" could be to think
> about the "problem" of more contributions during GSoC, and if it
> is useful to have co-maintainers or something. :)
Junio, I know you have been working extra hard lately with the
merge of builtin merge, and now gitweb and the sequencer are also
being looked at in much greater detail.
What can we do to smooth out this workload better? Its awesome
that we were so fortunate to get these great students this year,
and have so much contributed in so little time, but we also do
not want to see maintainer burn-out. We also want to avoid a
huge backlog of patches.
I don't think we really ever talked about how to help Junio work
through these large contributions that are coming his way.
--
Shawn.
^ permalink raw reply
* [PATCH v2] bash: Teach the bash completion about 'git send-email'
From: Teemu Likonen @ 2008-07-15 6:30 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, gitster
In-Reply-To: <20080715043839.GE2432@spearce.org>
Add the following long options to be completed with 'git send-email':
--bcc --cc --cc-cmd --chain-reply-to --compose --dry-run
--envelope-sender --from --identity --in-reply-to
--no-chain-reply-to --no-signed-off-by-cc --no-suppress-from
--no-thread --quiet --signed-off-by-cc --smtp-pass --smtp-server
--smtp-server-port --smtp-ssl --smtp-user --subject --suppress-cc
--suppress-from --thread --to
Short ones like --to and --cc are not usable for actual completion
because of the shortness itself and because there are longer ones which
start with same letters (--thread, --compose). It's still useful to have
these shorter options _listed_ when user presses TAB key after typing
two dashes. It gives user an idea what options are available (and --to
and --cc are probably the most commonly used).
Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
---
Shawn O. Pearce wrote (2008-07-15 04:38 +0000):
> Don't use __git_complete_file here. As far as I remember,
> git-send-email does not accept "origin/maint:some.patch" as an email
> to extract from Git prior to sending. It looks for files in the local
> filesystem. So you want standard bash completion for anything not
> starting with --.
>
> Just use COMPREPLY=() at the end. See _git_am for an example.
Done. And thanks.
> > +complete -o default -o nospace -F _git_send_email git-send-email
> Hmm. With dash form commands gone in 1.6 we should remove these.
>
> But I suspect this completion patch could be shipped in the next 1.5.6
> maint release as its really quite trivial. Junio, any comment on
> that?
This is a for-1.6 version so the completion for dashed command
(git-send-email) is dropped. I see Shawn already sent a patch which
drops all those.
contrib/completion/git-completion.bash | 19 +++++++++++++++++++
1 files changed, 19 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d268e6f..48ebbf7 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -905,6 +905,24 @@ _git_rebase ()
__gitcomp "$(__git_refs)"
}
+_git_send_email ()
+{
+ local cur="${COMP_WORDS[COMP_CWORD]}"
+ case "$cur" in
+ --*)
+ __gitcomp "--bcc --cc --cc-cmd --chain-reply-to --compose
+ --dry-run --envelope-sender --from --identity
+ --in-reply-to --no-chain-reply-to --no-signed-off-by-cc
+ --no-suppress-from --no-thread --quiet
+ --signed-off-by-cc --smtp-pass --smtp-server
+ --smtp-server-port --smtp-ssl --smtp-user --subject
+ --suppress-cc --suppress-from --thread --to"
+ return
+ ;;
+ esac
+ COMPREPLY=()
+}
+
_git_config ()
{
local cur="${COMP_WORDS[COMP_CWORD]}"
@@ -1376,6 +1394,7 @@ _git ()
rebase) _git_rebase ;;
remote) _git_remote ;;
reset) _git_reset ;;
+ send-email) _git_send_email ;;
shortlog) _git_shortlog ;;
show) _git_show ;;
show-branch) _git_log ;;
--
1.5.6.3.316.g01fc
^ permalink raw reply related
* Re: [PATCH v2] bash: Teach the bash completion about 'git send-email'
From: Shawn O. Pearce @ 2008-07-15 6:31 UTC (permalink / raw)
To: Teemu Likonen; +Cc: git, gitster
In-Reply-To: <20080715063034.GA3316@mithlond.arda.local>
Teemu Likonen <tlikonen@iki.fi> wrote:
> Add the following long options to be completed with 'git send-email':
>
> --bcc --cc --cc-cmd --chain-reply-to --compose --dry-run
> --envelope-sender --from --identity --in-reply-to
> --no-chain-reply-to --no-signed-off-by-cc --no-suppress-from
> --no-thread --quiet --signed-off-by-cc --smtp-pass --smtp-server
> --smtp-server-port --smtp-ssl --smtp-user --subject --suppress-cc
> --suppress-from --thread --to
>
> Short ones like --to and --cc are not usable for actual completion
> because of the shortness itself and because there are longer ones which
> start with same letters (--thread, --compose). It's still useful to have
> these shorter options _listed_ when user presses TAB key after typing
> two dashes. It gives user an idea what options are available (and --to
> and --cc are probably the most commonly used).
>
> Signed-off-by: Teemu Likonen <tlikonen@iki.fi>
Acked-by: Shawn O. Pearce <spearce@spearce.org>
Thanks for the quick reply cleaning up the minor details. :)
> Shawn O. Pearce wrote (2008-07-15 04:38 +0000):
>
> > Don't use __git_complete_file here. As far as I remember,
> > git-send-email does not accept "origin/maint:some.patch" as an email
> > to extract from Git prior to sending. It looks for files in the local
> > filesystem. So you want standard bash completion for anything not
> > starting with --.
> >
> > Just use COMPREPLY=() at the end. See _git_am for an example.
>
> Done. And thanks.
>
> > > +complete -o default -o nospace -F _git_send_email git-send-email
>
> > Hmm. With dash form commands gone in 1.6 we should remove these.
> >
> > But I suspect this completion patch could be shipped in the next 1.5.6
> > maint release as its really quite trivial. Junio, any comment on
> > that?
>
> This is a for-1.6 version so the completion for dashed command
> (git-send-email) is dropped. I see Shawn already sent a patch which
> drops all those.
>
>
>
> contrib/completion/git-completion.bash | 19 +++++++++++++++++++
> 1 files changed, 19 insertions(+), 0 deletions(-)
>
> diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
> index d268e6f..48ebbf7 100755
> --- a/contrib/completion/git-completion.bash
> +++ b/contrib/completion/git-completion.bash
> @@ -905,6 +905,24 @@ _git_rebase ()
> __gitcomp "$(__git_refs)"
> }
>
> +_git_send_email ()
> +{
> + local cur="${COMP_WORDS[COMP_CWORD]}"
> + case "$cur" in
> + --*)
> + __gitcomp "--bcc --cc --cc-cmd --chain-reply-to --compose
> + --dry-run --envelope-sender --from --identity
> + --in-reply-to --no-chain-reply-to --no-signed-off-by-cc
> + --no-suppress-from --no-thread --quiet
> + --signed-off-by-cc --smtp-pass --smtp-server
> + --smtp-server-port --smtp-ssl --smtp-user --subject
> + --suppress-cc --suppress-from --thread --to"
> + return
> + ;;
> + esac
> + COMPREPLY=()
> +}
> +
> _git_config ()
> {
> local cur="${COMP_WORDS[COMP_CWORD]}"
> @@ -1376,6 +1394,7 @@ _git ()
> rebase) _git_rebase ;;
> remote) _git_remote ;;
> reset) _git_reset ;;
> + send-email) _git_send_email ;;
> shortlog) _git_shortlog ;;
> show) _git_show ;;
> show-branch) _git_log ;;
> --
> 1.5.6.3.316.g01fc
>
--
Shawn.
^ permalink raw reply
* Re: Git describe question
From: Mark Burton @ 2008-07-15 6:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jean-Luc Herren, git
In-Reply-To: <7v1w1wf42n.fsf@gitster.siamese.dyndns.org>
On Mon, 14 Jul 2008 16:17:52 -0700
Junio C Hamano <gitster@pobox.com> wrote:
> Jean-Luc Herren <jlh@gmx.ch> writes:
>
> > Mark Burton wrote:
> > ...
> > I don't think people usually say "tag X is on branch Y", excepted
> > maybe if Y has never been merged anywhere. Specifically, nobody
> > would say v1.5.6.3 is *on* branch master. But it's part of its
> > history. v1.5.6.3 is *on* maint, at best.
>
> Actually I am somewhat sympathetic to Mark here. Probably what he wants
> is to describe 10ce020 as v1.5.6-390-10ce020.
>
> While that probably is doable by using the first-parent-only traversal, I
> do not think it is such a good idea. It is not how branches in git are
> designed to work. As Merlyn always says in #git at freenode, a branch is
> an illusion, and it is especially true in the presense of fast-forward
> merge (aka the upstream maintainer asking a subsystem lieutenant to do a
> merge for him).
Hi Guys,
Many thanks for the replies which make sense.
I guess the thing that prompted my original email was the fact that
when you look at output from gitk, the "distance" between 1.5.6.3 and
HEAD is only a few commits and that led me to expect that the output of
describe would show a smaller number than it does. I now understand why
it is how it is.
However, the git describe manual page does mention branches:
>With something like git.git current tree, I get:
>
> [torvalds@g5 git]$ git-describe parent
> v1.0.4-14-g2414721
>i.e. the current head of my "parent" branch is based on v1.0.4,
>but since it has a handful commits on top of that, describe has added
>the number of additional commits ("14") and an abbreviated object name
>for the commit itself ("2414721") at the end.
If you're a git newbie (like me) those words suggest that the commits
are "on" branch parent and you could measure the direct distance
between them by following the branch. Perhaps, the manual page should
contain a sentence similar to this:
Branches have no influence on the git describe long format output
which is derived only from the number of commits in the chain from the
described tag to the committish.
Cheers,
Mark
^ permalink raw reply
* Re: [PATCH 0/6] archive: refactor and cleanup
From: René Scharfe @ 2008-07-15 7:49 UTC (permalink / raw)
To: Lea Wiemann; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <487BE440.9010006@gmail.com>
Lea Wiemann schrieb:
> René Scharfe wrote:
>> This series is a collection of cleanups for git archive
>
> A few things:
>
> * The note quoted above probably shouldn't be in the commit message but
> after the "---".
Since it's in the zeroth message, it's not intended to be committed.
> * You patch messages seem to be In-Reply-To a message that wasn't posted
> on the list, not to PATCH 0/6.
Hmm, that's strange. Won't happen next time, though.
> * Unless you have a specific reason, I suggest that you don't Cc Junio
> on patches; he reads all messages on this list (more or less) and will
> usually simply apply your patches once they're reviewed. (Watch for his
> periodical "What's cooking in git.git" messages to see if he got them.)
We're both wrong, quoth Documentation/SubmittingPatches:
Note that your maintainer does not necessarily read everything
on the git mailing list. If your patch is for discussion first,
send it "To:" the mailing list, and optionally "cc:" him. If it
is trivially correct or after the list reached a consensus, send
it "To:" the maintainer and optionally "cc:" the list.
Obviously, my patches weren't trivially correct nor a consensus reached.
> * And most importantly, your Thunderbird introduced line-breaks, so it's
> not possible to apply the patches. May I suggest you use git-send-email
> instead?
Well, it is possible to send usable patches with Thunderbird, using the
extension Toggle Word Wrap. Patches 1 and 3 are damaged because I
edited them again to correct a typo -- with word wrap accidentally on.
Trying git-send-email again is a good idea, though.
> Feel free to ping me on IRC (lea_w in #git) if you need help.
I've slacked long enough to become a complete noob again. Oh, well.
Thanks,
René
^ permalink raw reply
* Re: [PATCH 3/6] archive: add baselen member to struct archiver_args
From: René Scharfe @ 2008-07-15 7:49 UTC (permalink / raw)
Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <487BA7C9.6090908@lsrfire.ath.cx>
[Resent with fixed line wrap.]
Calculate the length of base and save it in a new member of struct
archiver_args. This way we don't have to compute it in each of the
format backends.
Note: parse_archive_args() guarantees that ->base won't ever be NULL.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
archive-tar.c | 8 +++-----
archive-zip.c | 8 +++-----
archive.h | 1 +
builtin-archive.c | 1 +
4 files changed, 8 insertions(+), 10 deletions(-)
diff --git a/archive-tar.c b/archive-tar.c
index 6eaf59e..63cc2ec 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -268,19 +268,17 @@ static int write_tar_entry(const unsigned char *sha1, const char *base,
int write_tar_archive(struct archiver_args *args)
{
- int plen = args->base ? strlen(args->base) : 0;
-
git_config(git_tar_config, NULL);
archive_time = args->time;
verbose = args->verbose;
commit = args->commit;
- base_len = args->base ? strlen(args->base) : 0;
+ base_len = args->baselen;
if (args->commit_sha1)
write_global_extended_header(args->commit_sha1);
- if (args->base && plen > 0 && args->base[plen - 1] == '/') {
+ if (args->baselen > 0 && args->base[args->baselen - 1] == '/') {
char *base = xstrdup(args->base);
int baselen = strlen(base);
@@ -290,7 +288,7 @@ int write_tar_archive(struct archiver_args *args)
0, NULL);
free(base);
}
- read_tree_recursive(args->tree, args->base, plen, 0,
+ read_tree_recursive(args->tree, args->base, args->baselen, 0,
args->pathspec, write_tar_entry, NULL);
write_trailer();
diff --git a/archive-zip.c b/archive-zip.c
index 0d24f3f..d18254c 100644
--- a/archive-zip.c
+++ b/archive-zip.c
@@ -316,17 +316,15 @@ static void dos_time(time_t *time, int *dos_date, int *dos_time)
int write_zip_archive(struct archiver_args *args)
{
- int plen = strlen(args->base);
-
dos_time(&args->time, &zip_date, &zip_time);
zip_dir = xmalloc(ZIP_DIRECTORY_MIN_SIZE);
zip_dir_size = ZIP_DIRECTORY_MIN_SIZE;
verbose = args->verbose;
commit = args->commit;
- base_len = args->base ? strlen(args->base) : 0;
+ base_len = args->baselen;
- if (args->base && plen > 0 && args->base[plen - 1] == '/') {
+ if (args->baselen > 0 && args->base[args->baselen - 1] == '/') {
char *base = xstrdup(args->base);
int baselen = strlen(base);
@@ -336,7 +334,7 @@ int write_zip_archive(struct archiver_args *args)
0, NULL);
free(base);
}
- read_tree_recursive(args->tree, args->base, plen, 0,
+ read_tree_recursive(args->tree, args->base, args->baselen, 0,
args->pathspec, write_zip_entry, NULL);
write_zip_trailer(args->commit_sha1);
diff --git a/archive.h b/archive.h
index 1b24ae3..34151f4 100644
--- a/archive.h
+++ b/archive.h
@@ -6,6 +6,7 @@
struct archiver_args {
const char *base;
+ size_t baselen;
struct tree *tree;
const unsigned char *commit_sha1;
const struct commit *commit;
diff --git a/builtin-archive.c b/builtin-archive.c
index 6ee3677..e7f4ec6 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -192,6 +192,7 @@ int parse_archive_args(int argc, const char **argv, const struct archiver **ar,
}
args->verbose = verbose;
args->base = base;
+ args->baselen = strlen(base);
return i;
}
--
1.5.6.2.212.g08b51
^ permalink raw reply related
* Re: [PATCH 1/6] archive: remove args member from struct archiver
From: René Scharfe @ 2008-07-15 7:49 UTC (permalink / raw)
Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <487BA7C1.3000109@lsrfire.ath.cx>
[Resent with fixed line wrap.]
Pass struct archiver and struct archiver_args explicitly to parse_archive_args
and remove the latter from the former. This allows us to get rid of struct
archiver_desc and simplifies the code a bit.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
archive.h | 5 +---
builtin-archive.c | 51 +++++++++++++++++++---------------------------
builtin-upload-archive.c | 11 +++++----
3 files changed, 28 insertions(+), 39 deletions(-)
diff --git a/archive.h b/archive.h
index ddf004a..1b24ae3 100644
--- a/archive.h
+++ b/archive.h
@@ -21,14 +21,11 @@ typedef void *(*parse_extra_args_fn_t)(int argc, const char **argv);
struct archiver {
const char *name;
- struct archiver_args args;
write_archive_fn_t write_archive;
parse_extra_args_fn_t parse_extra;
};
-extern int parse_archive_args(int argc,
- const char **argv,
- struct archiver *ar);
+extern int parse_archive_args(int argc, const char **argv, const struct archiver **ar, struct archiver_args *args);
extern void parse_treeish_arg(const char **treeish,
struct archiver_args *ar_args,
diff --git a/builtin-archive.c b/builtin-archive.c
index c2e0c1e..6ee3677 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -15,12 +15,7 @@
static const char archive_usage[] = \
"git-archive --format=<fmt> [--prefix=<prefix>/] [--verbose] [<extra>] <tree-ish> [path...]";
-static struct archiver_desc
-{
- const char *name;
- write_archive_fn_t write_archive;
- parse_extra_args_fn_t parse_extra;
-} archivers[] = {
+const struct archiver archivers[] = {
{ "tar", write_tar_archive, NULL },
{ "zip", write_zip_archive, parse_extra_zip_args },
};
@@ -79,21 +74,15 @@ static int run_remote_archiver(const char *remote, int argc,
return !!rv;
}
-static int init_archiver(const char *name, struct archiver *ar)
+static const struct archiver *lookup_archiver(const char *name)
{
- int rv = -1, i;
+ int i;
for (i = 0; i < ARRAY_SIZE(archivers); i++) {
- if (!strcmp(name, archivers[i].name)) {
- memset(ar, 0, sizeof(*ar));
- ar->name = archivers[i].name;
- ar->write_archive = archivers[i].write_archive;
- ar->parse_extra = archivers[i].parse_extra;
- rv = 0;
- break;
- }
+ if (!strcmp(name, archivers[i].name))
+ return &archivers[i];
}
- return rv;
+ return NULL;
}
void parse_pathspec_arg(const char **pathspec, struct archiver_args *ar_args)
@@ -145,7 +134,8 @@ void parse_treeish_arg(const char **argv, struct archiver_args *ar_args,
ar_args->time = archive_time;
}
-int parse_archive_args(int argc, const char **argv, struct archiver *ar)
+int parse_archive_args(int argc, const char **argv, const struct archiver **ar,
+ struct archiver_args *args)
{
const char *extra_argv[MAX_EXTRA_ARGS];
int extra_argc = 0;
@@ -190,17 +180,18 @@ int parse_archive_args(int argc, const char **argv, struct archiver *ar)
/* We need at least one parameter -- tree-ish */
if (argc - 1 < i)
usage(archive_usage);
- if (init_archiver(format, ar) < 0)
+ *ar = lookup_archiver(format);
+ if (!*ar)
die("Unknown archive format '%s'", format);
if (extra_argc) {
- if (!ar->parse_extra)
+ if (!(*ar)->parse_extra)
die("'%s' format does not handle %s",
- ar->name, extra_argv[0]);
- ar->args.extra = ar->parse_extra(extra_argc, extra_argv);
+ (*ar)->name, extra_argv[0]);
+ args->extra = (*ar)->parse_extra(extra_argc, extra_argv);
}
- ar->args.verbose = verbose;
- ar->args.base = base;
+ args->verbose = verbose;
+ args->base = base;
return i;
}
@@ -238,7 +229,8 @@ static const char *extract_remote_arg(int *ac, const char **av)
int cmd_archive(int argc, const char **argv, const char *prefix)
{
- struct archiver ar;
+ const struct archiver *ar = NULL;
+ struct archiver_args args;
int tree_idx;
const char *remote = NULL;
@@ -248,14 +240,13 @@ int cmd_archive(int argc, const char **argv, const char *prefix)
setvbuf(stderr, NULL, _IOLBF, BUFSIZ);
- memset(&ar, 0, sizeof(ar));
- tree_idx = parse_archive_args(argc, argv, &ar);
+ tree_idx = parse_archive_args(argc, argv, &ar, &args);
if (prefix == NULL)
prefix = setup_git_directory();
argv += tree_idx;
- parse_treeish_arg(argv, &ar.args, prefix);
- parse_pathspec_arg(argv + 1, &ar.args);
+ parse_treeish_arg(argv, &args, prefix);
+ parse_pathspec_arg(argv + 1, &args);
- return ar.write_archive(&ar.args);
+ return ar->write_archive(&args);
}
diff --git a/builtin-upload-archive.c b/builtin-upload-archive.c
index 371400d..295e24c 100644
--- a/builtin-upload-archive.c
+++ b/builtin-upload-archive.c
@@ -19,7 +19,8 @@ static const char lostchild[] =
static int run_upload_archive(int argc, const char **argv, const char *prefix)
{
- struct archiver ar;
+ const struct archiver *ar;
+ struct archiver_args args;
const char *sent_argv[MAX_ARGS];
const char *arg_cmd = "argument ";
char *p, buf[4096];
@@ -65,12 +66,12 @@ static int run_upload_archive(int argc, const char **argv, const char *prefix)
sent_argv[sent_argc] = NULL;
/* parse all options sent by the client */
- treeish_idx = parse_archive_args(sent_argc, sent_argv, &ar);
+ treeish_idx = parse_archive_args(sent_argc, sent_argv, &ar, &args);
- parse_treeish_arg(sent_argv + treeish_idx, &ar.args, prefix);
- parse_pathspec_arg(sent_argv + treeish_idx + 1, &ar.args);
+ parse_treeish_arg(sent_argv + treeish_idx, &args, prefix);
+ parse_pathspec_arg(sent_argv + treeish_idx + 1, &args);
- return ar.write_archive(&ar.args);
+ return ar->write_archive(&args);
}
static void error_clnt(const char *fmt, ...)
--
1.5.6.2.212.g08b51
^ permalink raw reply related
* Re: [PATCH 0/5] replacement for the part of js/more-win that is in pu
From: Johannes Sixt @ 2008-07-15 7:59 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Steffen Prohaska, git
In-Reply-To: <1216071689-14823-1-git-send-email-johannes.sixt@telecom.at>
Johannes Sixt schrieb:
> The interdiff to js/more-win is below. It is mostly the changes
> of 1/5.
>
> Johannes Sixt (5):
> Makefile: Normalize $(bindir) and $(gitexecdir) before comparing
> Record the command invocation path early
> Fix relative built-in paths to be relative to the command
> invocation
> Allow the built-in exec path to be relative to the command
> invocation path
> Allow add_path() to add non-existent directories to the path
I retract this series and also the earlier version (the part that is in pu).
If I had done due diligence, I could have found out earlier that it does
not solve the problem it tried to solve. Appologies for the noise. :-(
The series tries to derive the exec-path from argv[0] (if the built-in
path is relative). But if a command is invoked from CMD on Windows,
argv[0] doesn't have a path, there is only the program name, "git.exe". In
the past, we relied on the global variable _pgmptr (only Windows's C
runtime has this), which does contain the full path, and if we set
gitexecdir = $(bindir)
in the Makefile, then we get a working git.exe, but we put back all
commands into $PATH.
-- Hannes
^ permalink raw reply
* Re: [PATCH] bash completion: Fix the . -> .. revision range completion
From: Andreas Ericsson @ 2008-07-15 8:05 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, Junio C Hamano, Petr Baudis, git
In-Reply-To: <20080715042553.GD2432@spearce.org>
Shawn O. Pearce wrote:
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>> On Mon, 14 Jul 2008, Shawn O. Pearce wrote:
>>> What is $COMP_WORDBREAKS set to in your shell? In mine it
>>> appears to be:
>>>
>>> " \"'@><=;|&(:"
>> Ahhah. Indeed. I don't have the ':'.
> ...
>> Umm, if so, git should just set it in the completion script, no?
>
> OK, so it turns out not having : in COMP_WORDBREAKS is a very common
> case that we should somehow deal with, to aid our users.
>
> I'm concerned about just setting COMP_WORDBREAKS back to the default
> in the git completion script because then we get into an ordering
> game with the profile scripts, don't we? If git completion sources
> before the gvfs script we don't get our COMP_WORDBREAKS setting.
>
> I think we may need to do two things.
>
> If COMP_WORDBREAKS doesn't contain a :, try to reset it to include
> one when the script is sourced. This may "fix" git completion but
> make gvfs completion act differently, resulting in a thread on the
> gvfs lists. ;-)
>
> If COMP_WORDBREAKS doesn't contain : during a completion event than
> we need to do what your original patch asked, which is to include
> "$ref:" in the prefix, so the ref isn't lost.
>
> At least we understand the problem now, finally. I'll try to write
> up a patch for it tomorrow. Unfortunately packing to move has been
> really sucking up my time lately.
>
I beat you to it ;-) This works just fine for me regardless of whether
or not I have a colon in COMP_WORDBREAKS.
--%<--%<--%<--
From: Andreas Ericsson <ae@op5.se>
Subject: git-completion.bash: Handle "rev:path" completion properly
The gvfs package on at least Fedora9 installs its own bash
completion script which removes the colon from COMP_WORDBREAKS,
which acts as a list of characters where bash should consider
as word boundaries. Doing so breaks the git bash completion
script when handling any rev:path style argument.
This patch fixes it by prepending the "rev" part and the colon
(which otherwise gets lost) before adding the "path" part if
COMP_WORDBREAKS doesn't contain the colon we would otherwise
need.
Also fixes a nearby indented-with-spaces issue.
Spotted-by: Linus Torvalds <torvalds@linux-foundation.org>
Investigated-by: Björn Steinbrink <b.steinbrink@gmx.de>
Signed-off-by: Andreas Ericsson <ae@op5.se>
---
contrib/completion/git-completion.bash | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index d268e6f..e138022 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -293,7 +293,11 @@ __git_complete_file ()
*)
ls="$ref"
;;
- esac
+ esac
+ # When completing something like 'rev:path', bash behaves
+ # differently whether or not COMP_WORDBREAKS contains a
+ # colon or not. This lets it handle both cases
+ test "${COMP_WORDBREAKS//:}" = "$COMP_WORDBREAKS" && pfx="$ref:$pfx"
COMPREPLY=($(compgen -P "$pfx" \
-W "$(git --git-dir="$(__gitdir)" ls-tree "$ls" \
| sed '/^100... blob /s,^.* ,,
--
1.5.6.3.315.g10ce0
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply related
* Re: [PATCH] bash completion: Fix the . -> .. revision range completion
From: Andreas Ericsson @ 2008-07-15 8:10 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, Junio C Hamano, Petr Baudis, git
In-Reply-To: <487C5A2D.3000707@op5.se>
Andreas Ericsson wrote:
[ a whitespace damaged patch ]
Sorry about that. I'll try again in a short while. It seems sending
patches with thunderbird no longer works like it used to.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] bash completion: Fix the . -> .. revision range completion
From: Andreas Ericsson @ 2008-07-15 8:17 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, Junio C Hamano, Petr Baudis, git
In-Reply-To: <487C5B72.5040502@op5.se>
Andreas Ericsson wrote:
> Andreas Ericsson wrote:
>
> [ a whitespace damaged patch ]
>
> Sorry about that. I'll try again in a short while. It seems sending
> patches with thunderbird no longer works like it used to.
>
Apparently it wasn't ws-damaged after all. Just my font-settings
acting up on me.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* applying and committing patches in a single git command
From: Erez Zilber @ 2008-07-15 8:50 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
Someone created a patch with git-format-patch and sent it to me. I
would like to apply & commit the patch. If I use git-apply, it only
patches my tree without committing it. Now, I need to copy the commit
log, run git-commit and paste the commit log there. Is there a more
intelligent way to do that?
Thanks,
Erez
^ permalink raw reply
* Re: applying and committing patches in a single git command
From: Stephan Beyer @ 2008-07-15 8:52 UTC (permalink / raw)
To: Erez Zilber; +Cc: git@vger.kernel.org
In-Reply-To: <ce513bcc0807150150l783e9ff1kd7780dc59f4b5a3d@mail.gmail.com>
Hi,
Erez Zilber wrote:
> Hi,
>
> Someone created a patch with git-format-patch and sent it to me. I
> would like to apply & commit the patch. If I use git-apply, it only
> patches my tree without committing it. Now, I need to copy the commit
> log, run git-commit and paste the commit log there. Is there a more
> intelligent way to do that?
git-am is exactly what you want.
Regards.
--
Stephan Beyer <s-beyer@gmx.net>, PGP 0x6EDDD207FCC5040F
^ permalink raw reply
* Re: applying and committing patches in a single git command
From: Boaz Harrosh @ 2008-07-15 8:53 UTC (permalink / raw)
To: Erez Zilber; +Cc: git@vger.kernel.org
In-Reply-To: <ce513bcc0807150150l783e9ff1kd7780dc59f4b5a3d@mail.gmail.com>
Erez Zilber wrote:
> Hi,
>
> Someone created a patch with git-format-patch and sent it to me. I
> would like to apply & commit the patch. If I use git-apply, it only
> patches my tree without committing it. Now, I need to copy the commit
> log, run git-commit and paste the commit log there. Is there a more
> intelligent way to do that?
>
> Thanks,
> Erez
>
git-am, can take all bunch of them at once
Boaz
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Petr Baudis @ 2008-07-15 9:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vtzesff91.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 14, 2008 at 12:16:26PM -0700, Junio C Hamano wrote:
> Yeah, I think git-repack, git-gc, git-pack-objects and git-index-pack on
> the server side need a knob to tell it to stay conservative because the
> repository may be served over dumb protocols to avoid this problem.
>
> That knob could even be called
>
> [repack]
> usedeltabaseoffset = false
> [pack]
> indexversion = 1
Can you please mention this in release notes? Until now, I actually
thought you're speaking about a hypothetical improvement, not a knob we
actually have. :-) (BTW, turning off the usedeltabaseoffset is not
critical at least Debian-wise, and I think that really is the oldest Git
in widespread use.)
Now, there is of course still the issue of default behaviour, but at
least my concern is somewhat eased now. :-)
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: Closing the merge window for 1.6.0
From: Petr Baudis @ 2008-07-15 9:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Gerrit Pape, Johannes Schindelin, git
In-Reply-To: <7v3amcgujd.fsf@gitster.siamese.dyndns.org>
On Mon, Jul 14, 2008 at 12:00:54PM -0700, Junio C Hamano wrote:
> But as the upstream, we have our own deprecation schedule. We should of
> course plan carefully not to harm existing users of our releases, but
> frankly speaking, 18 months since 1.4.4.4 was tagged (early January 2007)
> is an eternity in git timescale. Maybe we will slow down someday, and
> this 18-month is not a set-in-stone rule in any way, but at this point
> even without the packfile format issues, I personally think anything
> before 1.5.0 is irrelevant --- maybe they are interesting as historical
> curiosities, but not more than that.
Really, I think this is should be put into certain perspective:
(i) This change is special since it affects client-server
compatibility in bare repositories. AFAIK, none of the others
you mention does this.
(ii) The CRC checking is perhaps quite an improvement, but I
don't think it is critical-to-have-just-now.
(iii) Most importantly, this is not about waiting another few
years for Debian to catch up, since the next stable release
should really be upcoming rather soon:
http://debian-community.org/LennyReleaseSchedule/
(iv) These problems do not concern people who are currently
_actively_ _working_ with Git; these people hopefully do not
use 1.4 willingly and already use Git from backports.org.
This is about user experience for casual users who are quite
possibly interested only in read-only tracking of upstream
using Git - these people will likely use default Debian Git
version and that is okay, because frankly, for them, the
1.5 improvements do not really matter much. This is also
large class of prospective future real Git users and we might
not want to ruin Git's reputation in their eyes.
--
Petr "Pasky" Baudis
GNU, n. An animal of South Africa, which in its domesticated state
resembles a horse, a buffalo and a stag. In its wild condition it is
something like a thunderbolt, an earthquake and a cyclone. -- A. Pierce
^ permalink raw reply
* Re: What's cooking in git.git (topics)
From: Johannes Schindelin @ 2008-07-15 9:22 UTC (permalink / raw)
To: Geoffrey Irving; +Cc: Junio C Hamano, git
In-Reply-To: <7f9d599f0807142038w62ccb69fv42d6dcf3dd4f2afd@mail.gmail.com>
Hi,
On Mon, 14 Jul 2008, Geoffrey Irving wrote:
> The problem (beyond the basic problem of me not having tried running the
> tests) is that the current caching code isn't taking into account the
> changing values of diff_options. t6007 computes a patch-id for a commit
> with one value of options.paths, and then tries to compute a _different_
> patch-id for the same commit using a different value of options.paths.
>
> Here are a few different ways of fixing this:
>
> 1. Modify commit_patch_id in patch-ids.c to compute a sha1 of the
> diff_options structure and xor it with the commit sha1 to get a truly
> unique hash of the input. This means the optimization can be safely
> applied for all patch-id computations regardless of the diff_options.
> I can add a diff_options_sha1 function in diff.[ch] to compute the
> checksum.
>
> 2. Restrict commit_patch_id in patch-ids.c to apply the optimization
> only if options.nr_paths is zero, and perhaps a few other conditions.
> This is rather fragile, since it would mean that the cache would
> break if someone decided to change the default diff options.
Funnily, (2) contradicts (1). The patch id is _different_ when you have
nr_paths > 0. At least in the general case.
So what you propose in (1) will not work, unless you also hash the path
names (in the correct order, otherwise you'll end up with two hashes).
OTOH I would be really surprised if you needed --cherry-pick with paths
and/or diff options more than once for the same commits. So the caching
does not make sense to begin with (especially since we do not have a
proper way of gc'ing it, right?).
So I'd suggest saving diff_opts before the command line parsing, and
disable the cache when it is different _and/or_ (||) nr_paths.
Ciao,
Dscho
^ permalink raw reply
* Re: applying and committing patches in a single git command
From: Erez Zilber @ 2008-07-15 9:46 UTC (permalink / raw)
To: Boaz Harrosh, s-beyer; +Cc: git@vger.kernel.org
In-Reply-To: <487C659E.60606@panasas.com>
On Tue, Jul 15, 2008 at 11:53 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
> Erez Zilber wrote:
>> Hi,
>>
>> Someone created a patch with git-format-patch and sent it to me. I
>> would like to apply & commit the patch. If I use git-apply, it only
>> patches my tree without committing it. Now, I need to copy the commit
>> log, run git-commit and paste the commit log there. Is there a more
>> intelligent way to do that?
>>
>> Thanks,
>> Erez
>>
> git-am, can take all bunch of them at once
>
> Boaz
>
Thanks. I have 2 more questions:
1. How can I tell git-am to take a patch from an e-mail from a gmail account?
2. If I have the actual patch on my machine (not in an e-mail
message), I guess that I need something else (not git-am). Is there
anything like that?
Thanks,
Erez
^ permalink raw reply
* Re: applying and committing patches in a single git command
From: Andreas Ericsson @ 2008-07-15 10:00 UTC (permalink / raw)
To: Erez Zilber; +Cc: Boaz Harrosh, s-beyer, git@vger.kernel.org
In-Reply-To: <ce513bcc0807150246g790ca009vc0a76bd6ef0aac9b@mail.gmail.com>
Erez Zilber wrote:
> On Tue, Jul 15, 2008 at 11:53 AM, Boaz Harrosh <bharrosh@panasas.com> wrote:
>> Erez Zilber wrote:
>>> Hi,
>>>
>>> Someone created a patch with git-format-patch and sent it to me. I
>>> would like to apply & commit the patch. If I use git-apply, it only
>>> patches my tree without committing it. Now, I need to copy the commit
>>> log, run git-commit and paste the commit log there. Is there a more
>>> intelligent way to do that?
>>>
>>> Thanks,
>>> Erez
>>>
>> git-am, can take all bunch of them at once
>>
>> Boaz
>>
>
> Thanks. I have 2 more questions:
> 1. How can I tell git-am to take a patch from an e-mail from a gmail account?
You can't, but you can save your gmail message to disc and pass
the saved file to "git am" (don't use "git-am" over "git am";
we're trying to get away from that old format of typing).
> 2. If I have the actual patch on my machine (not in an e-mail
> message), I guess that I need something else (not git-am). Is there
> anything like that?
>
git apply patchfile
patch (-p1) < patchfile
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Documentation/git-submodule.txt: Add Description section
From: Petr Baudis @ 2008-07-15 10:22 UTC (permalink / raw)
To: gitster; +Cc: git
Figuring out how submodules work conceptually is quite a bumpy
ride for a newcomer; the user manual helps (if one knows to actually
look into it), but the reference documentation should provide good
quick intro as well. This patch attempts to do that.
Signed-off-by: Petr Baudis <pasky@suse.cz>
---
Documentation/git-submodule.txt | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 105fc2d..3413704 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -16,6 +16,24 @@ SYNOPSIS
'git submodule' [--quiet] summary [--summary-limit <n>] [commit] [--] [<path>...]
+DESCRIPTION
+-----------
+Submodules are a special kind of tree entries which do not refer to a blob or
+a directory, but to a particular tree in another repository (living at a given
+URL). The tree entry describes the existence of a submodule with the given
+name and the exact revision that should be used, while the location of the
+repository is described in the `/.gitmodules` file. This command will manage
+the tree entries and contents of this file for you, as well as inspecting the
+status of your submodules and updating them.
+
+When adding a new submodule to the tree, the 'add' subcommand is to be used.
+However, when pulling a tree containing submodules, these will not be checked
+out by default; the 'init' and 'update' subcommands will maintain submodules
+checked out and at appropriate revision in your working tree. You can inspect
+the current status of your submodules using the 'submodule' subcommand and get
+an overview of changes 'update' would perform using the 'summary' subcommand.
+
+
COMMANDS
--------
add::
^ permalink raw reply related
* Re: applying and committing patches in a single git command
From: Erez Zilber @ 2008-07-15 11:03 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Boaz Harrosh, s-beyer, git@vger.kernel.org
In-Reply-To: <487C752E.4090707@op5.se>
On Tue, Jul 15, 2008 at 1:00 PM, Andreas Ericsson <ae@op5.se> wrote:
> Erez Zilber wrote:
>>
>> On Tue, Jul 15, 2008 at 11:53 AM, Boaz Harrosh <bharrosh@panasas.com>
>> wrote:
>>>
>>> Erez Zilber wrote:
>>>>
>>>> Hi,
>>>>
>>>> Someone created a patch with git-format-patch and sent it to me. I
>>>> would like to apply & commit the patch. If I use git-apply, it only
>>>> patches my tree without committing it. Now, I need to copy the commit
>>>> log, run git-commit and paste the commit log there. Is there a more
>>>> intelligent way to do that?
>>>>
>>>> Thanks,
>>>> Erez
>>>>
>>> git-am, can take all bunch of them at once
>>>
>>> Boaz
>>>
>>
>> Thanks. I have 2 more questions:
>> 1. How can I tell git-am to take a patch from an e-mail from a gmail
>> account?
>
> You can't, but you can save your gmail message to disc and pass
> the saved file to "git am" (don't use "git-am" over "git am";
> we're trying to get away from that old format of typing).
>
>> 2. If I have the actual patch on my machine (not in an e-mail
>> message), I guess that I need something else (not git-am). Is there
>> anything like that?
>>
>
> git apply patchfile
> patch (-p1) < patchfile
Thanks.
^ permalink raw reply
* Standard "git svn init ; git svn fetch" behavior
From: "Peter Valdemar Mørch (Lists)" @ 2008-07-15 11:24 UTC (permalink / raw)
To: git
Hi,
I've now converted my svn repos to git with
$ git-svn init -T trunk -t tags -b branches file://some/path
$ git svn fetch
Wonderful!
I have two questions about the result:
1) It seems the svn tags were converted into git branches such as
"tags/mytag". Is that normal?
2) Why does master end up being off of tags/mytag instead of off of trunk?
###################################
Re: 1) It seems the svn tags were converted into git branches such as
"tags/mytag". Is that normal?
###################################
$ git tag -l
returns nothing and
$ git branch -a
returns all my svn tags as "tags/<tag>" git branches and all my svn
branches as expected in "the root".
Is that by design? Are there any downsides of creating a script that
foreach $tag ( m|tags/(.*)| ) {
git tag $tag $tag
git branch -r -D $tag
}
I'm cool with doing that, I just wanted to know if this is the expected
behaviour, and/or whether I'll run into trouble later because of a
wierdly converted subversion repository.
###################################
Re: 2) Why does master end up being off of tags/mytag instead of off of
trunk?
###################################
I would have expected, that "master" ended up tracking "trunk", and not
tags/mytag. Why track an obscure tag instead of trunk?
The tail of the fetch:
Successfully followed parent
W: +empty_dir: tags/mytag/probe/userHomedir/foo/cache/zlcache
W: +empty_dir: tags/mytag/probe/userHomedir/foo/pna_menu_items
r7375 = 5d3012afabccd348a5a5b81c5cf28532d324ea1b (tags/mytag)
Checking out files: 100% (2184/2184), done.
Checked out HEAD:
file:///home/pvm/cm/repos/tags/mytag r7375
("mytag" and "foo" replaced internal identifiers present in real output...)
$ git log --pretty=oneline --decorate -n 1
5d3012afabccd348a5a5b81c5cf28532d324ea1b (refs/remotes/tags/mytag,
refs/heads/master) Tag mytag
I rectified it with simply
$ git branch -m master old
$ git checkout -b master trunk
$ git branch -d old
Just wondering: Why is this behaviour the default? Is it a bug?
Is there a smarter way to find out what branchpoint was used to create
"master"? (I'm new to git, and find it difficult to see what my branches
were "made from")
Peter
--
Peter Valdemar Mørch
http://www.morch.com
^ permalink raw reply
* Re: [PATCH 1/6] archive: remove args member from struct archiver
From: Karl Hasselström @ 2008-07-15 12:29 UTC (permalink / raw)
To: René Scharfe; +Cc: git, Junio C Hamano
In-Reply-To: <487C5694.7050607@lsrfire.ath.cx>
On 2008-07-15 09:49:40 +0200, René Scharfe wrote:
> [Resent with fixed line wrap.]
And this remark embedded in the commit message. :-P
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* git stash save --keep-index
From: Sverre Rabbelier @ 2008-07-15 12:31 UTC (permalink / raw)
To: Git Mailinglist
Heya,
I have switched to using next/ recently and have had the chance to try
out the new '--keep-index' option to 'git stash'. I must say that 'git
stash save --keep-index' in combination with 'git add -p' followed by
'e' allows for a really nice workflow where I can split up patches
very easily, and test them before committing anything. IIUC the
'--keep-index' option was added as a response to the request to
support a workflow something like this:
<hack hack hack>
$ git add # or -i / -p
$ git stash save --keep-index
<test if staged changes are ready to be commited>
$ git commit
$ git stash pop
<lather, rinse, repeat>
But what happens if in the testing phase you detect that the commit is
not ready yet, or even, some of the changes you staged should have
been kept? It would make sense to 'undo' the stash the usual way:
$ git stash pop
But alas, it is not possible to apply on a dirty working directory, so
one has to resort to:
$ git commit -m "tmp"
$ git stash pop
$ git reset HEAD^
Nothing too bad surely, but I thought that the '--keep-index' option
was exactly to prevent having to do:
<hack hack hack>
$ git add # or -i / -p
$ git commit -m "tmp"
$ git stash save
<test if now committed changes were indeed ready to be comitted>
So the '--keep-index' option eliminates the need for such a temporary
commit in the (hopefully) common case where the selected changes were
indeed good, but we still need it in the case that the changes were
not ready / need something from the stashed changes.
Am I missing something here? Or is the only/best solution here to just
alias 'git commit -m "tmp" && git stash pop && git reset HEAD^' to
'git undo-stash'?
PS: It'd be nice if I could do 'git stash --keep-index' since I"m used
to 'git stash' automagically defaulting to 'git stash save'.
--
Cheers,
Sverre Rabbelier
^ 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