* warning in git version 1.6.6.rc0.114.gc8648
From: Alejandro Riveira @ 2009-12-02 17:21 UTC (permalink / raw)
To: git
Whenever i do a "git pull" to check updates to the kernel
or git repo i recieve
warning: 'git merge <msg> HEAD <commit>' is deprecated. Please update
your script to use 'git merge -m <msg> <commit>' instead.
In future versions of git, this syntax will be removed.
Already up-to-date.
git pull should be updated to not use a deprecated form of git merge.
Regards
^ permalink raw reply
* Re: [BUG?] git-merge appends extra string to user's message?
From: Miklos Vajna @ 2009-12-02 17:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nanako Shiraishi, git
In-Reply-To: <7veindi9pe.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 453 bytes --]
On Wed, Dec 02, 2009 at 09:09:49AM -0800, Junio C Hamano <gitster@pobox.com> wrote:
> I am still in favor, and I think we should do this change. I know Miklos
> said it is intentional, but I think he merely means "The version rewritten
> in C does so intentionally because the version before rewrite did so", not
> necessarily because "the version before rewrite did so intentionally with
> good reasons."
Exactly.
> How does this look?
Looks fine.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 4/8] Support remote helpers implementing smart transports
From: Shawn O. Pearce @ 2009-12-02 17:12 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20091202055543.GC31244@Knoppix>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> On Tue, Dec 01, 2009 at 11:22:33AM -0800, Shawn O. Pearce wrote:
>
> > Why 'OK'? Currently remote-helpers return an empty blank line
> > to any successful command, not 'OK'.
>
> Changed to "" (i.e. blank line) for next round.
Arrrgh. Just to correct myself... the 'option' command uses 'ok',
'error', 'unsupported' as its response messages. Which means
'option' breaks the blank-line-is-ok convention I tried to hold
you to above.
I consider this a mistake on my part. 'option' should respond with
a blank line on success just like 'fetch' or 'push' does.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] builtin-commit: add --date option
From: Miklos Vajna @ 2009-12-02 17:11 UTC (permalink / raw)
To: git
In-Reply-To: <1259627252-21615-1-git-send-email-vmiklos@frugalware.org>
[-- Attachment #1: Type: text/plain, Size: 587 bytes --]
On Tue, Dec 01, 2009 at 01:27:32AM +0100, Miklos Vajna <vmiklos@frugalware.org> wrote:
> +--date=<date>::
> + Override the date used in the commit. The format is the Git
> + native one and is `<time> SP <offutc>`.
I just noticed that fmt_ident() calls parse_date(), so other formats are
supported as well.
Is there any documentation describing what does parse_date() accept?
Based on t0006-date.sh and the comments in the source, I see 3 supported
formats:
1) <unix timestamp> <timezone>
2) A format like 2008-12-02 18:04:00
3) RFC 2822 (Thu, 21 Dec 2000 16:01:07 +0200)
Thanks.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [BUG?] git-merge appends extra string to user's message?
From: Junio C Hamano @ 2009-12-02 17:09 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git, Miklos Vajna
In-Reply-To: <20091202192030.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> When "git merge" is run with a message, it appends an extra message
> that it would add if it were run without one....
>
> I gave my own message because I didn't want git to add the
> standard message (if I wanted to, I wouldn't have given one,
> or I would have prepared it using git-fmt-merge-msg command).
>
> Is it possible to tell git-merge not to do this, or will it
> break compatibility and is a bad idea to change it?
>
> I noticed that this was proposed before:
>
> http://thread.gmane.org/gmane.comp.version-control.git/77965/focus=80059
>
> you were in favor of changing this behavior, and there was no objection
> from the list.
I am still in favor, and I think we should do this change. I know Miklos
said it is intentional, but I think he merely means "The version rewritten
in C does so intentionally because the version before rewrite did so", not
necessarily because "the version before rewrite did so intentionally with
good reasons."
Especially because we are going to update "merge" and eventually drop the
"merge <msg> HEAD <commit>..." syntax, the first step should be to make
it equivalent to "merge -m <msg> <commit..."
How does this look?
I stole a major part of your message to the proposed commit log.
-- >8 --
Subject: [PATCH] merge: do not add standard message when message is given with -m option
Even if the user explicitly gave her own message to "git merge", the
command still added its standard merge message. It resulted in a
useless repetition like this:
% git merge -m "Merge early part of side branch" `git rev-parse side~2`
% git show -s
commit 37217141e7519629353738d5e4e677a15096206f
Merge: e68e646 a1d2374
Author: しらいし ななこ <nanako3@lavabit.com>
Date: Wed Dec 2 14:33:20 2009 +0900
Merge early part of side branch
Merge commit 'a1d2374f8f52f4e8a53171601a920b538a6cec23'
The gave her own message because she didn't want git to add the
standard message (if she wanted to, she wouldn't have given one,
or she would have prepared it using git-fmt-merge-msg command).
Noticed by Nanako Shiraishi
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin-merge.c | 14 ++++++++------
t/t7604-merge-custom-message.sh | 7 ++-----
2 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/builtin-merge.c b/builtin-merge.c
index 2104577..981fe4b 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -71,7 +71,7 @@ static int option_parse_message(const struct option *opt,
if (unset)
strbuf_setlen(buf, 0);
else if (arg) {
- strbuf_addf(buf, "%s\n\n", arg);
+ strbuf_addf(buf, "%s%s", buf->len ? "\n\n" : "", arg);
have_message = 1;
} else
return error("switch `m' requires a value");
@@ -943,11 +943,13 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
* codepath so we discard the error in this
* loop.
*/
- for (i = 0; i < argc; i++)
- merge_name(argv[i], &msg);
- fmt_merge_msg(option_log, &msg, &merge_msg);
- if (merge_msg.len)
- strbuf_setlen(&merge_msg, merge_msg.len-1);
+ if (!have_message) {
+ for (i = 0; i < argc; i++)
+ merge_name(argv[i], &msg);
+ fmt_merge_msg(option_log, &msg, &merge_msg);
+ if (merge_msg.len)
+ strbuf_setlen(&merge_msg, merge_msg.len-1);
+ }
}
if (head_invalid || !argc)
diff --git a/t/t7604-merge-custom-message.sh b/t/t7604-merge-custom-message.sh
index de977c5..269cfdf 100755
--- a/t/t7604-merge-custom-message.sh
+++ b/t/t7604-merge-custom-message.sh
@@ -22,15 +22,12 @@ test_expect_success 'setup' '
git tag c2
'
-cat >expected <<\EOF
-custom message
-Merge commit 'c2'
-EOF
test_expect_success 'merge c2 with a custom message' '
git reset --hard c1 &&
+ echo >expected "custom message" &&
git merge -m "custom message" c2 &&
- git cat-file commit HEAD | sed -e "1,/^$/d" > actual &&
+ git cat-file commit HEAD | sed -e "1,/^$/d" >actual &&
test_cmp expected actual
'
--
1.6.6.rc0
^ permalink raw reply related
* Re: What is the status of merging with whitespace conflicts?
From: Junio C Hamano @ 2009-12-02 17:04 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Git Mailing List
In-Reply-To: <46a038f90912020234g3094cccbxd8ca80c7c0b32ca4@mail.gmail.com>
I am not working on it, and I didn't hear from anybody who is. If you
limit the whitespace-only changes to the ones that do not cross line
boundary, it wouldn't be too hard to add. Probably it would take less
than one summer for a good student.
^ permalink raw reply
* Re: [RFC PATCH 4/8] Support remote helpers implementing smart transports
From: Shawn O. Pearce @ 2009-12-02 17:04 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: git
In-Reply-To: <20091202055543.GC31244@Knoppix>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote:
> On Tue, Dec 01, 2009 at 11:22:33AM -0800, Shawn O. Pearce wrote:
> > Why both connect-r and invoke-r? Why isn't connect-r sufficient
> > here? Isn't it sufficient for any service that runs over git:// ?
>
> Invoke supports those --upload-pack &co (a'la ssh://). connect
> doesn't (a'la to git://).
Drop invoke-r.
Modify transport-helper.c to allow pushing TRANS_OPT_UPLOADPACK and
TRANS_OPT_RECEIVEPACK down into the helper via the option capability.
I'd rename connect-r to just connect.
For the command line:
$ git fetch --upload-pack='/path to my /git-upload-pack' origin
The conversation with the helper will be:
> capabilities
< option
< connect
<
> option uploadpack /path to my /git-upload-pack
< ok
> connect git-upload-pack
<
Which gives the helper the full information it needs to pass along
the --upload-pack command line argument to the remote system.
--
Shawn.
^ permalink raw reply
* Re: Marking commits as transitory for git bisect?
From: Junio C Hamano @ 2009-12-02 16:49 UTC (permalink / raw)
To: David Kastrup; +Cc: Michael J Gruber, git
In-Reply-To: <87tyw9wsfr.fsf@lola.goethe.zz>
David Kastrup <dak@gnu.org> writes:
> Further comments/insights?
Just make sure that you state in the log message of the commits in the
series something like:
- The way the series is split for easier review has to break X and Y
and this commit does not even compile;
- This is the second half of restructuring, and it compiles again;
- Now A is fully restructured, test X works again, but Y is still broken;
- This finally completes the series and everything works again.
for _human consumption_. Bisect is not the only thing that needs to know
about these commits that are intentionally broken. The reviewers and
people who test before accepting the history with these commits in their
history need to know about the known breakages, too.
Because you are talking about breakages that are _known_ when you make the
series, you can afford to follow this recommendation. Object replacement
mechanism is _not_ the answer---it's whole point is that you can add it as
an afterthought by (virtually) squashing the series into one.
This way, the initial reviewers and a person who happened to hit such an
intentionally broken commit during bisect can deal with the situation
exactly the same way. I.e. with "git log".
^ permalink raw reply
* Re: Git GUI client SmartGit released
From: Shawn O. Pearce @ 2009-12-02 16:48 UTC (permalink / raw)
To: Marc Strapetz; +Cc: git
In-Reply-To: <4B161B15.2020106@syntevo.com>
Marc Strapetz <marc.strapetz@syntevo.com> wrote:
> We are proud to announce the general availability of our Git client
> SmartGit[1]:
>
> http://www.syntevo.com/smartgit/index.html
Congrats on your release.
I noticed you use JGit and the Trilead SSH client.
I'm curious, did you guys replace JSch because its a pile of junk?
Did you patch JGit to use Trilead SSH instead of JSch? If so,
would you be interested in contributing that change back to JGit?
I'm rather fed up with JSch... :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH] git-pull.sh: Fix call to git-merge for new command format
From: Junio C Hamano @ 2009-12-02 16:45 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, Horst H. von Brand, git
In-Reply-To: <4B163B49.4070606@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> This made me wonder a bit: Do we have a policy regarding the use of
> "git-command" vs. "git command" in git shell scripts such as this one?
Yes. Anything that sets GIT_EXEC_PATH correctly can use git-foo form.
^ permalink raw reply
* Re: [PATCH] transport-helper: remove duplicate free()
From: Daniel Barkalow @ 2009-12-02 16:23 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Sverre Rabbelier, Junio C Hamano
In-Reply-To: <20091202153950.c18095b7.rctay89@gmail.com>
On Wed, 2 Dec 2009, Tay Ray Chuan wrote:
> Remove the free() invocation on transport->data in release_helper(), as
> disconnect_helper() has already done so.
You need to remove the one in disconnect_helper, because the entire point
of disconnect_helper as opposed to release_helper is to *not* free that
memory. If you remove this one, you'll access freed memory in any case
where the helper has to be quit and restarted.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: non-US-ASCII file names (e.g. Hiragana) on Windows
From: Shawn Pearce @ 2009-12-02 16:22 UTC (permalink / raw)
To: Thomas Singer; +Cc: Jakub Narebski, Johannes Sixt, git
In-Reply-To: <4B15668A.5050209@syntevo.com>
On Tue, Dec 1, 2009 at 10:55 AM, Thomas Singer
<thomas.singer@syntevo.com> wrote:
>
> Jakub Narebski wrote:
> > If you use Git from Java, why don't you just use JGit (www.jgit.org),
> > which is Git implementation in Java?
>
> We are using JGit for the read-only stuff and the Git command line
> executable for all writing commands. We very much appreciate Shawn O.
> Pearce' (and the other JGit developers') effort, but Git is a fast moving
> target and (much) more complex than CVS or SVN, for which we use Java
> libraries communicating with the corresponding server which adds another
> sanity layer to the repository making repository corruption less likely than
> direct access.
Uhm. I'm sorry, but this is just plain FUD.
JGit implements the current on disk formats and network protocols
completely[1]. In the area of disk formats and network protocols, Git
*IS NOT* a fast moving target. This area of Git hasn't changed much
since pack files were first introduced. As a community, we have been
very careful to avoid changes which break compatibility with older
implementations.
Git is also a lot less complex than CVS or SVN. Its data model is
simpler on disk. Its network protocol is *vastly* more simple than
SVN's WebDAV protocol. And unlike SVN we haven't had to break the
network protocol on every 1.x release we make.
[1] Actually, JGit lacks --depth support for shallow clones, but
otherwise is complete.
^ permalink raw reply
* Re: How to update from remote origin with local modified branch?
From: GittyUser @ 2009-12-02 16:20 UTC (permalink / raw)
To: git
In-Reply-To: <4B167925.8080307@drmicha.warpmail.net>
Michael J Gruber-2 wrote:
>
>
> I think you want to read up on workflows with git and decide whether you
> want to rebase or merge. In short, git fetch --all (which is called by
> git pull) will update your remote tracking branches (origin/*), and then
> you can decide what to do with your local branch (probably master): Do
> you merge origin/master into master, or do you rebase master onto
> origin/master?
>
Thnx for your response,
What I want is merge origin/master to local branch master. My mistake is to
have some uncommited files and I guess that's the reason why it's not,
pardon me, it could not be updated. So I try to commit the files, but still
had issues about unmerged files. So as advised I did "git add -f
unmergedfile" and than they were added to the Index. Did finally the commit
and now get the "Already up-to-date" message after a pull command.
Still need to practice a lot to know what is exactly going on.
--
View this message in context: http://n2.nabble.com/How-to-update-from-remote-origin-with-local-modified-branch-tp4099323p4100678.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [RFC PATCH 0/8] Git remote helpers to implement smart transports.
From: Ilari Liusvaara @ 2009-12-02 16:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vy6llnar5.fsf@alter.siamese.dyndns.org>
On Tue, Dec 01, 2009 at 10:35:58PM -0800, Junio C Hamano wrote:
> Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>
> I didn't mean the line count by "large". I was referring to the size of
> change at the conceptual level. As Daniel already explained, it has been
> one of the design assumption so far that there are built-in mappings from
> some common <scheme>:// to backend "helpers".
No implicit mappings from <scheme>:// to helpers existed before this series
(except for forcing in URL, which are different). Thus, any mapping had to
be explicit and built-in.
And if mappings http -> curl, https -> curl, ftp -> curl are to remain explicit
in main git binary, I would put them into table and build stub remote-curl if
NO_CURL is defined instead of special casing the error in main git binary
(but I consider that worse than just removing the association from main
git binary).
>From file system listing on this computer (note the I-node numbers, this is
on newer version of change than the one sent):
2068945 -rwxr-xr-x 4 Ilari users 1547231 2009-12-02 15:12 /home/Ilari/.local/git-testing/libexec/git-core/git-remote-ftp
2068945 -rwxr-xr-x 4 Ilari users 1547231 2009-12-02 15:12 /home/Ilari/.local/git-testing/libexec/git-core/git-remote-ftps
2068945 -rwxr-xr-x 4 Ilari users 1547231 2009-12-02 15:12 /home/Ilari/.local/git-testing/libexec/git-core/git-remote-http
2068945 -rwxr-xr-x 4 Ilari users 1547231 2009-12-02 15:12 /home/Ilari/.local/git-testing/libexec/git-core/git-remote-https
So instead of mapping explicitly, those are effectively mapped by filesystem
(that's after the fixes for next round that make helpers hardlinked instead
of copied).
-Ilari
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC 06/11] run-command: add kill_async() and is_async_alive()
From: Erik Faye-Lund @ 2009-12-02 15:57 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <200911272059.25934.j6t@kdbg.org>
On Fri, Nov 27, 2009 at 8:59 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Freitag, 27. November 2009, Erik Faye-Lund wrote:
>> Do you really think it's better to unconditionally take down the
>> entire process with an error, instead of having a relatively small
>> chance of stuff blowing up without any sensible error? I'm not 100%
>> convinced - but let's hope we'll find a proper fix.
>
> "relatively small chance of stuff blowing up"? The docs of
> TerminateThread: "... the kernel32 state for the thread's process could be
> inconsistent." That's scary if we are talking about a process that should run
> for days or weeks without interruption.
>
I think there's a misunderstanding here. I thought your suggestion was
to simply call die(), which would take down the main process. After
reading this explanation, I think you're talking about giving an error
and rejecting the connection instead. Which makes more sense than to
risk crashing the main-process, indeed.
> The reason why we are killing a thread is to prevent keeping lots of
> connections open (to the same IP address). There are two situations to take
> care of:
>
> 1. We are in a lengthy computation without paying attention to the socket.
>
> 2. The client does not send or accept data for a long time.
>
> Case 1 could happen if upload-pack is "counting objects" on a large
> repository. We would need some way to kill upload-pack. Since it is a
> separate process anyway, we could use TerminateProcess().
>
Makes sense. I'll play around a bit with this and see what I come up with.
> Case 2 could be achieved by using setsockopt() with SO_RCVTIMEO and
> SO_SNDTIMEO and a tiny timeout. But notice that we would set a timeout in one
> thread while another thread is waiting in ReadFile() or WriteFile(). Would
> that work?
>
I think it should work fine, but I won't give you a guarantee ;)
Perhaps we should have a configurable global max timeout, and just set
that on all sockets? Or does this open for DDOS attacks?
Anyway, thanks for the sanity :)
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [BUG?] git-merge appends extra string to user's message?
From: Miklos Vajna @ 2009-12-02 15:54 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git
In-Reply-To: <20091202192030.6117@nanako3.lavabit.com>
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
On Wed, Dec 02, 2009 at 07:20:30PM +0900, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> % git merge -m "Merge early part of side branch" `git rev-parse side~2`
> % git show -s
> commit 37217141e7519629353738d5e4e677a15096206f
> Merge: e68e646 a1d2374
> Author: ???????????? ????????? <nanako3@lavabit.com>
> Date: Wed Dec 2 14:33:20 2009 +0900
>
> Merge early part of side branch
>
> Merge commit 'a1d2374f8f52f4e8a53171601a920b538a6cec23'
At least it's intentional. When I wrote builtin-merge I remember I
checked that the script version had this behaviour and that's why I
implemented the same way in C.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [msysGit] [PATCH/RFC 09/11] daemon: use run-command api for async serving
From: Erik Faye-Lund @ 2009-12-02 15:45 UTC (permalink / raw)
To: Johannes Sixt; +Cc: msysgit, git, dotzenlabs
In-Reply-To: <200911272159.38757.j6t@kdbg.org>
On Fri, Nov 27, 2009 at 9:59 PM, Johannes Sixt <j6t@kdbg.org> wrote:
> On Donnerstag, 26. November 2009, Erik Faye-Lund wrote:
>> static void check_dead_children(void)
>> {
>> - int status;
>> - pid_t pid;
>> -
>> - while ((pid = waitpid(-1, &status, WNOHANG)) > 0) {
>> - const char *dead = "";
>> - remove_child(pid);
>> - if (!WIFEXITED(status) || (WEXITSTATUS(status) > 0))
>> - dead = " (with error)";
>> - loginfo("[%"PRIuMAX"] Disconnected%s", (uintmax_t)pid, dead);
>> - }
>> + struct child **cradle, *blanket;
>> + for (cradle = &firstborn; (blanket = *cradle);)
>> + if (!is_async_alive(&blanket->async)) {
>
> This would be the right place to call finish_async(). But since we cannot
> wait, you invented is_async_alive(). But actually we are not only interested
> in whether the process is alive, but also whether it completed successfully
> so that we can add "(with error)". Would it make sense to have a function
> finish_async_nowait() instead of is_async_alive() that (1) stresses the
> start/finish symmetry and (2) can return more than just Boolean?
>
Yes, it does.
>> + *cradle = blanket->next;
>> + loginfo("Disconnected\n");
>
> Here you are losing information about the pid, which is important to have in
> the syslog. The \n should be dropped.
>
Yeah... I removed the pid mostly because after moving to async, there
wasn't "just a pid" any more. But if we make finish_async_nowait()
return whatever we need to report, I guess we can add the information
back somehow.
I'm not entirely sure how to make the interface, though. Any good suggestions?
>> + async.proc = async_execute;
>> + async.data = ss;
>> + async.out = incoming;
>>
>> - dup2(incoming, 0);
>> - dup2(incoming, 1);
>> + if (start_async(&async))
>> + logerror("unable to fork");
>> + else
>> + add_child(&async, addr, addrlen);
>> close(incoming);
>> -
>> - exit(execute(0, addr));
>
> In start_command(), the convention is that fds that are provided by the caller
> are closed by start_command() (even if there are errors). The close(incoming)
> that you leave here indicates that you are not using the same convention with
> start_async(). It would be nice to switch to the same convention.
>
Yeah, I've fixed this for the next round.
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Marking commits as transitory for git bisect?
From: David Kastrup @ 2009-12-02 11:01 UTC (permalink / raw)
To: Michael J Gruber; +Cc: git
In-Reply-To: <4B164501.7010902@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> David Kastrup venit, vidit, dixit 02.12.2009 10:32:
>>
>> sometimes there are changes which would seem better to restructure into
>> more than one commit, with a non-operative intermediate state.
>>
>> What I am thinking of is something like
>>
>> a) change an API (small but highly intricate patch warranting thorough
>> line-by-line review to make sure it's fine)
>> b) adapt all existing callers (really large but utterly trivial patch)
>
> A quick solution with current git would be "replace": Say, in
> A-B-C-D
> you want B and C to be considered an "atom" for bisection. So, "git
> replace" C by a commit C' which is B+C squashed and has A as its parent:
> A-C'-D.
That would lose B and C. The idea was to have this available
publically.
> Alternatively, if you want this to be distributed more easily and think
> of it at the time of committing, producing a DAG like
>
> A--C'--D
> \ /
> B--C
>
> with C' as the first parent of D may help during bisection. I.e., you
> keep the detailed history on the side branch and squash it together on
> the --first-parent-line, with C,C' being tree-same.
That would seem to be more or less accomplished by putting B-C on a
side-branch, then merge that branch into A (C' basically being the merge
commit). So the DAG would be something like
A------D
\ /
B--C
If B-C is a local branch, will their history make it through to a remote
repository when you push D?
It seems like this workflow could possibly meet my criteria when one has
push access to the repo in question. If one passes D upstream via
git-format-patch, however, it would appear that just the equivalent of
C' makes it upstream, with the B-C history staying local.
Not sure what will happen when upstream pulls D.
Further comments/insights?
--
David Kastrup
^ permalink raw reply
* Re: [PATCH/RFC 01/11] mingw: add network-wrappers for daemon
From: Erik Faye-Lund @ 2009-12-02 15:11 UTC (permalink / raw)
To: Martin Storsjö; +Cc: msysgit, git, dotzenlabs, Johannes Sixt
In-Reply-To: <40aa078e0912020549s792eb3ffi93b2cfdc6b7219dd@mail.gmail.com>
On Wed, Dec 2, 2009 at 2:49 PM, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
> On Wed, Dec 2, 2009 at 2:21 PM, Martin Storsjö <martin@martin.st> wrote:
>> On Wed, 2 Dec 2009, Erik Faye-Lund wrote:
>>> @@ -854,6 +850,7 @@ static int service_loop(int socknum, int *socklist)
>>> }
>>> }
>>> handle(incoming, (struct sockaddr *)&ss, sslen);
>>>
>>> + break;
>>
>> What's this good for?
>>
>
> When I clone git://localhost/some-repo, select() returns a fd-set with
> both the IPv4 and IPv6 fds. After accept()'ing the first one, the
> second call to accept() hangs. I solved this by accepting only the
> first connection I got; the second one should be accepted in the next
> round of the service loop (if still available).
>
Actually, it's no good - my code is broken. FD_SET() and FD_ISSET()
needs wrapping to call _get_osfhandle() on the socket. Since this is
not needed on Linux, the code ran just fine there. But on Windows,
select() failed, but due to the following bug, it wasn't picked up:
+ if (select(0, &fds, NULL, NULL, &timeout) > 0) {
changing the comparison around, revealed that select hadn't done
anything so fds wasn't modified at all! Thus, I wrongly interpreted it
as if both sockets had an awaiting connection, making IPv6 connections
work (since they are on the first socket), but IPv4 not.
I've corrected this locally, and I'll include the fixed patch in the next round.
Thanks for pointing out the issue, causing me to second guess my "cure" :)
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: How to update from remote origin with local modified branch?
From: Michael J Gruber @ 2009-12-02 14:26 UTC (permalink / raw)
To: GittyUser; +Cc: git
In-Reply-To: <1259752954810-4099323.post@n2.nabble.com>
GittyUser venit, vidit, dixit 02.12.2009 12:22:
>
> I have once cloned a a project from a remote repository:
> git cloned http://repo.or.cz/r/openbsc.git
>
> After that I modified some files and commited.
> In the mean time the remote repository had several commits. Now I want to
> update my local repo from the remote repo but I also want to keep my own
> commits. So, when doing "git pull" I get the message that certain files
> needs to be updated.
>
> Now, how can I get my local repo, with my own modification, updated by the
> remote repo?
> I know I need to be aware that those updates (or commits) from remote must
> not conflict with my local.
>
> Thank you.
I think you want to read up on workflows with git and decide whether you
want to rebase or merge. In short, git fetch --all (which is called by
git pull) will update your remote tracking branches (origin/*), and then
you can decide what to do with your local branch (probably master): Do
you merge origin/master into master, or do you rebase master onto
origin/master?
Michael
^ permalink raw reply
* Re: [egit] Git repository with multiple eclipse projects ?
From: Yann Dirson @ 2009-12-02 14:24 UTC (permalink / raw)
To: Robin Rosenberg; +Cc: git, egit-dev
In-Reply-To: <200911252227.40235.robin.rosenberg@dewire.com>
On Wed, Nov 25, 2009 at 10:27:39PM +0100, Robin Rosenberg wrote:
> onsdag 25 november 2009 17:47:34 skrev Yann Dirson:
> > I am investigating whether it is possible at all to have several
> > eclipse projects in a single git repo, and have those projects
> > correctly seen as managed by git.
> >
> > When importing a git repo into eclipse, we get a list of projects to
> > import, but that list is empty. What is expected by egit to get this
> > list filled ?
>
> Both Egit and Jgit themselves have multiple projects in the same repo.
> All projects must be located in the same directory structure.
>
> repo/.git
> |`--project1/.git
> |`--project2
>
> etc
> Other variations are possible.
You seem to talk about nested git repo here. Do you mean using
submodules (I thought jgit did not support them yet) ? git-subtree ?
> >
> > It also does not look like it would be possible to use the "share"
> > functionnality to setup such a repository from multiple projects (or
> > from a project set), right ?
>
> Share only tells Eclipse to attach EGit as the team provider, provided
> it is located in a git repo, or lets you create a repo if none exists.
Looks like there is a possibly-windows-specific issue here.
The test repo is a git repo with a couple of eclipse projects just
beneath the top-level. It can be checked-out from both Ubuntu
(Karmic) and Windows (Vista), and in both cases the projects can be
attached to the team provider from the "import" wizard.
On an Ubuntu box, I could use "team/disconnect", and then "share" to
attach to "../.git", it worked like a charm. On the windows box
however, reconnecting was not possible: the "../.git" line is not
selectable. Note that it does read "../.git" and not "..\.git".
Note that on my "mostly squeeze" Debian box, the import would succeed,
but in that case none of the projects were attached to the team
provider. If afterwards I try to connect it, it silently does nothing.
In that case it may be a known bug: I have a ~/.git dir that is also
seen by jgit, and which I am also proposed in the "share" dialog. If
I move it away, the request to attach is successful.
Best regards,
--
Yann
^ permalink raw reply
* Re: [PATCH/RFC 01/11] mingw: add network-wrappers for daemon
From: Erik Faye-Lund @ 2009-12-02 13:49 UTC (permalink / raw)
To: Martin Storsjö; +Cc: msysgit, git, dotzenlabs, Johannes Sixt
In-Reply-To: <alpine.DEB.2.00.0912021511310.5582@cone.home.martin.st>
On Wed, Dec 2, 2009 at 2:21 PM, Martin Storsjö <martin@martin.st> wrote:
> On Wed, 2 Dec 2009, Erik Faye-Lund wrote:
>
>> I'm not very familiar with poll(), but if I understand the man-pages
>> correctly it's waiting for events on file descriptors, and is in our
>> case used to check for incoming connections, right? If so, I see three
>> possible ways forward: (1) extending our poll()-emulation to handle
>> multiple sockets, (2) change daemon.c to check one socket at the time,
>> and (3) using select() instead of poll().
>>
>> (1) seems like the "correct" but tricky thing to do, (2) like the
>> "easy" but nasty thing to do. However, (3) strikes me as the least
>> dangerous thing to do ;)
>
> Generally, poll is a better API than select, since select is limited to fd
> values up to (about) 1000, depending on the implementation. (This is due
> to the fact that fd_set is a fixed size bit set with a bit for each
> possible fd.)
>
> But since we're only doing select on the handful of sockets that were
> opened initially in the process (so these should receive low numbers),
> this should only be a theoretical concern.
>
Yeah. In our case, I guess it's a maximum of two times the number of
network adapters installed, so I think we should be relatively safe.
>
>> --->8---
>> --- a/daemon.c
>> +++ b/daemon.c
>> @@ -812,26 +812,22 @@ static int socksetup(char *listen_addr, int listen_port, i
>> nt **socklist_p)
>>
>> static int service_loop(int socknum, int *socklist)
>> {
>> - struct pollfd *pfd;
>> - int i;
>> -
>> - pfd = xcalloc(socknum, sizeof(struct pollfd));
>> -
>> - for (i = 0; i < socknum; i++) {
>> - pfd[i].fd = socklist[i];
>> - pfd[i].events = POLLIN;
>> - }
>> -
>> signal(SIGCHLD, child_handler);
>>
>> for (;;) {
>> int i;
>> + fd_set fds;
>> + struct timeval timeout = { 0, 0 };
>>
>> check_dead_children();
>>
>> - if (poll(pfd, socknum, -1) < 0) {
>> + FD_ZERO(&fds);
>> + for (i = 0; i < socknum; i++)
>> + FD_SET(socklist[i], &fds);
>> +
>> + if (select(0, &fds, NULL, NULL, &timeout) > 0) {
>> if (errno != EINTR) {
>
> The first parameter to select should be max(all fds set in the fd_set) +
> 1, this should be trivial enough to determine in the loop above where the
> fd:s are added with FD_SET.
>
Yeah, thanks for pointing out. I did a little bit of searching, and it
seems like "most other people passes zero, and it just works".
However, we should be nice to systems where it doesn't "just work", so
I'll fix this before sending it out.
> You're calling select() with a zero timeout - I'd guess this chews quite a
> bit of cpu just looping around doing nothing? If the last parameter would
> be set to NULL, it would wait indefinitely, just like the previous poll
> loop did.
>
Ah, yes. That's much nicer!
>> @@ -854,6 +850,7 @@ static int service_loop(int socknum, int *socklist)
>> }
>> }
>> handle(incoming, (struct sockaddr *)&ss, sslen);
>>
>> + break;
>
> What's this good for?
>
When I clone git://localhost/some-repo, select() returns a fd-set with
both the IPv4 and IPv6 fds. After accept()'ing the first one, the
second call to accept() hangs. I solved this by accepting only the
first connection I got; the second one should be accepted in the next
round of the service loop (if still available).
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: [PATCH/RFC 01/11] mingw: add network-wrappers for daemon
From: Martin Storsjö @ 2009-12-02 13:21 UTC (permalink / raw)
To: kusmabite; +Cc: msysgit, git, dotzenlabs, Johannes Sixt
In-Reply-To: <40aa078e0912020501v9378c37l106e1e23b5e7b43d@mail.gmail.com>
On Wed, 2 Dec 2009, Erik Faye-Lund wrote:
> I'm not very familiar with poll(), but if I understand the man-pages
> correctly it's waiting for events on file descriptors, and is in our
> case used to check for incoming connections, right? If so, I see three
> possible ways forward: (1) extending our poll()-emulation to handle
> multiple sockets, (2) change daemon.c to check one socket at the time,
> and (3) using select() instead of poll().
>
> (1) seems like the "correct" but tricky thing to do, (2) like the
> "easy" but nasty thing to do. However, (3) strikes me as the least
> dangerous thing to do ;)
Generally, poll is a better API than select, since select is limited to fd
values up to (about) 1000, depending on the implementation. (This is due
to the fact that fd_set is a fixed size bit set with a bit for each
possible fd.)
But since we're only doing select on the handful of sockets that were
opened initially in the process (so these should receive low numbers),
this should only be a theoretical concern.
> For (1), there's also a WSAPoll() function in Windows, but I'm not
> sure how to figure out if an fd is a socket or a pipe. There's also
> WaitForMultipleObjects.
>
> Here's a quick stab at (3). It seems to work fine under Windows. Not
> tested on other platforms, though.
A few comments below, just by reading through this, didn't test it yet:
> --->8---
> --- a/daemon.c
> +++ b/daemon.c
> @@ -812,26 +812,22 @@ static int socksetup(char *listen_addr, int listen_port, i
> nt **socklist_p)
>
> static int service_loop(int socknum, int *socklist)
> {
> - struct pollfd *pfd;
> - int i;
> -
> - pfd = xcalloc(socknum, sizeof(struct pollfd));
> -
> - for (i = 0; i < socknum; i++) {
> - pfd[i].fd = socklist[i];
> - pfd[i].events = POLLIN;
> - }
> -
> signal(SIGCHLD, child_handler);
>
> for (;;) {
> int i;
> + fd_set fds;
> + struct timeval timeout = { 0, 0 };
>
> check_dead_children();
>
> - if (poll(pfd, socknum, -1) < 0) {
> + FD_ZERO(&fds);
> + for (i = 0; i < socknum; i++)
> + FD_SET(socklist[i], &fds);
> +
> + if (select(0, &fds, NULL, NULL, &timeout) > 0) {
> if (errno != EINTR) {
The first parameter to select should be max(all fds set in the fd_set) +
1, this should be trivial enough to determine in the loop above where the
fd:s are added with FD_SET.
You're calling select() with a zero timeout - I'd guess this chews quite a
bit of cpu just looping around doing nothing? If the last parameter would
be set to NULL, it would wait indefinitely, just like the previous poll
loop did.
> @@ -854,6 +850,7 @@ static int service_loop(int socknum, int *socklist)
> }
> }
> handle(incoming, (struct sockaddr *)&ss, sslen);
>
> + break;
What's this good for?
Other than that, this looks quite good to me, at a first glance.
// Martin
^ permalink raw reply
* Re: [PATCH/RFC 01/11] mingw: add network-wrappers for daemon
From: Erik Faye-Lund @ 2009-12-02 13:01 UTC (permalink / raw)
To: Martin Storsjö; +Cc: msysgit, git, dotzenlabs, Johannes Sixt
In-Reply-To: <alpine.DEB.2.00.0911261250180.14228@cone.home.martin.st>
(CC'ing Hannes, as he seems to be the original author of our poll()-emulation)
On Thu, Nov 26, 2009 at 12:03 PM, Martin Storsjö <martin@martin.st> wrote:
> On Thu, 26 Nov 2009, Erik Faye-Lund wrote:
>
>> Yeah, I saw your patches, and realized that I needed to rebase my work
>> at some point, but none of the repos I usually pull from seems to
>> contain the patches yet. Rebasing will be a requirement before this
>> can be applied for sure.
>
> Ok, great! I tried applying it on the latest master, and it wasn't too
> much of work.
I've finally gotten around to doing the same now, thanks for the heads up :)
> This causes problems with the mingw poll() replacement, which has a
> special case for polling one single fd - otherwise it tries to use some
> emulation that currently only works for pipes. I didn't try to make any
> proper fix for this though. I tested git-daemon by hacking it to listen on
> only one of the sockets, and that worked well for both v4 and v6.
>
>
> So, in addition to the getaddrinfo patch I sent, the mingw poll()
> replacement needs some updates to handle polling multiple sockets. Except
> from that, things seem to work, at a quick glance.
>
Thanks a lot for helping out! I'm seeing the same issue here when
running on Vista:
$ ./git-daemon.exe --base-path=/c/Users/Erik/src/ --export-all
error: PeekNamedPipe failed, GetLastError: 1
[3656] Poll failed, resuming: Invalid argument
error: PeekNamedPipe failed, GetLastError: 1
[3656] Poll failed, resuming: Invalid argument
...
If I hack the poll()-emulation to never enter the PeekNamedPipe
code-path seems to make it work with IPv6 here, but this is obviously
not the correct solution as it breaks pipe-polling:
--->8---
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -360,7 +360,7 @@ int poll(struct pollfd *ufds, unsigned int nfds, int timeout
* input is available and let the actual wait happen when the
* caller invokes read().
*/
- if (nfds == 1) {
+ if (1) {
if (!(ufds[0].events & POLLIN))
return errno = EINVAL, error("POLLIN not set");
ufds[0].revents = POLLIN;
--->8---
I'm not very familiar with poll(), but if I understand the man-pages
correctly it's waiting for events on file descriptors, and is in our
case used to check for incoming connections, right? If so, I see three
possible ways forward: (1) extending our poll()-emulation to handle
multiple sockets, (2) change daemon.c to check one socket at the time,
and (3) using select() instead of poll().
(1) seems like the "correct" but tricky thing to do, (2) like the
"easy" but nasty thing to do. However, (3) strikes me as the least
dangerous thing to do ;)
For (1), there's also a WSAPoll() function in Windows, but I'm not
sure how to figure out if an fd is a socket or a pipe. There's also
WaitForMultipleObjects.
Here's a quick stab at (3). It seems to work fine under Windows. Not
tested on other platforms, though.
--->8---
--- a/daemon.c
+++ b/daemon.c
@@ -812,26 +812,22 @@ static int socksetup(char *listen_addr, int listen_port, i
nt **socklist_p)
static int service_loop(int socknum, int *socklist)
{
- struct pollfd *pfd;
- int i;
-
- pfd = xcalloc(socknum, sizeof(struct pollfd));
-
- for (i = 0; i < socknum; i++) {
- pfd[i].fd = socklist[i];
- pfd[i].events = POLLIN;
- }
-
signal(SIGCHLD, child_handler);
for (;;) {
int i;
+ fd_set fds;
+ struct timeval timeout = { 0, 0 };
check_dead_children();
- if (poll(pfd, socknum, -1) < 0) {
+ FD_ZERO(&fds);
+ for (i = 0; i < socknum; i++)
+ FD_SET(socklist[i], &fds);
+
+ if (select(0, &fds, NULL, NULL, &timeout) > 0) {
if (errno != EINTR) {
- logerror("Poll failed, resuming: %s",
+ logerror("select() failed, resuming: %s",
strerror(errno));
sleep(1);
}
@@ -839,10 +835,10 @@ static int service_loop(int socknum, int *socklist)
}
for (i = 0; i < socknum; i++) {
- if (pfd[i].revents & POLLIN) {
+ if (FD_ISSET(socklist[i], &fds)) {
struct sockaddr_storage ss;
socklen_t sslen = sizeof(ss);
- int incoming = accept(pfd[i].fd,
(struct sockaddr *)&ss, &sslen);
+ int incoming = accept(socklist[i],
(struct sockaddr *)&ss, &sslen);
if (incoming < 0) {
switch (errno) {
case EAGAIN:
@@ -854,6 +850,7 @@ static int service_loop(int socknum, int *socklist)
}
}
handle(incoming, (struct sockaddr *)&ss, sslen);
+ break;
}
}
}
--->8---
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: choosing an issue tracker
From: Bill Lear @ 2009-12-02 11:54 UTC (permalink / raw)
To: Rakotomandimby Mihamina; +Cc: git
In-Reply-To: <4B16331A.3060606@gulfsat.mg>
On Wednesday, December 2, 2009 at 12:27:54 (+0300) Rakotomandimby Mihamina writes:
>Hi all,
>
>For a while, I used SVN and Trac.
>They have a satisfying mutual integration.
>
>I am looking for our new issue tracker, and would like to be advised.
>
>Our context:
>- developpers using git, developping
> - web based applications (PHP, Python, OCaml,...)
> - Unix-like system maintainance scripts (SHELL, Perl,...)
>- a QA guy that makes functional tests only on the web applications
> and reports bugs and potential improvements. He does not use git.
>- multiple projects
>
>What we look for:
>something like the (Trac, SVN) but with git as SCM.
>
>What issue tracker would you recommend?
You might be interested in Jira, which I have tied to git with my
open-source niftyism:
http://github.com/rael/git-jira
Bill
^ 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