* [PATCH 4/7] builtin-merge: allow using a custom strategy
From: Miklos Vajna @ 2008-07-26 11:54 UTC (permalink / raw)
To: git
In-Reply-To: <cover.1217037178.git.vmiklos@frugalware.org>
Allow using a custom strategy, as long as it's named git-merge-foo. The
error handling is now done using is_git_command(). The list of available
strategies is now shown by list_commands().
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
builtin-merge.c | 19 ++++++++++++-------
1 files changed, 12 insertions(+), 7 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index e78fa18..cdbc692 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -22,6 +22,7 @@
#include "log-tree.h"
#include "color.h"
#include "rerere.h"
+#include "help.h"
#define DEFAULT_TWOHEAD (1<<0)
#define DEFAULT_OCTOPUS (1<<1)
@@ -77,7 +78,7 @@ static int option_parse_message(const struct option *opt,
static struct strategy *get_strategy(const char *name)
{
int i;
- struct strbuf err;
+ struct strategy *ret;
if (!name)
return NULL;
@@ -86,12 +87,16 @@ static struct strategy *get_strategy(const char *name)
if (!strcmp(name, all_strategy[i].name))
return &all_strategy[i];
- strbuf_init(&err, 0);
- for (i = 0; i < ARRAY_SIZE(all_strategy); i++)
- strbuf_addf(&err, " %s", all_strategy[i].name);
- fprintf(stderr, "Could not find merge strategy '%s'.\n", name);
- fprintf(stderr, "Available strategies are:%s.\n", err.buf);
- exit(1);
+ if (!is_git_command(name, "git-merge-")) {
+ fprintf(stderr, "Could not find merge strategy '%s'.\n\n", name);
+ list_commands("git-merge-", "strategies");
+ exit(1);
+ }
+
+ ret = xmalloc(sizeof(struct strategy));
+ memset(ret, 0, sizeof(struct strategy));
+ ret->name = xstrdup(name);
+ return ret;
}
static void append_strategy(struct strategy *s)
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: Mailing lists, was Re: [RFC] Git User's Survey 2008
From: Marek Zawirski @ 2008-07-26 12:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Shawn O. Pearce, Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <200807261254.53939.jnareb@gmail.com>
Jakub Narebski wrote:
> On Sat, 26 July 2008, Shawn O. Pearce wrote:
(...)
>> Actually I'd like the editor integration to be broken out (if
>> it isn't already) so we can see which editors (and thus which
>> integrations) are popular among users. I think it would help all
>> of the integration authors, as well as make it clear to end-users
>> where we have integration available/under development, in case they
>> were not aware of it previously.
>
> So you would like to see something like the following question in the
> upcoming Git User's Survey?
>
> xx. Which editors/IDEs/RADs do you use?
> (zero or more; multiple choice with 'other')
> - Emacs, Vim, Eclipse, KDevelop, Anjuta, TextMate, Notepad++,
> Visual Studio, other
> + what choices should be in the list of editors and IDE;
> or should perhaps this question be free-form?
If we stay with hard coded list of IDEs, I'd add NetBeans to this list.
I have an impression that quite many folks are asking about NetBeans
support for Git. Particularly, comparison between number of Eclipse and
NetBeans users using Git is interesting matter for potential jgit usage.
--
Marek Zawirski [zawir]
marek.zawirski@gmail.com
^ permalink raw reply
* Re: [PATCH] t7601: extend the 'merge picks up the best result' test
From: Miklos Vajna @ 2008-07-26 12:33 UTC (permalink / raw)
To: git
In-Reply-To: <1217073292-27945-1-git-send-email-vmiklos@frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 454 bytes --]
On Sat, Jul 26, 2008 at 01:54:45PM +0200, Miklos Vajna <vmiklos@frugalware.org> wrote:
> The test only checked if the best result picking code works if there are
> multiple strategies set in the config. Add a similar one that tests if
> the same true if the -s option of git merge was used multiple times.
Ignore this one. I run git send-email *.patch when sending out the other
series and forgot to do an rm *.patch before format-patch.
Sorry,
Miklos
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: git-scm.com
From: Petr Baudis @ 2008-07-26 13:07 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Scott Chacon, git
In-Reply-To: <m3hcadul6j.fsf@localhost.localdomain>
On Sat, Jul 26, 2008 at 01:03:26AM -0700, Jakub Narebski wrote:
> "Scott Chacon" <schacon@gmail.com> writes:
>
> > A followup on the post I did a few days ago about Git documentation.
> > I forked Petr's git.or.cz site and put up a version that I think is a
> > bit more accessible and newbie-friendly at git-scm.com. I had meant
> > to discuss this with Petr before posting it to you all, but I
> > published a blog post that got a bit more attention than I expected,
> > and I didn't want you all to think I didn't care about your opinion,
> > as some have already accused me of.
>
> On thing I am curious about: how do you plan to have current version
> of Git in the download / last version section? Petr Baudis uses
> custom script, which search git mailing list for "[ANNOUNCE]" posts,
> and automatically updates download / last version links.
Actually, I scan the last tag on maint branch using git descirbe; the
ANNOUNCE posts are scanned by the RSS feed. Originally, git-scm scanned
kernel.org download directory for the latest tarball, but it seemed that
would break on something like the 1.4.4.5, so it also moved to the git
describe method:
http://repo.or.cz/w/git-homepage.git?a=blob;f=update.sh
http://github.com/schacon/learn-github/tree/master/script/get_version.rb
One Scott's concern that didn't occur to me was that a the time of
release, we could have broken links between the time tag is created and
tarballs are wrapped up. I *think* that in practice, this happens at the
same time, I wonder if Junio could confirm that.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH] init: handle empty "template" parameter, was Re: fetch refspec foo/* matches foo*
From: Johannes Schindelin @ 2008-07-26 13:13 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20080726083356.GB10104@sigill.intra.peff.net>
Hi,
On Sat, 26 Jul 2008, Jeff King wrote:
> Also, while I have your attention, Junio, here is another bug fix
> that should go into 1.6.0. I posted the patch as a "how about this" deep
> in a thread and got no response (which means no complaints, right?).
Again it is in a thread...
> This patch just checks for that condition in copy_templates
> and aborts. As a side effect, this means that --template=
> now has the meaning "don't copy any templates."
I deem this patch obviously correct, and your reasoning as to what an
empty parameter should mean makes sense.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Modify mingw_main() workaround to avoid link errors
From: Johannes Schindelin @ 2008-07-26 13:17 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <1217065304-27815-1-git-send-email-prohaska@zib.de>
Hi,
On Sat, 26 Jul 2008, Steffen Prohaska wrote:
> -#define main(c,v) main(int argc, const char **argv) \
> +#define main(c,v) dummy_decl_mingw_main(); \
What is this dummy_*() statement supposed to do?
Note that I still think it would be a better fix to refactor the
lookup_prog() function from mingw.c.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] git-svn: teach dcommit about svn auto-props
From: Brad King @ 2008-07-26 14:08 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20080726054547.GA20494@untitled>
Eric Wong wrote:
> Brad King <brad.king@kitware.com> wrote:
>> Signed-off-by: Brad King <brad.king@kitware.com>
>
> Acked-by: Eric Wong <normalperson@yhbt.net>
Great, thanks!
>> ---
>> Eric Wong wrote:
>>> I haven't had the chance to look at this. Can anybody else shed more
>>> light on that bug? It's really strange that the tests won't run because
>>> of it. Are you unable to run some git-svn tests or all of them?
>> Just that one fails. All others (including the one in the patch below) pass.
>
> Exactly which test fails for you? Perhaps it's some setting in your
> ~/.subversion/config that's causing it to fail. Maybe we should set
> $HOME and use a clean ~/.subversion/config for git-svn tests regardless
> if that turns out to be the case...
$ cd $gitsrc/t
$ export SVNSERVE_PORT=5432
$ ./t9113-git-svn-dcommit-new-file.sh
* ok 1: start tracking an empty repo
* FAIL 2: create files in new directory with dcommit
mkdir git-new-dir &&
echo hello > git-new-dir/world &&
git update-index --add git-new-dir/world &&
git commit -m hello &&
start_svnserve &&
git svn dcommit
* failed 1 among 2 test(s)
I hacked the test script to log the dcommit output to a file, and I see
this:
Committing to svn://127.0.0.1:5432 ...
Use of uninitialized value in concatenation (.) or string at
/usr/lib/perl5/SVN/Core.pm line 584.
Authorization failed: at $gitsrc/t/../git-svn line 3329
(I replaced my git source dir full path with $gitsrc).
The version of libsvn-perl is: 1.5.0dfsg1-4
Please let me know if you need more info.
I tried moving my ~/.subversion/config out of the way but it makes no
difference. However, I agree we should block the user's home svn config
when running other dcommit tests now that we have auto-props. Perhaps
just using the --config-dir option with an empty directory would be enough.
-Brad
^ permalink raw reply
* [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Johannes Schindelin @ 2008-07-26 14:14 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, git, Junio C Hamano
In-Reply-To: <1217065304-27815-1-git-send-email-prohaska@zib.de>
When the program 'git' is in the PATH, the argv[0] is set to the basename.
However, argv0_path needs the full path, so add a function to discover the
program by traversing the PATH manually.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
So it is not easily possible to reuse this function in
compat/mingw.c, as Junio said that compat/ should not depend
(at least too much) on libgit.a.
Of course, we could try to follow a symlinked git, too, but I
think this is overkill until someone proves me wrong.
exec_cmd.c | 22 ++++++++++++++++++++++
exec_cmd.h | 1 +
git.c | 6 ++++++
3 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/exec_cmd.c b/exec_cmd.c
index 0ed768d..048f3ca 100644
--- a/exec_cmd.c
+++ b/exec_cmd.c
@@ -125,3 +125,25 @@ int execl_git_cmd(const char *cmd,...)
argv[argc] = NULL;
return execv_git_cmd(argv);
}
+
+char *lookup_program_in_path(const char *program)
+{
+ struct strbuf buf = STRBUF_INIT;
+ const char *path = getenv("PATH");
+
+ if (!path || !*path)
+ return NULL;
+
+ for (;;) {
+ const char *colon = strchrnul(path, PATH_SEP);
+
+ strbuf_setlen(&buf, 0);
+ strbuf_addf(&buf, "%.*s/%s",
+ (int)(colon - path), path, program);
+ if (!access(buf.buf, X_OK))
+ return strbuf_detach(&buf, NULL);
+ if (!*colon)
+ return NULL;
+ path = colon + 1;
+ }
+}
diff --git a/exec_cmd.h b/exec_cmd.h
index 0c46cd5..4548390 100644
--- a/exec_cmd.h
+++ b/exec_cmd.h
@@ -8,5 +8,6 @@ extern void setup_path(void);
extern int execv_git_cmd(const char **argv); /* NULL terminated */
extern int execl_git_cmd(const char *cmd, ...);
extern const char *system_path(const char *path);
+extern char *lookup_program_in_path(const char *program);
#endif /* GIT_EXEC_CMD_H */
diff --git a/git.c b/git.c
index 54c5bfa..0ec8ee1 100644
--- a/git.c
+++ b/git.c
@@ -428,6 +428,12 @@ int main(int argc, const char **argv)
do
--slash;
while (cmd <= slash && !is_dir_sep(*slash));
+ if (slash < cmd) {
+ cmd = lookup_program_in_path(cmd);
+ for (slash = (char *)cmd + strlen(cmd) - 1;
+ cmd <= slash && !is_dir_sep(*slash); slash--)
+ ; /* do nothing */
+ }
if (cmd <= slash) {
*slash++ = 0;
git_set_argv0_path(cmd);
--
1.5.6.2.516.g22071
^ permalink raw reply related
* Re: Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-26 14:17 UTC (permalink / raw)
To: Scott Chacon; +Cc: git
In-Reply-To: <d411cc4a0807260007i26791084lce6b6a8d74b831cc@mail.gmail.com>
Hi,
On Sat, Jul 26, 2008 at 12:07:03AM -0700, Scott Chacon wrote:
> On Fri, Jul 25, 2008 at 6:53 PM, Petr Baudis <pasky@suse.cz> wrote:
> > Plenty of minor fixes are available for pull at
> >
> > git://github.com/pasky/learn-github.git
> > (http://github.com/pasky/learn-github/tree/master)
>
> I've pulled in all this stuff and it should be live now.
thanks.
> >
> > Other non-trivial nits:
> >
> > * I'm feeling a bit uneasy about listing so many projects using Git;
> > I haven't heard about quite a few of these and I'm not sure on what
> > merit should we list projects. "Prototype" or "Liftweb" and probably
> > even "Rubinius", is that going to ring a bell for major part of visitors
> > so that they say "oh, even _those_ guys are using Git"?
>
> Based on a conversation in the other thread, I think we should have a
> list that is suggested by the community and just have the 3 or 4 that
> are really famous (Git, Linux, RoR...) and have the rest randomly
> pulled from that list - changed every day or so.
Maybe it is because of my general background, but I think X.org, WINE
and Fedora (probably in this order) really belong to the list as well.
If you say Prototype and MooTools are huge projects that are very
well-known in the web programmer community too, it makes sense to
include them as well; and that would be it. I might add
<p align="right"><em>...and many more</em><p>
below the list.
Having some of the list randomly generated is an interesting idea, but
it should be clearly visually separated from the static part, and it
would probably take a bit of work to tune this to show only interesting
projects ($size * sqrt(activity)$ or something).
> > * Reusing captions from command manpages in the Documentation page
> > shows nicely how awful they sometimes are. :-) This is probably something
> > to fix upstream, though.
>
> I saw you changed some of these, I can take another pass. I'm not
> entirely sure how useful it is to have the commands on that page, to
> tell the truth. This may go away as the documentation page evolves.
I agree. I changed none though, I just reordered some of the commands.
> > * Is "Git for the lazy" really unique in some regard to deserve to be
> > listed among the other resources? I think we should minimalize
> > redundancy at the documentation page, the amount of material is already
> > overwhelming and it should be obvious for the visitor which document to
> > choose based on his needs. I have similar doubts about the 37signals
> > resources.
> >
> > In other words, "let's keep the resources orthogonal!"
>
> I agree - I would like to pull a lot of the information in those links
> into one open-source book that is kept up by the community and hosted
> at this page. The documentation page will change significantly as we
> try to simplify and maximize the usefulness of the page.
But that's a long-term project, I'm talking about the usefulness of
some of the links right now.
> > * There is no reference to the Wiki in the documentation, only to the
> > [GitDocumentation] page; I think there should be a reference to the
> > [GitFaq] page too - a lot of important points that are not obvious
> > to newcomers are covered there. I'm just not sure where exactly to put
> > the link.
> >
> > * I would go as far as put the link to the Wiki itself to the
> > navigation bar, simply since it is such a crucial resource.
>
>
> Perhaps I should just do this - would that cover the previous one as well?
It seems you did, which is great! I think there should be a direct FAQ
link as well, though.
> > How does that compare with the Git user manual? Have you considered
> > collaborating on that one, or what are your reasons not to? Or are you
> > trying to do something different?
>
> I would like to - I have personally found that invaluable in learning
> Git, but I would like it to be more digestible and I would like to add
> a lot of supporting media to it - screencasts and diagrams, to help
> people that are more visual learners. Loading up a document where the
> TOC is several pages long is intimidating and difficult to start and
> stop with.
Making it more digestible is certainly a worthy goal. :-) I think both
screencasts and diagrams could be valuable for the user manual, but
the question is how to best integrate them into the manual and if it
makes sense to do this within the Git tree, or how to cross-merge.
However, at the documentation side I focus pretty much exclusively on
improving the reference documentation, so that's not for me to discuss.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: git sequencer prototype
From: Johannes Schindelin @ 2008-07-26 14:19 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <1217049644-8874-1-git-send-email-s-beyer@gmx.net>
Hi,
On Sat, 26 Jul 2008, Stephan Beyer wrote:
> In the last patchset I mentioned the issue, that the prototype is slow
> as hell. I know some bottlenecks, but I have not even tried to change
> that, because this is no issue for the builtin.
Why is it no issue for the builtin? Is it so much different from the
prototype?
Personally, I think if the prototype is so much slower, there is no sense
applying it into git.git, but I'd rather see you work on the builtin and
finalize it.
Ciao,
Dscho
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-26 14:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Scott Chacon, git
In-Reply-To: <7vtzedmeqh.fsf@gitster.siamese.dyndns.org>
On Fri, Jul 25, 2008 at 09:49:42PM -0700, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > On Fri, 25 Jul 2008, Junio C Hamano wrote:
> >
> >> It's also somewhat interesting to observe that several people I have
> >> never heard of in the git circle are simultaneously doing new git books,
> >> apparently never asking for much technical advice from core git people,
> >> by the way.
I would say we actually worked hard to make itpossible to understand
Git without being a Git contributor and knowing the code inside-out,
didn't we? So in a sense, having books about Git written by people
outside of the developer community could be considered a certain
milestone for Git usability. At least provided the books are good, and
reading the excerpts from
http://www.pragprog.com/titles/tsgit/pragmatic-version-control-using-git
has been a little disturbing experience at times. Then again, it is an
early alpha probably far before technical editing, so it is too early
to draw conclusions. (And after doing technical editing for a very thick
Czech book on low-level Linux programming, my standards for this phase
of book development had to be... somewhat lowered. ;-)
> Oh, mine was not a criticism but was just an observation.
>
> Maybe the folks we consider as "git community members" are either too
> narrow, or too detached from the "real user community", and it could be
> that git books are better written without us.
The numbers in another part of the thread show something important -
GitHub is more than SIX TIMES BIGGER than repo.or.cz! How many of you
have GitHub accounts, and how many of you are actively using repo.or.cz?
:-) And GitHub is not "just" Ruby on Rails *at all*:
http://github.com/blog/99-popular-languages
Overally, it seems that Git is getting huge traction in the web
developers community while this is something I would presume the core
Git community of kernel hackers and such is mostly unaware of (and it is
somewhat amusing contrast). Now, these are people who we will probably
never see on the mailing list, not just because they frequently don't
even know C, and don't care to, but they might have actually never used
a mailing list before! These are the people who frequently could not
care about their VCS' internals less and finding out that Git works well
enough for them is something rather satisfying for me personally.
I don't know if this should have any immediate effect on how we
develop Git etc., but I think it is good to be aware of the fact that
silently, huge amount of "dark mass" Git projects is accumulating and
that Git is making headways in areas many of us were little aware of.
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Rene Herman @ 2008-07-26 14:48 UTC (permalink / raw)
To: Scott Chacon; +Cc: Junio C Hamano, Petr Baudis, git
In-Reply-To: <d411cc4a0807260027t4b9c3b08x1f865ec75d976ef6@mail.gmail.com>
On 26-07-08 09:27, Scott Chacon wrote:
> Perhaps it would be useful to split the mailing list into
> core/contrib and support lists? I would be happy to help out
> answering questions - a lot of them come directly to me anyhow
> because of the gitcasts site and such.
A git-user list would be welcomed at least by me. It remains to be seen
how useful it would be (and stay) as often the user lists for a project
dwinddle a bit but I've subcribed and unsubscribed to this list a number
of times now since unless I've a specific question to ask, the list is
too busy too just sit around on; I end up deleting all list mail unread
every night anyway, so I just unsubcribe again.
Maybe a less busy and less implementation focussed list could help "me
and mine" gradually pick up new tips and tricks. Depends ofcourse on
willingness of some of the more proficient to be involved in that list
as well...
Rene.
^ permalink raw reply
* Re: [PATCH 2/5] Add git-sequencer documentation
From: Johannes Schindelin @ 2008-07-26 14:47 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <1217049644-8874-3-git-send-email-s-beyer@gmx.net>
Hi,
On Sat, 26 Jul 2008, Stephan Beyer wrote:
> +-B::
> +--batch::
> + Run in batch mode. If unexpected user intervention is needed
> + (e.g. a conflict or the need to run an editor), 'git-sequencer' fails.
Does it abort, or leave a dirty tree?
> +--onto=<base>::
> + Checkout given commit or branch before sequencing.
> + If you provide a branch, sequencer will make the provided
> + changes on the branch, i.e. the branch will be changed.
Whoa, does that mean that
$ git checkout my-private-branch
$ git sequencer --onto=master
will change _master_?
> +--continue::
> + Restart the sequencing process after having resolved a merge conflict.
What about 'edit'? Does it restart the sequencing process after editing a
file or commit message, too?
> +--skip::
> + Restart the sequencing process by skipping the current instruction.
s/ by/,/
> +--status::
> + Show the current status of 'git-sequencer' and what
> + operations can be done to change that status.
Nice.
> +--edit::
> + Invoke editor to edit the unprocessed part of the TODO file.
Nice!
> +If you nonetheless noticed that you made a mistake, you can
> +overwrite `.git/sequencer/todo` with `.git/sequencer/todo.old` and
> +rerun `git sequencer --edit`.
Speaking of "todo": there was an explicit request to change that to
"git-rebase-todo" for rebase -i, so that syntax highlighting could be
switched on.
> +-q::
> +--quiet::
> + Suppress output. Implies `--no-advice`.
> + (Not yet implemented.)
So this is not meant for application yet. Okay.
> +-v::
> +--verbose::
> + Be more verbose.
More?
> +NOTES
> +-----
> +
> +When sequencing, it is possible, that you are changing the history of
s/possible,/possible/ I know that mistake, being a German myself.
> +a branch in a way that can cause problems for anyone who already has
> +a copy of the branch in their repository and tries to pull updates from
> +you. You should understand the implications of using 'git-sequencer' on
> +a repository that you share.
How about this instead?
Note that sequencing will rewrite the history of the branch.
This will cause problems if you published the branch prior to
rewriting the history, as the former tip is no longer an
ancestor of the new tip.
In other words, if you rewrite an already published branch, users
that pull from you _will_ get a bogus merge.
> +'git-sequencer' will usually be called by another git porcelain, like
s/another git procelain/other git programs/
> +TODO FILE FORMAT
> +----------------
> +
> +The TODO file contains basically one instruction per line.
s/basically //
> +edit <commit>::
> + Pick a commit and pause the sequencer process to let you
> + make changes.
> ++
> +This is a short form for `pick <commit> and `pause` on separate lines.
It might make sense to explain 'pick' before 'edit', then.
> +mark <mark>::
> + Set a symbolic mark for the last commit.
> + `<mark>` is an unsigned integer starting at 1 and
> + prefixed with a colon, e.g. `:1`.
> ++
> +The marks can help if you want to refer to commits that you
> +created during the sequencer process, e.g. if you want to
> +merge such a commit.
It might make sense to explain 'merge' before that, then.
> + --mainline=<n>;;
> + Allow you to pick merge commits by specifying the
> + parent number (beginning from 1) to let sequencer
> + replay the changes relative to the specified parent.
Why is this called "mainline", and not "parent"?
> [... talking about 'patch']
>
> + --exclude=<path-pattern>;;
> + Do not apply changes to files matching the given path pattern.
> + This can be useful when importing patchsets, where you want to
> + exclude certain files or directories.
You might just as well support the new "--directory" option of git-apply,
too, and/or --recount.
> [talking about 'squash']
>
> + --collect-signoffs;;
> + Collect the Signed-off-by: lines of each commit and
> + add them to the squashed commit message.
> + (Not yet implemented.)
I really have to wonder how useful that is. Or how correct, for that
matter.
> +
> + --include-merges;;
> + Sanity check does not fail if you have merges
> + between HEAD and <mark>.
It may be a commit, too, right? And why does it make sense to check that
there are no merges? I mean, it is just as if I did two cherry-picks, the
second with -n, and then commit --amend it. Can make tons of sense...
> +Here are some examples that shall ease the start with the TODO
> +file format.
> +Make sure you have understood the `pick` and perhaps the `patch` command.
> +Those will not be explained further.
This sentence is insulting. Strike it.
> +------------
> +$ git rev-list --no-merges --reverse A^..E | sed -e 's/^/pick /'`
> +------------
Don't.
$ git log --pretty=format:'pick %h' --no-merges --reverse A^..E
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 5/5] Migrate rebase-i to sequencer
From: Johannes Schindelin @ 2008-07-26 14:52 UTC (permalink / raw)
To: Stephan Beyer; +Cc: git, Christian Couder, Daniel Barkalow
In-Reply-To: <1217049644-8874-6-git-send-email-s-beyer@gmx.net>
Hi,
On Sat, 26 Jul 2008, Stephan Beyer wrote:
> For git-rebase-i -p (preserving merges) merges should be
> rewritten. For this, the sequencer instructions "mark", "merge"
> and "reset" are used.
Ah, the ugliness returns.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Rene Herman @ 2008-07-26 14:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Johannes Sixt, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807261613120.26810@eeepc-johanness>
On 26-07-08 16:14, Johannes Schindelin wrote:
> When the program 'git' is in the PATH, the argv[0] is set to the
> basename. However, argv0_path needs the full path, so add a function
> to discover the program by traversing the PATH manually.
While not having read the context for this, this ofcourse sounds like a
huge gaping race-condition. If applicable here (as said, did not read
context) you generally want to make sure that there's no window that a
path could be replaced -- while perhaps not here, that's often the kind
of thing that security attacks end up abusing.
Rene.
^ permalink raw reply
* Re: [PATCH 2/7] builtin-help: change the current directory back in list_commands_in_dir()
From: Johannes Schindelin @ 2008-07-26 14:58 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <4f2b03391e3f85cf2224f97a2a7765d08707bd73.1217037178.git.vmiklos@frugalware.org>
Hi,
On Sat, 26 Jul 2008, Miklos Vajna wrote:
> That function used to do a chdir() without switching back to the
> original directory. That was not a problem till this function was used
> only inside builtin-help, but once other builtins use it as well, this
> is a problem, for example when the object database path is relative.
I had to work around that in my patch "git wrapper: DWIM mistyped
commands", too :-)
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 7/7] builtin-merge: avoid non-strategy git-merge commands in error message
From: Johannes Schindelin @ 2008-07-26 15:08 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <65a569c389352c5d0500b8c44c28e5572352e6ba.1217037178.git.vmiklos@frugalware.org>
Hi,
On Sat, 26 Jul 2008, Miklos Vajna wrote:
> + memset(¬_strategies, 0, sizeof(struct cmdnames));
> + for (i = 0; i < main_cmds.cnt; i++) {
Looking through all the discovered git commands? Cute... But does that
not exclude the commands that are in PATH, starting with git-merge-, even
if they are custom strategies?
> + int j, found = 0;
> + for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
> + if (!strcmp(main_cmds.names[i]->name, all_strategy[j].name))
> + found = 1;
> + if (!found)
> + add_cmdname(¬_strategies, main_cmds.names[i]->name, strlen(main_cmds.names[i]->name));
Better have a local variable "name" instead of writing out
"main_cmds.names[i]->name" all the time...
Oh, and you assume that the names are NUL-terminated (which I assume is
not the case in general, as the len member is the only thing that makes
struct cmdnames different from struct string_list.
Ciao,
Dscho
^ permalink raw reply
* Re: [EGIT PATCH] Support linked resources
From: Robin Rosenberg @ 2008-07-26 15:07 UTC (permalink / raw)
To: Richie Vos; +Cc: git
In-Reply-To: <5a27b7b0807232034t564e8d45l9f6e4bc6429cda60@mail.gmail.com>
torsdagen den 24 juli 2008 05.34.06 skrev Richie Vos:
> I have a project that outputs to a linked directory (for example the
> project is in /projects/foo and the project outputs to /projects/bar).
> This was causing egit to throw a bunch of "file is not in working
> path" errors whenever I rebuilt the project or otherwise interacted
> with that linked directory. I tracked it down to GitIndex's add/remove
> being called on these files even though these files are not part of
> the actual index.
>
> It seems like egit shouldn't be trying to interact with the index on
> these files, and after looking at it, I decided the best solution
> would be to realize in the RepositoryMapping that these files do not
> point to a repository.
I'd be inclined to prefer ignoring any non-plain resource, always. Linked
resources are either absolute or relative to a variable. Other than that
there is an analogy to symbolic links. Git manages the link, not its
content (unless handled elsewhere). The link in this case is in the
.project file and thus managed there.
EGit could still managed the resource, but not via the link, but rather at
the place it is located, iff that happens to be in a project managed by Egit.
-- robin
^ permalink raw reply
* Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Johannes Schindelin @ 2008-07-26 15:10 UTC (permalink / raw)
To: Rene Herman; +Cc: Steffen Prohaska, Johannes Sixt, git, Junio C Hamano
In-Reply-To: <488B3A97.6000606@keyaccess.nl>
Hi,
On Sat, 26 Jul 2008, Rene Herman wrote:
> On 26-07-08 16:14, Johannes Schindelin wrote:
>
> > When the program 'git' is in the PATH, the argv[0] is set to the
> > basename. However, argv0_path needs the full path, so add a function
> > to discover the program by traversing the PATH manually.
>
> While not having read the context for this, this ofcourse sounds like a huge
> gaping race-condition. If applicable here (as said, did not read context) you
> generally want to make sure that there's no window that a path could be
> replaced -- while perhaps not here, that's often the kind of thing that
> security attacks end up abusing.
Yeah, and that's why you would carefully time your attack just in between
the command invocation and the discovery of argv[0] in the PATH.
Rather than replacing the 'git' program with an infected version right
away.
Giggling,
Dscho
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Petr Baudis @ 2008-07-26 15:15 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Scott Chacon, git
In-Reply-To: <7vtzedktmi.fsf@gitster.siamese.dyndns.org>
On Sat, Jul 26, 2008 at 12:11:01AM -0700, Junio C Hamano wrote:
> The people who design the new features and write code should have easy
> access to the issues the users of all levels have with the software and
> the documentation (and what they find useful as well). What I am most
> afraid of is that both "We do not bother the coders" and "We are too busy
> to answer every newbie question" mentalities would lead to a fractured
> community.
The community is already fractured! I think we actually have very tiny
fraction of the user base on the mailing list - the traffic is simply
too massive. After all we chose _our_ convenience over _users'_
convenience in making this tradeoff. Also, as I mentioned in the other
mail, it's not obvious to me whether major part of our community would
be willing to participate in any mailing list at all.
(Note that I don't want to imply that this would be inherently a Bad
Thing. Some feedback still bubbles through and we have ways like Jakub's
Git User Survey as well. Maybe the user community is by now simply too
big to make the direct cross-pollination with developers feasible.)
There was a proposal some time ago for making a web forum for Git; maybe
we were too dismissive to the suggestion. I wonder where *do* these 100k
of registered GitHubbers get their Git support now? :-)
--
Petr "Pasky" Baudis
As in certain cults it is possible to kill a process if you know
its true name. -- Ken Thompson and Dennis M. Ritchie
^ permalink raw reply
* Re: [PATCH] Set up argv0_path correctly, even when argv[0] is just the basename
From: Rene Herman @ 2008-07-26 15:19 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Steffen Prohaska, Johannes Sixt, git, Junio C Hamano
In-Reply-To: <alpine.DEB.1.00.0807261709090.26810@eeepc-johanness>
On 26-07-08 17:10, Johannes Schindelin wrote:
> Hi,
>
> On Sat, 26 Jul 2008, Rene Herman wrote:
>
>> On 26-07-08 16:14, Johannes Schindelin wrote:
>>
>>> When the program 'git' is in the PATH, the argv[0] is set to the
>>> basename. However, argv0_path needs the full path, so add a function
>>> to discover the program by traversing the PATH manually.
>> While not having read the context for this, this ofcourse sounds like a huge
>> gaping race-condition. If applicable here (as said, did not read context) you
>> generally want to make sure that there's no window that a path could be
>> replaced -- while perhaps not here, that's often the kind of thing that
>> security attacks end up abusing.
>
> Yeah, and that's why you would carefully time your attack just in between
> the command invocation and the discovery of argv[0] in the PATH.
>
> Rather than replacing the 'git' program with an infected version right
> away.
Adding to the PATH is generally not disallowed by user level security.
Replacing the GIT binary generally is.
Sure maybe it's not much of a problem here; as said, I didn't read the
context and am not a GIT person. Just commented on a git-user list when
this was the next message on the list. Though a heads-up might still be
in order. If it wasn't useful -- so be it, but even making a command do
something different than a user expected can have serious implications,
for example in this case for the tree they are working on.
Rene.
^ permalink raw reply
* Re: Official Git Homepage change? Re: git-scm.com
From: Jakub Narebski @ 2008-07-26 15:21 UTC (permalink / raw)
To: Rene Herman; +Cc: Scott Chacon, Junio C Hamano, Petr Baudis, git
In-Reply-To: <488B394F.9000300@keyaccess.nl>
Rene Herman <rene.herman@keyaccess.nl> writes:
> On 26-07-08 09:27, Scott Chacon wrote:
>
> > Perhaps it would be useful to split the mailing list into
> > core/contrib and support lists? I would be happy to help out
> > answering questions - a lot of them come directly to me anyhow
> > because of the gitcasts site and such.
>
> A git-user list would be welcomed at least by me. It remains to be
> seen how useful it would be (and stay) as often the user lists for a
> project dwinddle a bit but I've subcribed and unsubscribed to this
> list a number of times now since unless I've a specific question to
> ask, the list is too busy too just sit around on; I end up deleting
> all list mail unread every night anyway, so I just unsubcribe again.
>
> Maybe a less busy and less implementation focused list could help "me
> and mine" gradually pick up new tips and tricks. Depends ofcourse on
> willingness of some of the more proficient to be involved in that list
> as well...
Well, there _is_ separate Git Users Group at Google Groups
http://groups.google.com/group/git-users
nntp://news.gmane.org/gmane.comp.version-control.git.user
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 7/7] builtin-merge: avoid non-strategy git-merge commands in error message
From: Miklos Vajna @ 2008-07-26 15:25 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <alpine.DEB.1.00.0807261701520.26810@eeepc-johanness>
[-- Attachment #1: Type: text/plain, Size: 2890 bytes --]
On Sat, Jul 26, 2008 at 05:08:11PM +0200, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > + memset(¬_strategies, 0, sizeof(struct cmdnames));
> > + for (i = 0; i < main_cmds.cnt; i++) {
>
> Looking through all the discovered git commands? Cute... But does that
> not exclude the commands that are in PATH, starting with git-merge-, even
> if they are custom strategies?
main_cmds contains only commands in /usr/libexec/git-core, while I guess
custom strategies are elsewhere in PATH, which commands are in
other_cmds, not in main_cmds.
Sample output at me:
$ git merge -s theirss c2
HEAD is now at 1f5e3cc c1
Could not find merge strategy 'theirss'.
available strategies in '/usr/libexec/git-core/'
--------------------------------------------------
octopus ours recursive resolve subtree
strategies available from elsewhere on your $PATH
---------------------------------------------------
theirs
and I have git-merge-theirs in ~/bin (which is in PATH).
>
> > + int j, found = 0;
> > + for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
> > + if (!strcmp(main_cmds.names[i]->name, all_strategy[j].name))
> > + found = 1;
> > + if (!found)
> > + add_cmdname(¬_strategies, main_cmds.names[i]->name, strlen(main_cmds.names[i]->name));
>
> Better have a local variable "name" instead of writing out
> "main_cmds.names[i]->name" all the time...
Fixed.
> Oh, and you assume that the names are NUL-terminated (which I assume is
> not the case in general, as the len member is the only thing that makes
> struct cmdnames different from struct string_list.
I think the purpose of it is different, but the argument is still valie.
That len member is to be able to have ->name contain "foo.exe" while
having len at 3, so that git help -a will avoid the .exe suffixes.
Changed.
(I do not want to resend a full series yet, but I pushed out an amended
patch to repo.or.cz in the 'merge-custom' branch.)
diff --git a/builtin-merge.c b/builtin-merge.c
index 4084e07..b0d1de5 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -93,11 +93,12 @@ static struct strategy *get_strategy(const char *name)
memset(¬_strategies, 0, sizeof(struct cmdnames));
for (i = 0; i < main_cmds.cnt; i++) {
int j, found = 0;
+ char *ent = main_cmds.names[i];
for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
- if (!strcmp(main_cmds.names[i]->name, all_strategy[j].name))
+ if (!strncmp(ent->name, all_strategy[j].name, ent->len))
found = 1;
if (!found)
- add_cmdname(¬_strategies, main_cmds.names[i]->name, strlen(main_cmds.names[i]->name));
+ add_cmdname(¬_strategies, ent->name, ent->len);
}
fprintf(stderr, "Could not find merge strategy '%s'.\n\n", name);
list_commands("git-merge-", "strategies", ¬_strategies);
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply related
* [PATCH 7/7] builtin-merge: avoid non-strategy git-merge commands in error message
From: Miklos Vajna @ 2008-07-26 15:27 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <20080726152502.GL32057@genesis.frugalware.org>
If an invalid strategy is supplied, like -s foobar, then git-merge
listed all git-merge-* commands. This is not perfect, since for example
git-merge-index is not a valid strategy.
These are now removed from the output by scanning the list of main
commands; if the git-merge-foo command is listed in the all_strategy
list, then it's shown, otherwise excluded. This does not exclude
commands somewhere else in the PATH, where custom strategies are
expected.
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
I just realized I can resend the last patch as the others are unchanged,
so here it is.
builtin-merge.c | 14 +++++++++++++-
1 files changed, 13 insertions(+), 1 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index cdbc692..b0d1de5 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -88,8 +88,20 @@ static struct strategy *get_strategy(const char *name)
return &all_strategy[i];
if (!is_git_command(name, "git-merge-")) {
+ struct cmdnames not_strategies;
+
+ memset(¬_strategies, 0, sizeof(struct cmdnames));
+ for (i = 0; i < main_cmds.cnt; i++) {
+ int j, found = 0;
+ char *ent = main_cmds.names[i];
+ for (j = 0; j < ARRAY_SIZE(all_strategy); j++)
+ if (!strncmp(ent->name, all_strategy[j].name, ent->len))
+ found = 1;
+ if (!found)
+ add_cmdname(¬_strategies, ent->name, ent->len);
+ }
fprintf(stderr, "Could not find merge strategy '%s'.\n\n", name);
- list_commands("git-merge-", "strategies");
+ list_commands("git-merge-", "strategies", ¬_strategies);
exit(1);
}
--
1.6.0.rc0.14.g95f8.dirty
^ permalink raw reply related
* Re: Official Git Homepage change? Re: git-scm.com
From: Scott Chacon @ 2008-07-26 15:32 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3d4l0vfgk.fsf@localhost.localdomain>
On Sat, Jul 26, 2008 at 8:21 AM, Jakub Narebski <jnareb@gmail.com> wrote:
> Rene Herman <rene.herman@keyaccess.nl> writes:
>
>> On 26-07-08 09:27, Scott Chacon wrote:
>>
>> > Perhaps it would be useful to split the mailing list into
>> > core/contrib and support lists? I would be happy to help out
>> > answering questions - a lot of them come directly to me anyhow
>> > because of the gitcasts site and such.
>>
>> A git-user list would be welcomed at least by me. It remains to be
>> seen how useful it would be (and stay) as often the user lists for a
>> project dwinddle a bit but I've subcribed and unsubscribed to this
>> list a number of times now since unless I've a specific question to
>> ask, the list is too busy too just sit around on; I end up deleting
>> all list mail unread every night anyway, so I just unsubcribe again.
>>
>> Maybe a less busy and less implementation focused list could help "me
>> and mine" gradually pick up new tips and tricks. Depends ofcourse on
>> willingness of some of the more proficient to be involved in that list
>> as well...
>
> Well, there _is_ separate Git Users Group at Google Groups
> http://groups.google.com/group/git-users
> nntp://news.gmane.org/gmane.comp.version-control.git.user
>
> --
> Jakub Narebski
> Poland
> ShadeHawk on #git
>
Perhaps I should link to that on git-scm as well / instead?
Scott
^ 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