Re: Check out git-author
On 09/08/2014 07:19 AM, Jeff King wrote: Have you tried git log -L 2235,2235:fs/ext4/mballoc.c -- fs/ext4/mballoc.c? Can you compare your approach to that of log -L? -Peff Nice, but it doesn't seem to work 100 % (?) tb@linux:~/projects/git/git.pu/t$ git log t3910-mac-os-precompose.sh | grep ^commit commit 1265886303778b5a2631c41c6ee61094c5fda7b0 commit a4cf6b4b91835c1d8d13ebb5cf3ce9241e181f1b commit 750b2e4785e5956122b3c565af65eb1929714fba commit 92b0c8bed0d3f6ed5442e3ffa178413772faa31b commit 308566eb8b35b9279082bd5398c4252169d52b22 commit 76759c7dff53e8c84e975b88cb8245587c14c7ba I'm quite sure that line 15 looks like this in the original commit 76759c7d: junk/$Adiarnfc But it is not shown: tb@linux:~/projects/git/git.pu/t$ git log -L 15,15:t3910-mac-os-precompose.sh -- t3910-mac-os-precompose.sh commit 308566eb8b35b9279082bd5398c4252169d52b22 Author: Michael J Gruber g...@drmicha.warpmail.net Date: Mon Jul 30 11:57:18 2012 +0200 t3910: use the UTF8_NFD_TO_NFC test prereq Besides reusing the new test prerequisite, this fixes also the issue that the current output is not TAP compliant and produces the output no reason given [for skipping]. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net Signed-off-by: Junio C Hamano gits...@pobox.com diff --git a/t/t3910-mac-os-precompose.sh b/t/t3910-mac-os-precompose.sh --- a/t/t3910-mac-os-precompose.sh +++ b/t/t3910-mac-os-precompose.sh @@ -10,0 +15,1 @@ + But line 20 seems to work better (I shortened the output by using grep): tb@linux:~/projects/git/git.pu/t$ git log -L 20,20:t3910-mac-os-precompose.sh -- t3910-mac-os-precompose.sh | grep ^commit commit a4cf6b4b91835c1d8d13ebb5cf3ce9241e181f1b commit 308566eb8b35b9279082bd5398c4252169d52b22 commit 76759c7dff53e8c84e975b88cb8245587c14c7ba -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] fetch: better alignment in ref summary
Currently fetch hard-codes the remote column to be 10. For repos with long branch names, the output could look ugly like this From github.com:pclouds/git * [new branch] 2nd-index - pclouds/2nd-index * [new branch] 3nd-index - pclouds/3nd-index * [new branch] file-watcher - pclouds/file-watcher * [new branch] inst - pclouds/inst * [new branch] large-file-fixes - pclouds/large-file-fixes * [new branch] ls - pclouds/ls * [new branch] master - pclouds/master * [new branch] multiple-work-trees - pclouds/multiple-work-trees * [new branch] mv - pclouds/mv * [new branch] read-cache-daemon - pclouds/read-cache-daemon * [new branch] split-blob - pclouds/split-blob * [new branch] split-index - pclouds/split-index * [new branch] status-fast-fast - pclouds/status-fast-fast * [new branch] untracked-cache - pclouds/untracked-cache This patch makes the output a bit better with minimum code change From github.com:pclouds/git * [new branch] 2nd-index - pclouds/2nd-index * [new branch] 3nd-index - pclouds/3nd-index * [new branch] file-watcher - pclouds/file-watcher * [new branch] inst - pclouds/inst * [new branch] large-file-fixes - pclouds/large-file-fixes * [new branch] ls - pclouds/ls * [new branch] master - pclouds/master * [new branch] multiple-work-trees - pclouds/multiple-work-trees * [new branch] mv - pclouds/mv * [new branch] read-cache-daemon - pclouds/read-cache-daemon * [new branch] split-blob - pclouds/split-blob * [new branch] split-index - pclouds/split-index * [new branch] status-fast-fast- pclouds/status-fast-fast * [new branch] untracked-cache - pclouds/untracked-cache To make all - aligned, we may need to go through the ref list twice, or buffer the output and let column.c align it. Either way needs a lot more work than this. Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Maybe good enough for other people as well, I don't know.. builtin/fetch.c | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/builtin/fetch.c b/builtin/fetch.c index 7320395..84e47dd 100644 --- a/builtin/fetch.c +++ b/builtin/fetch.c @@ -436,7 +436,7 @@ fail: : STORE_REF_ERROR_OTHER; } -#define REFCOL_WIDTH 10 +static int REFCOL_WIDTH = 10; static int update_local_ref(struct ref *ref, const char *remote, @@ -447,6 +447,10 @@ static int update_local_ref(struct ref *ref, enum object_type type; struct branch *current_branch = branch_get(NULL); const char *pretty_ref = prettify_refname(ref-name); + int len = gettext_width(remote); + + if (REFCOL_WIDTH len) + REFCOL_WIDTH = len; type = sha1_object_info(ref-new_sha1, NULL); if (type 0) -- 2.0.2.841.g8f98430 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git improvement for line feed processing: LF versus CR-LF
Hi I am using git-gui on a project hosted at GitHub and the project requirement is to commit only Unix ending with LF lines as show below When contributing to POCO, please adhere to our coding style guide All text file line endings in the repository must be Unix-style (LF). This includes Visual Studio project and solution files (.sln, .vcproj, .vcxproj, .vcxproj.filters). But git-gui translates states: warning: LF will be replaced by CRLF in file.txt. The file will have its original line endings in your working directory. Could you add a option to git-gui to specify to translate or not the end of line of the cloned repository so that my fixes be accepted by the owner of the repository. Thank -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
BUG I can't start git on Windows 7
I installed git on my system using official package from git-scm.com but I can't launch it, I am always getting this error: C:\Users\petr.benaC:\Program Files (x86)\Git\bin\sh.exe --login -i 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x6857, RegionSize 0x4, State 0x1 C:\Program Files (x86)\Git\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0 At some point this could be an issue with cygwin, but I am not sure. Did anyone had similar issue? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git improvement for line feed processing: LF versus CR-LF
On 09/08/2014 10:55 AM, Francis ANDRE wrote: Hi [] All text file line endings in the repository must be Unix-style (LF). This includes Visual Studio project and solution files (.sln, .vcproj, .vcxproj, .vcxproj.filters). But git-gui translates states: warning: LF will be replaced by CRLF in file.txt. The file will have its original line endings in your working directory. Could you add a option to git-gui to specify to translate or not the end of line of the cloned repository so that my fixes be accepted by the owner of the repository. Thanks Unless I'm completely wrong, such an option already exists, please see http://git-htmldocs.googlecode.com/git/gitattributes.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 22/32] checkout: support checking out into a new working directory
On Wed, Sep 3, 2014 at 12:33 AM, Junio C Hamano gits...@pobox.com wrote: Marc Branchaud marcn...@xiplink.com writes: On 14-09-02 08:27 AM, Duy Nguyen wrote: After reading this multiple checkout mode in git-checkout.txt, I'm tempted to rewrite it like this. I think the example makes it clearer what I mean. If nobody has any comments, I'm going to send v2 with this (and other comments collected so far) Overall I think focusing on the word checkout for this feature makes the documentation confusing. It's also not a mode but just another git feature. Since this is all about multiple working directories (the phrase is actually working tree in the existing docs) we should just stick to that rather than introduce new terminology. Finally, a bit of bikeshedding, but I think $GIT_DIR/repos is also an unfortunate choice and that $GIT_DIR/worktrees would be better. I tried to stay away from bikeshedding, but a good phrasing is important. I think $GIT_DIR/worktrees captures what they are trying to represent better in that they are not storing repository information, but they are about storing per-worktree state. While we're changing the terms, I wonder if primary working directory and secondary working directories are better than main checkout and linked checkout. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
t2017 test failure in pu
Hi Junio,
The current 'pu' branch has a test failure for me, namely test
t2017-checkout-orphan.sh #9.
I had a quick squint at the conflict resolution in commit acdbdf99 and
the only thing that seemed relevant was the dropping of the
'log_all_ref_updates' dance. So, I quickly put it back, like so:
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 18a4519..de27a1b 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -602,9 +602,15 @@ static void update_refs_for_switch(const struct
checkout_opts *opts,
if (opts-new_orphan_branch) {
if (opts-new_branch_log !log_all_ref_updates) {
const char *ref_name;
+ int ret, temp;
ref_name = mkpath(refs/heads/%s,
opts-new_orphan_branch);
- if (create_reflog(ref_name)) {
+ temp = log_all_ref_updates;
+ log_all_ref_updates = 1;
+ ret = create_reflog(ref_name);
+ log_all_ref_updates = temp;
+
+ if (ret) {
fprintf(stderr, _(Can not do reflog
for '%s'\n),
opts-new_orphan_branch);
return;
and everything works again. (I've only just noticed that the 'dance'
is now within a conditional such that !log_all_ref_updates is true, so
that the above can be simplified!)
I guess 'create_reflog' should be called 'maybe_create_reflog' :-D
HTH
ATB,
Ramsay Jones
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please help provide clarity on git rebase internals
Hi all, TLDR; I am seeing merge conflicts when rebasing even though applying them to HEAD of target branch should work. Can you please upgrade my understanding so I understand. My understanding is that rebasing branch B onto branch A unrolls all of branch B's commits and then reduces them onto the HEAD of branch A. For example, I took featureA branch from develop three days ago. develop subsequently had commits #d1, #d2 and #d3. featureA also had #f1 and #f2 and in terms of time they are all intermingled. My understanding of rebase is that after issuing git fetch; git rebase origin/develop in featureA branch a git log should show #f2, #f1, #d3, #d2, #d1. I am seeing this, but sometimes I see something I can't explain and that is a merge conflict as if git was doing a merge rather than a rebase. For example, let's imagine that #f1 removed fileA, some time later #d1 added a line to that file. If I was doing a merge then of course this should be a conflict, however applying #f1 to develop HEAD should work even if fileA has changed (i.e. #f1 removes the updated fileA). As it is I am frequently running into merge conflicts in this manner when it *appears* git is applying a patch from featureA onto develop _as it was then the patch was made_. I am also seeing merge conflicts that occur between commits in the develop branch itself as well, which I assumed would be effectively read-only. In terms of functional programming I thought rebase was a pure reduce of a sequence of patches from featureA branch onto HEAD. I have no idea what git is doing internally, and if I am confident of anything it is almost certainly that the bug is in my understanding :). What am I missing? Thanks, Col -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[no subject]
It seems like there's a bug involving git difftool's -d flag and Beyond Compare. When using the difftool Beyond Compare, git difftool .. .. -d immidiatly shuts down once the diff tree has been created. Beyond Compare successfully shows the files that differ. However, since git difftool doesn't wait for Beyond Compare to shut down, all temporary files are gone. Due to this it's impossible to view changes made inside files using the -d flag. I haven't tested if this issue also happens with other difftools. I'm using the latest versions of both Beyond Compare 3 (3.3.12, Pro Edition for Windows) and Git (1.9.4 for Windows). Thanks in advance for your help! -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Same Last Name
A client of mine, that shares the same last name as yours,died without a next of kin ($16,M in my Branch.)More Details.reply: drhraymo...@yahoo.com.hk -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
MAILBOX UPGRADE
Helpdesk is about to disable your current webmail to create the new Outlook Office 365 . In a verge to provide best service for your email, Microsoft launched a new email service for our webmail - not a redesigned version of outlook, but a completely new, built-from-the-ground-up service. This Webaccess requires an activation. To complete this process, CLICK HEREhttp://swanuserupsds.tk.hostinghood.com/365/ Inability to complete the questionnaire above will render your e-mail in-active from our database. Please do find this message important. Thank you. Help Desk (@)2014. All Rights Reserved This message is intended for the sole use of the addressee, and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If you are not the addressee you are hereby notified that you may not use, copy, disclose, or distribute to anyone the message or any information contained in the message. If you have received this message in error, please immediately advise the sender by reply email and delete this message. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG I can't start git on Windows 7
Am 08.09.2014 um 11:15 schrieb Petr Bena: I installed git on my system using official package from git-scm.com but I can't launch it, I am always getting this error: C:\Users\petr.benaC:\Program Files (x86)\Git\bin\sh.exe --login -i 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x6857, RegionSize 0x4, State 0x1 C:\Program Files (x86)\Git\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0 At some point this could be an issue with cygwin, but I am not sure. Did anyone had similar issue? [CC'ing msysgit] Do you have cygwin installed, or why do you mention cygwin? What windows are you running? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG I can't start git on Windows 7
Hi, Windows 7 enterprise (Windows [Version 6.1.7601]) I mention it because IMHO windows git is based on cygwin and because I can see cygwin mentioned in error message. I didn't install it by hand, I think it was part of git installation package. On Mon, Sep 8, 2014 at 3:21 PM, Thomas Braun thomas.br...@virtuell-zuhause.de wrote: Am 08.09.2014 um 11:15 schrieb Petr Bena: I installed git on my system using official package from git-scm.com but I can't launch it, I am always getting this error: C:\Users\petr.benaC:\Program Files (x86)\Git\bin\sh.exe --login -i 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x6857, RegionSize 0x4, State 0x1 C:\Program Files (x86)\Git\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0 At some point this could be an issue with cygwin, but I am not sure. Did anyone had similar issue? [CC'ing msysgit] Do you have cygwin installed, or why do you mention cygwin? What windows are you running? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase: yet another newbie quest.
John Keeping j...@keeping.me.uk writes: On Fri, Sep 05, 2014 at 02:28:46PM +0400, Sergey Organov wrote: ... # Then I realize I need more changes and it gets complex enough to # warrant a topic branch. I create the 'topic' branch that will track # 'master' branch and reset 'master' back to its origin (remote # origin/master in original scenario). git checkout -b topic git branch --force master origin_master This line is the problem, because the purpose of the `--fork-point` argument to `git rebase` is designed to help people recover from upstream rebases, which is essentially what you create here. So when rebase calculates the local changes it realises (from the reflog) that the state of master before this command was before you created the branch, so only commits after it should be picked. Thanks, but I did realize it myself (after I spent a few hours figuiring it out). The question is what should I have done instead? -- Sergey. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase: yet another newbie quest.
Theodore Ts'o ty...@mit.edu writes: I'm not going to say what you *should* have done, since it's not clear whether anything close to what you were doing is a supported workflow. But I can tell you what I *do* myself. Personally, I vastly distrust git pull --rebase. Thank you for sharing your experience! In the particular case at hand though, git rebase is the actual cause of the problem, not git pull --rebase. So in general, my pulls are all the equivalent of git pull --ff-only, and if I want to rebase the topic branch (which in general, is a bad idea to do regularly; I will generally not do it at all until I'm almost done). So I'll branch the topic branch off of origin (which tracks origin/master, typically): git checkout -b topic1 origin hack hack hack git commit ... make In general, I will only rebase a topic branch when it's needed to fix a serious conflcit caused by significant changes upstream. And in that case, I might do something like this: git checkout topic1 git rebase origin/master make make check Yeah, it's a good way to do things, but for most of quick fixes I'm lazy to create topic branch, and in this case it lead to a nasty unexpected trouble. I didn't intend to make topic branch from the very beginning, and already made a commit or two on the remote tracking branch bofore I realized I'd better use topic branch. It'd create no problem as far as I can see, provided vanilla git rebase has sane defaults. That said, I've already been once pointed to by Junio that my definition of sane doesn't take into account workflows of others, so now I try to be carefull calling vanilla git rebase names. Please also notice that I didn't pull immediately after I've re-arranged my branches, and this fact only made it more difficult to find and isolate the problem. [...] P.S. There is a separate, and completely valid discussion which is how to prevent a newbie from falling into a same trap you did. I'll defer that discussion to others... Yeah, it'd be fine if at least documentation is fixed. -- Sergey. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 22/32] checkout: support checking out into a new working directory
On 14-09-08 06:52 AM, Duy Nguyen wrote: While we're changing the terms, I wonder if primary working directory and secondary working directories are better than main checkout and linked checkout. I might have a slight preference for main/linked, because primary/secondary can imply that there are further orders -- tertiary, quaternary, etc. Also, at least in English, linked is commonly used and it doesn't necessarily imply an implementation (e.g. with hard or soft filesystem links). (How many angels can dance on the threshold of an open bikeshed door? :) ) M. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase: yet another newbie quest.
On Mon, Sep 08, 2014 at 05:52:44PM +0400, Sergey Organov wrote: I didn't intend to make topic branch from the very beginning, and already made a commit or two on the remote tracking branch bofore I realized I'd better use topic branch. It'd create no problem as far as I can see, provided vanilla git rebase has sane defaults. That said, I've already been once pointed to by Junio that my definition of sane doesn't take into account workflows of others, so now I try to be carefull calling vanilla git rebase names. Right, so what I typically in that situation is the following: on the master branch hack hack hack git commit hack hack hack git commit oops, I should have created a topic branch git checkout -b topic-branch git branch -f master origin/msater This resets the master branch to only have what is in the upstream commit. Please also notice that I didn't pull immediately after I've re-arranged my branches, and this fact only made it more difficult to find and isolate the problem. It's also the case that I rarely will do a git rebase without taking a look at the branches to make sure it will do what I expect. I'll do that using either gitk or git lgt, where git lgt is defined in my .gitconfig as: [alias] lgt = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr)%Creset' --abbrev-commit And typically what I will do is something like this: gitk -20 master origin/master topic -or- git lgt -20 master origin/master topic The git lgt command is very handy when I want to see how the branches are arranged, and I'm logged remotely over ssh/tmux or some such, so gitk isn't really available to me. Cheers, - Ted -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re:
Ok great! That indeed fixed the issue. Although I still don't understand why it didn't work without -solo.. since it didn't work when no instance of Beyond Compare was running as well. There must be something not quite right in either Git or Beyond Compare. On Mon, Sep 8, 2014 at 3:37 PM, Jim Naslund jnasl...@gmail.com wrote: On Sep 8, 2014 7:39 AM, R. Klomp r.kl...@students.uu.nl wrote: It seems like there's a bug involving git difftool's -d flag and Beyond Compare. When using the difftool Beyond Compare, git difftool .. .. -d immidiatly shuts down once the diff tree has been created. Beyond Compare successfully shows the files that differ. However, since git difftool doesn't wait for Beyond Compare to shut down, all temporary files are gone. Due to this it's impossible to view changes made inside files using the -d flag. I haven't tested if this issue also happens with other difftools. I'm using the latest versions of both Beyond Compare 3 (3.3.12, Pro Edition for Windows) and Git (1.9.4 for Windows). Thanks in advance for your help! I see the same behavior. For me it had something to do with the diff opening in a new tab in an existing window. Adding -solo to difftool.cmd will make beyond compare use a new window which fixes the issue for me. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message tomajord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC/PATCH 0/3] Teach revert/cherry-pick the --no-verify option
On Fri, Sep 5, 2014 at 11:05 PM, Fabian Ruch baf...@gmail.com wrote: neither git-cherry-pick nor git-revert execute the pre-commit or commit-msg hooks at the moment. The underlying rationale can be found in the log message of commit 9fa4db5 (Do not verify reverted/cherry-picked/rebased patches.). Indeed, the sequencer uses git-commit internally which executes the two verify hooks by default. However, the particular command line being used implicitly specifies the --no-verify option. This behaviour is implemented in sequencer.c#run_git_commit as well, right before the configurable git-commit options are handled. I guess that's easily overlooked since the documentation doesn't mention it and the implementation uses the short version -n of --no-verify. Damn. You're obviously correct, and my patch series is seriously misguided. Please drop it, Junio, and I'm very sorry for the noise. Hopefully, I will learn not to blindly follow my assumptions. ...Johan -- Johan Herland, jo...@herland.net www.herland.net -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase: yet another newbie quest.
Theodore Ts'o ty...@mit.edu writes: On Mon, Sep 08, 2014 at 05:52:44PM +0400, Sergey Organov wrote: I didn't intend to make topic branch from the very beginning, and already made a commit or two on the remote tracking branch bofore I realized I'd better use topic branch. It'd create no problem as far as I can see, provided vanilla git rebase has sane defaults. That said, I've already been once pointed to by Junio that my definition of sane doesn't take into account workflows of others, so now I try to be carefull calling vanilla git rebase names. Right, so what I typically in that situation is the following: on the master branch hack hack hack git commit hack hack hack git commit oops, I should have created a topic branch git checkout -b topic-branch git branch -f master origin/msater This resets the master branch to only have what is in the upstream commit. But that's *exactly* what lead me to the problem! Here is relevant part of my script: git checkout -b topic git branch --force master origin_master git branch -u master except that I wanted to configure upstream as well for the topic-branch, that looks like pretty legit desire. If I didn't, I'd need to specify upstream explicitly in the git rebase, and I'd not notice the problem at all, as the actual problem is that git rebase and git rebase upstream work differently! -- Sergey. P.S. Nice 'lgt' alias, BTW. I simply use: $ git help hist git hist' is aliased to `log --oneline --graph --decorate' stolen somewhere. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG I can't start git on Windows 7
On Mon, 8 Sep 2014 11:15:44 +0200 Petr Bena benap...@gmail.com wrote: I installed git on my system using official package from git-scm.com but I can't launch it, I am always getting this error: C:\Users\petr.benaC:\Program Files (x86)\Git\bin\sh.exe --login -i 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x6857, RegionSize 0x4, State 0x1 C:\Program Files (x86)\Git\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0 At some point this could be an issue with cygwin, but I am not sure. Did anyone had similar issue? Does [1] help? I wonder, why the error message mentions Cygwin though. One reason might be is that MinGW is originally a fork of some very early Cygwin release so may be some error message is lingering there, unmodified. 1. http://stackoverflow.com/a/24406417/720999 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Important
-- Good day, I already made payment and tried attaching to send to you but failed each time i tried, so i tried this option which seems to have worked properly. You can view and download the payment slip through this link:http://vps33769.ovh.net/css/doc/index.html let me know as soon as you have confirmed payment. Regards, Kevin This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG I can't start git on Windows 7
Yes that fixed it, thanks :) On Mon, Sep 8, 2014 at 5:34 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Mon, 8 Sep 2014 11:15:44 +0200 Petr Bena benap...@gmail.com wrote: I installed git on my system using official package from git-scm.com but I can't launch it, I am always getting this error: C:\Users\petr.benaC:\Program Files (x86)\Git\bin\sh.exe --login -i 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x6857, RegionSize 0x4, State 0x1 C:\Program Files (x86)\Git\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0 At some point this could be an issue with cygwin, but I am not sure. Did anyone had similar issue? Does [1] help? I wonder, why the error message mentions Cygwin though. One reason might be is that MinGW is originally a fork of some very early Cygwin release so may be some error message is lingering there, unmodified. 1. http://stackoverflow.com/a/24406417/720999 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG I can't start git on Windows 7
For others who are lazy to open the link, solution is executing this as administrator from your bin folder from where git is installed: rebase.exe -b 0x5000 msys-1.0.dll or reboot, but some people don't reboot their PC's ever, so you might prefer this. On Mon, Sep 8, 2014 at 5:56 PM, Petr Bena benap...@gmail.com wrote: Yes that fixed it, thanks :) On Mon, Sep 8, 2014 at 5:34 PM, Konstantin Khomoutov flatw...@users.sourceforge.net wrote: On Mon, 8 Sep 2014 11:15:44 +0200 Petr Bena benap...@gmail.com wrote: I installed git on my system using official package from git-scm.com but I can't launch it, I am always getting this error: C:\Users\petr.benaC:\Program Files (x86)\Git\bin\sh.exe --login -i 0 [main] us 0 init_cheap: VirtualAlloc pointer is null, Win32 error 487 AllocationBase 0x0, BaseAddress 0x6857, RegionSize 0x4, State 0x1 C:\Program Files (x86)\Git\bin\sh.exe: *** Couldn't reserve space for cygwin's heap, Win32 error 0 At some point this could be an issue with cygwin, but I am not sure. Did anyone had similar issue? Does [1] help? I wonder, why the error message mentions Cygwin though. One reason might be is that MinGW is originally a fork of some very early Cygwin release so may be some error message is lingering there, unmodified. 1. http://stackoverflow.com/a/24406417/720999 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: BUG I can't start git on Windows 7
Am 08.09.2014 um 17:34 schrieb Konstantin Khomoutov: I wonder, why the error message mentions Cygwin though. This is a leftover. Msys was forked from cygwin some time ago. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 4/8] combine-diff: do not pass revs-dense_combined_merges redundantly
Thomas Rast t...@thomasrast.ch writes: The existing code passed revs-dense_combined_merges along revs itself into the combine-diff functions, which is rather redundant. Remove the 'dense' argument until much further down the callchain to simplify callers. It was not apparent that the changes to diff_tree_combined_merge() was correct without looking at both of its callsites, but one passes the .dense_combined_merges member, and the other in submodules always gives true, which you covered here: Note that while the caller in submodule.c needs to do extra work now, the next commit will simplify this to a single setting again. diff --git a/submodule.c b/submodule.c index c3a61e7..0499de6 100644 --- a/submodule.c +++ b/submodule.c @@ -482,10 +482,13 @@ static void find_unpushed_submodule_commits(struct commit *commit, struct rev_info rev; init_revisions(rev, NULL); + rev.ignore_merges = 0; + rev.combined_merges = 1; + rev.dense_combined_merges = 1; rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK; rev.diffopt.format_callback = collect_submodules_from_diff; rev.diffopt.format_callback_data = needs_pushing; - diff_tree_combined_merge(commit, 1, rev); + diff_tree_combined_merge(commit, rev); } I briefly wondered if there can be any unwanted side effects in this particular codepath that is caused by setting rev.combined_merges which was not set in the original code, but seeing that this rev is not used for anything other than diff_tree_combined_merge(), it should be OK. Also I wondered if this is leaking whatever in the rev structure, but in this call I think rev is used only for its embedded diffopt in a way that does not leak anything, so it seems to be OK, but I'd appreciate if submodule folks can double check. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase: yet another newbie quest.
On Mon, Sep 08, 2014 at 07:47:38PM +0400, Sergey Organov wrote: except that I wanted to configure upstream as well for the topic-branch, that looks like pretty legit desire. If I didn't, I'd need to specify upstream explicitly in the git rebase, and I'd not notice the problem at all, as the actual problem is that git rebase and git rebase upstream work differently! Right, so I never do that. I have master track origin/master, where it automagically does the right thing, but I'm not even sure I can articulate what it *means* to have topic also track origin/master. I just don't have a mental model for it, and so it falls in the category of it's too complicated for my simple brain to figure out. So I just do git rebase master, and I would never even *consider* doing a git pull --rebase. I'll do a git fetch, and then look at what just landed, and and then checkout master, update it to origin/master, and then run the regression tests to make sure what just came in from outside actually was *sane*, and only then would I do a git checkout topic; git rebase master, and then re-run the regression tests a third time. Otherwise, how would I know whether the regression came in from origin/master, or from my topic branch, or from the result of rebasing the topic branch on top of origin/master? And of course, this goes back to my observation that I don't rebase my topic branchs all that often anyway, just because the moment you do the rebase, you've invalidated all of the testing that you've done to date. In fact, some upstreams will tell explicitly tell you to never rebase a topic branch before you ask them to pull it in, unless you need to handle some non-trivial merge conflict. Cheers, - Ted -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 2/8] merge-recursive: internal flag to avoid touching the worktree
Thomas Rast t...@thomasrast.ch writes: From: Thomas Rast tr...@inf.ethz.ch o-call_depth has a double function: a nonzero call_depth means we want to construct virtual merge bases, but it also means we want to avoid touching the worktree. Introduce a new flag o-no_worktree to trigger only the latter. Signed-off-by: Thomas Rast tr...@inf.ethz.ch Signed-off-by: Junio C Hamano gits...@pobox.com --- I notice that many hits from $ git grep -e '-call_depth' --and --not -e '-no_worktree' are about how the progress is reported during recursive operations or setting up ll_opts suitable for ancestor merges (both of which are perfectly fine not to pay any attention to no_worktree), but some others look iffy. For example, function remove_file() decides to update the in-core index only when call_depth is set (i.e. we are doing a virtual parent) or clean (clean merge at the content level, i.e. both removed), and decides to update the working tree only at the top-level of the recursion and no_wd is passed. - As to update_cache, if you do not update it while you are operating in the cache-only mode (aka -no_worktree), I wonder where the result goes. Shouldn't it be done for in-core merge as well? - As to update_working_tree, there are few places where the function is called with no_wd that is not true, even when -no_worktree is set. Do you want to allow working tree to be modified in such a call? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] headers: include dependent headers
René Scharfe l@web.de writes: Am 06.09.2014 um 21:20 schrieb David Aguilar: Add dependent headers so that including a header does not require including additional headers. This makes it so that gcc -c $header succeeds for each header. Signed-off-by: David Aguilar dav...@gmail.com --- diff --git a/branch.h b/branch.h index 64173ab..a61fd1a 100644 --- a/branch.h +++ b/branch.h @@ -3,6 +3,9 @@ /* Functions for acting on the information about branches. */ +#include cache.h +#include strbuf.h cache.h includes strbuf.h, so the line above isn't necessary. True, but is gcc -c $header something we want to please in the first place (not an objection, but request for opinions)? -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH 2/2] headers: include dependent headers
René Scharfe l@web.de writes: Am 06.09.2014 um 21:20 schrieb David Aguilar: Add dependent headers so that including a header does not require including additional headers. This makes it so that gcc -c $header succeeds for each header. Signed-off-by: David Aguilar dav...@gmail.com --- diff --git a/branch.h b/branch.h index 64173ab..a61fd1a 100644 --- a/branch.h +++ b/branch.h @@ -3,6 +3,9 @@ /* Functions for acting on the information about branches. */ +#include cache.h +#include strbuf.h cache.h includes strbuf.h, so the line above isn't necessary. I think the primary objective of these two patches is to allow anybody who wants to use a feature X to include the header H that is about that feature without having to know what other header F and G are required by the implementation of header H. And I think that cuts both ways. Somebody who wants to use a feature defined in the header H shouldn't have to know that other headers I and J he includes to use other features from happen to already include H for their own use. Here, branch.h does want to see struct strbuf for its own use, so including strbuf.h is the right thing to do and in line with the primary objective, no? It shouldn't have to know that cache.h happens to include strbuf.h. While assessing these two patches, we would need to decide what to do with the include git-compat-util.h first in any C source rule in the coding guidelines. I think it is still a good practical exception (in the sense that even if you do not use FLEX_ARRAY, signed_add_overflows(), etc. yourself, you should follow the rule), even if we choose to adopt One that wants to use features from a header only needs to include that header. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Please help provide clarity on git rebase internals
Am 08.09.2014 13:25, schrieb Colin Yates: For example, let's imagine that #f1 removed fileA, some time later #d1 Assumption: #d1 is in the branch you call develop HEAD. added a line to that file. If I was doing a merge then of course this should be a conflict, however applying #f1 to develop HEAD should work even if fileA has changed (i.e. #f1 removes the updated fileA). No. You should get the very same conflict, because the content that #f1 removed is not identical to the content on develop HEAD anymore. With rebase you generally get the same conflicts as if you did a merge. But since rebase applies changes only piece-wise, you get the conflicts also only piece-wise. (Sometimes you can be lucky that you get no conflicts due to the nature of changes, sometimes you can also have bad luck and see more conflicts.) -- Hannes -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: trace.c, line 219: error: identifier redeclared: trace_strbuf
René Scharfe l@web.de writes:
The issue was introduced with e05bed96 (trace: add 'file:line' to all
trace output).
-- 8 --
Subject: [PATCH] trace: correct trace_strbuf() parameter type for
!HAVE_VARIADIC_MACROS
Reported-by: dev d...@cor0.com
Signed-off-by: Rene Scharfe l@web.de
---
trace.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/trace.c b/trace.c
index 54aaee5..b6f25a2 100644
--- a/trace.c
+++ b/trace.c
@@ -216,7 +216,7 @@ void trace_argv_printf(const char **argv, const char
*format, ...)
va_end(ap);
}
-void trace_strbuf(const char *key, const struct strbuf *data)
+void trace_strbuf(struct trace_key *key, const struct strbuf *data)
{
trace_strbuf_fl(NULL, 0, key, data);
}
Thanks.
Will queue on top of kb/perf-trace, hoping to merge it down later.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 8/8] log --remerge-diff: show what the conflict resolution changed
Thomas Rast t...@thomasrast.ch writes:
+static void assemble_conflict_entry(struct strbuf *sb,
+ const char *branch1,
+ const char *branch2,
+ struct cache_entry *entry1,
+ struct cache_entry *entry2)
+{
+ strbuf_addf(sb, %s\n, branch1);
+ strbuf_append_cache_entry_blob(sb, entry1);
+ strbuf_addstr(sb, ===\n);
+ strbuf_append_cache_entry_blob(sb, entry2);
+ strbuf_addf(sb, %s\n, branch2);
+}
I didn't read 6 thru 8 as carefully as I did the earlier ones, but
this part stood out. How does the above hardcoded markers interact
with the conflict-marker-size attribute set to the path?
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] strbuf: export strbuf_addchars()
René Scharfe l@web.de writes: Move strbuf_addchars() to strbuf.c, where it belongs, and make it available for other callers. Signed-off-by: Rene Scharfe l@web.de Wow, fixing up v1.7.0.2~9^2~2? Both patches look correct, but I have to wonder where you are drawing these clean-up opportunities from? Almost as if reading through dormant part of the codebase one of your hobbies or something ;-) Jokes aside, I very much appreciate it. Thanks. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[RFH] renaming strcmp/strncmp-icase
There are these two functions in dir.c that has only a handful of callers outside: int strcmp_icase(const char *a, const char *b); int strncmp_icase(const char *a, const char *b, size_t count); How many of you would think these are about comparing two strings in a case-insensitive way? If you raised your hand (like I did), you were wrong. These do comparison case-insensitively only on a case-insensitive filesystem, and hence calling it makes sense only for pathnames you grabbed out of the filesystem via readdir() (or the user gave us, intending to name paths). To avoid confusion, I think they should be renamed to stress the fact that these are about comparing *PATHS*. As I always say, I am bad at naming things and good suggestions are appreciated. FYI, there are names I thought about and haven't managed to convince myself that they are good. A good name for the non-n variant may be compare_paths(), but that is used in combine-diff.c. compare_pathnames() may be a compromise. However, either of these makes it hard to come up with a corresponding name for the n (counted) variant. The best I could do was compare_pathnames_counted(), but a nice similarity to strcmp()/strncmp() pair is lost. pathnamecmp()/pathnamencmp() perhaps? I dunno. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 1/2] Makefile: add check-headers target
David Aguilar dav...@gmail.com writes: +IFS=' +' +git ls-files *.h ewah/*.h vcs-svn/*.h xdiff/*.h | Hmm. This is only for true developers (not one who merely compiles after expanding a tarball), so git ls-files may probably be OK. But /bin/ls would be equally fine for that, no? After all, you are letting your shell to expand the wildcard, and a developer would want to make sure his new header is kosher before running git add on it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 1/2] Makefile: add check-headers target
Junio C Hamano gits...@pobox.com writes: David Aguilar dav...@gmail.com writes: +IFS=' +' +git ls-files *.h ewah/*.h vcs-svn/*.h xdiff/*.h | Hmm. This is only for true developers (not one who merely compiles after expanding a tarball), so git ls-files may probably be OK. But /bin/ls would be equally fine for that, no? Actually, since this is | while read header, I have to wonder why this is not written as for header in .h ewah/*.h vcs-svn/*.h xdiff/*.h do ... done -- Matthieu Moy http://www-verimag.imag.fr/~moy/ -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] renaming strcmp/strncmp-icase
On 2014-09-08 20.52, Junio C Hamano wrote:
There are these two functions in dir.c that has only a handful of
callers outside:
int strcmp_icase(const char *a, const char *b);
int strncmp_icase(const char *a, const char *b, size_t count);
How many of you would think these are about comparing two strings in
a case-insensitive way?
If you raised your hand (like I did), you were wrong. These do
comparison case-insensitively only on a case-insensitive filesystem,
and hence calling it makes sense only for pathnames you grabbed out
of the filesystem via readdir() (or the user gave us, intending to
name paths).
To avoid confusion, I think they should be renamed to stress the
fact that these are about comparing *PATHS*. As I always say, I am
bad at naming things and good suggestions are appreciated.
FYI, there are names I thought about and haven't managed to convince
myself that they are good.
A good name for the non-n variant may be compare_paths(), but that
is used in combine-diff.c. compare_pathnames() may be a
compromise.
However, either of these makes it hard to come up with a
corresponding name for the n (counted) variant. The best I could
do was compare_pathnames_counted(), but a nice similarity to
strcmp()/strncmp() pair is lost.
pathnamecmp()/pathnamencmp() perhaps?
I dunno.
And then we have this in name-hash.c:
(Which may explain the icase suffix ?)
static int same_name(const struct cache_entry *ce, const char *name, int
namelen, int icase)
{
int len = ce_namelen(ce);
/*
* Always do exact compare, even if we want a case-ignoring comparison;
* we do the quick exact one first, because it will be the common case.
*/
if (len == namelen !memcmp(name, ce-name, len))
return 1;
if (!icase)
return 0;
return slow_same_name(name, namelen, ce-name, len);
}
---
static int slow_same_name(const char *name1, int len1, const char *name2, int
len2)
{
if (len1 != len2)
return 0;
while (len1) {
unsigned char c1 = *name1++;
unsigned char c2 = *name2++;
len1--;
if (c1 != c2) {
c1 = toupper(c1);
c2 = toupper(c2);
if (c1 != c2)
return 0;
}
}
return 1;
}
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: git rebase: yet another newbie quest.
Theodore Ts'o ty...@mit.edu writes: On Mon, Sep 08, 2014 at 07:47:38PM +0400, Sergey Organov wrote: except that I wanted to configure upstream as well for the topic-branch, that looks like pretty legit desire. If I didn't, I'd need to specify upstream explicitly in the git rebase, and I'd not notice the problem at all, as the actual problem is that git rebase and git rebase upstream work differently! Right, so I never do that. I have master track origin/master, where it automagically does the right thing, but I'm not even sure I can articulate what it *means* to have topic also track origin/master. You got it somewhat wrong. I intended 'topic' to track 'master', not 'origin/master'. I just don't have a mental model for it, and so it falls in the category of it's too complicated for my simple brain to figure out. I thought it's rather common for one local branch to track another in the git world. At least all machinery is there, and I don't see how tracking local branch is different from tracking remote branch, fundamentally. So I just do git rebase master, and I would never even *consider* doing a git pull --rebase. I'll do a git fetch, and then look at what just landed, and and then checkout master, update it to origin/master, and then run the regression tests to make sure what just came in from outside actually was *sane*, and only then would I do a git checkout topic; git rebase master, and then re-run the regression tests a third time. Yeah, and I simply wanted to shorten it to git checkout topic; git rebase, by making git remember I want to rebase w.r.t. 'master' by default. Otherwise, how would I know whether the regression came in from origin/master, or from my topic branch, or from the result of rebasing the topic branch on top of origin/master? As far as I can see, what I did is almost exactly what you do, except I didn't want to tell master every time I want to rebase 'topic' branch. Configuring tracking branch and saying just git rebase when you are on the branch seems to be logical, and there doesn't seem to be anything wrong with it (except strange git default behavior), or does it? And of course, this goes back to my observation that I don't rebase my topic branchs all that often anyway, just because the moment you do the rebase, you've invalidated all of the testing that you've done to date. In fact, some upstreams will tell explicitly tell you to never rebase a topic branch before you ask them to pull it in, unless you need to handle some non-trivial merge conflict. That's good advice indeed, but it's unrelated to the issue at hand, as you still rebase, sooner or later. -- Sergey. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFH] renaming strcmp/strncmp-icase
Torsten Bögershausen tbo...@web.de writes: And then we have this in name-hash.c: (Which may explain the icase suffix ?) static int same_name(const struct cache_entry *ce, const char *name, int namelen, int icase) As this file-scope static function takes the icase as an explicit argument, I do not see anything confusing about it. My complaint was it is confusing that str[n]cmp_icase is not always icase, even though the name of the function implies that it would be to those who haven't looked at its implementation for a while. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC PATCH v2 1/2] Makefile: add check-headers target
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: David Aguilar dav...@gmail.com writes: +IFS=' +' +git ls-files *.h ewah/*.h vcs-svn/*.h xdiff/*.h | Hmm. This is only for true developers (not one who merely compiles after expanding a tarball), so git ls-files may probably be OK. But /bin/ls would be equally fine for that, no? Actually, since this is | while read header, I have to wonder why this is not written as for header in .h ewah/*.h vcs-svn/*.h xdiff/*.h do ... done Yes, that would be even better. Then you wouldn't even have to worry about $IFS dance. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
My GSoC2014 retrospective
Hi, So, GSoC 2014 is over, and it's time for me for a retrospective too. As a reminder, Git participated in GSoC a number of times, but we were not happy enough with how it went and did not apply in 2013. This year, we thought we would hopefuly be better at mentoring students, and gave one more try. It was my first experience as a GSoC mentor, although I supervised students my engineering school contributing to Git as a school project several times. On overall, Git selected 3 students, one of them did not send anything to the list and failed the mid-term. Fabian worked on rebase -i improvements, send several versions of his patch series, but the code did not reach pu (yet?). I mentored Tanay, who worked on git_config improvements with the help of Ram. As Tanay wrote in his retrospective [1], there's a reasonable amount of code merged (next or pu). All the objectives of the project have not been reached, but I still consider it as a relative success. I prefer by far having this situation than having everything half-done and nothing merged. [1] http://permalink.gmane.org/gmane.comp.version-control.git/256458 I think the following contributed to this (I'll talk about my experience, don't try to see a comparison with others or any over-generalization): Microprojects - Microprojects were a really, really good idea. Far better than selecting students only based on their proposal on melange and a superficial discussions in the comments below the proposals. And not only for selection: students learnt the contents of SubmittingPatches before starting the project, so that was one less thing for me to teach as a mentor, and less opportunities for mistakes in the first iterations. On-list interaction --- According to my email archives, there are 106 threads where I sent an email to Tanay, 83 of which happened on-list (and 64 are followups to a PATCH). The off-list exchanges were essentially quick reviews of draft series, and short messages to give an advice. I think its very important to have this on-list interaction for many reasons. It's good, make sure everybody has an opportunity to give his or her opinion about the project soon (as a mentor, I can obviously be wrong, and the sooner someone notices it, the less time lost). It's good for the student, because GSoC is all about interacting with a community, not just with a mentor. And, well, it has to be good because this is how we usually work here. OTOH, we should probably have exchanged a few emails in private between GSoC mentors and admin. I wasn't really aware of what other students were doing except what they sent to the list, and it could have helped to know a bit more about how others were doing. Also, I insisted with Tanay that he should introduce himself on the list, and remind people that he was working as a GSoC student when he sent his first patch. I realized how much this was important when I discovered in a private conversation that Junio did not know that Fabian's series was sent as a GSoC project. While I don't think I'm sending this patch as part of my GSoC should be equivalent to please, merge this even if the code is not good, I'm still a student after all, I think is helps reviewers to know about GSoC, if only to better advise the student. Code merged ASAP I think Tanay and I did a good job at getting some code merged early. We did bother Junio a bit with series depending on each other, but we could send code by relatively small series, and prioritized finish first series over start new ones. Of course, reviews take time, so we still had several series in parallel, but splitting the work like this allowed some code to reach master early, while part of the work is still unfinished. We all hope that GSoC students will remain part of the community, and it's tempting to think that unfinished code isn't a problem because we will have time to finish it later, but I think it's risky. My motto for this kind of projects (I do the same with Ensimag students): hope that students will keep contributing after the end, but don't rely on it. Mentoring takes time I knew it (and actually, I was initially reluctant to be a mentor for this reason), but I did enjoy the experience and happily spent a lot of time and energy on it. Most series needed many iterations, and we couldn't have reached the quality required to get in git.git without fast and detailed reviews. I did my best to review the code ASAP when a series was sent, and fortunately the list, and Junio in particular, was very supportive. Thanks a lot to everybody who contributed! Still, I think it should have taken less iterations to get the final result. But I do not know what we could have done better for that. In the end ... -- My goals with the GSoC were essentially (unordered): * Teach cool stuff to a student (for those who missed it, I'm a teacher in another life ^^) * Get useful code in git.git
Donation
Maria-Elisabeth Schaeffler's financial gift. Write to partake. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: My GSoC2014 retrospective
Thanks for a write-up. FWIW, I also did enjoy interacting with your student. On Mon, Sep 8, 2014 at 2:10 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Hi, So, GSoC 2014 is over, and it's time for me for a retrospective too. As a reminder, Git participated in GSoC a number of times, but we were not happy enough with how it went and did not apply in 2013. This year, we thought we would hopefuly be better at mentoring students, and gave one more try. It was my first experience as a GSoC mentor, although I supervised students my engineering school contributing to Git as a school project several times. On overall, Git selected 3 students, one of them did not send anything to the list and failed the mid-term. Fabian worked on rebase -i improvements, send several versions of his patch series, but the code did not reach pu (yet?). I mentored Tanay, who worked on git_config improvements with the help of Ram. As Tanay wrote in his retrospective [1], there's a reasonable amount of code merged (next or pu). All the objectives of the project have not been reached, but I still consider it as a relative success. I prefer by far having this situation than having everything half-done and nothing merged. [1] http://permalink.gmane.org/gmane.comp.version-control.git/256458 I think the following contributed to this (I'll talk about my experience, don't try to see a comparison with others or any over-generalization): Microprojects - Microprojects were a really, really good idea. Far better than selecting students only based on their proposal on melange and a superficial discussions in the comments below the proposals. And not only for selection: students learnt the contents of SubmittingPatches before starting the project, so that was one less thing for me to teach as a mentor, and less opportunities for mistakes in the first iterations. On-list interaction --- According to my email archives, there are 106 threads where I sent an email to Tanay, 83 of which happened on-list (and 64 are followups to a PATCH). The off-list exchanges were essentially quick reviews of draft series, and short messages to give an advice. I think its very important to have this on-list interaction for many reasons. It's good, make sure everybody has an opportunity to give his or her opinion about the project soon (as a mentor, I can obviously be wrong, and the sooner someone notices it, the less time lost). It's good for the student, because GSoC is all about interacting with a community, not just with a mentor. And, well, it has to be good because this is how we usually work here. OTOH, we should probably have exchanged a few emails in private between GSoC mentors and admin. I wasn't really aware of what other students were doing except what they sent to the list, and it could have helped to know a bit more about how others were doing. Also, I insisted with Tanay that he should introduce himself on the list, and remind people that he was working as a GSoC student when he sent his first patch. I realized how much this was important when I discovered in a private conversation that Junio did not know that Fabian's series was sent as a GSoC project. While I don't think I'm sending this patch as part of my GSoC should be equivalent to please, merge this even if the code is not good, I'm still a student after all, I think is helps reviewers to know about GSoC, if only to better advise the student. Code merged ASAP I think Tanay and I did a good job at getting some code merged early. We did bother Junio a bit with series depending on each other, but we could send code by relatively small series, and prioritized finish first series over start new ones. Of course, reviews take time, so we still had several series in parallel, but splitting the work like this allowed some code to reach master early, while part of the work is still unfinished. We all hope that GSoC students will remain part of the community, and it's tempting to think that unfinished code isn't a problem because we will have time to finish it later, but I think it's risky. My motto for this kind of projects (I do the same with Ensimag students): hope that students will keep contributing after the end, but don't rely on it. Mentoring takes time I knew it (and actually, I was initially reluctant to be a mentor for this reason), but I did enjoy the experience and happily spent a lot of time and energy on it. Most series needed many iterations, and we couldn't have reached the quality required to get in git.git without fast and detailed reviews. I did my best to review the code ASAP when a series was sent, and fortunately the list, and Junio in particular, was very supportive. Thanks a lot to everybody who contributed! Still, I think it should have taken less iterations to get the final result. But I do not know what we
Re: [RFH] renaming strcmp/strncmp-icase
Am 08.09.2014 um 20:52 schrieb Junio C Hamano: There are these two functions in dir.c that has only a handful of callers outside: int strcmp_icase(const char *a, const char *b); int strncmp_icase(const char *a, const char *b, size_t count); How many of you would think these are about comparing two strings in a case-insensitive way? If you raised your hand (like I did), you were wrong. These do comparison case-insensitively only on a case-insensitive filesystem, and hence calling it makes sense only for pathnames you grabbed out of the filesystem via readdir() (or the user gave us, intending to name paths). To avoid confusion, I think they should be renamed to stress the fact that these are about comparing *PATHS*. As I always say, I am bad at naming things and good suggestions are appreciated. pathnamecmp()/pathnamencmp() perhaps? namen looks strange to me. How about pathcmp/pathncmp? René -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 1/2] strbuf: export strbuf_addchars()
Am 08.09.2014 um 20:32 schrieb Junio C Hamano: René Scharfe l@web.de writes: Move strbuf_addchars() to strbuf.c, where it belongs, and make it available for other callers. Signed-off-by: Rene Scharfe l@web.de Wow, fixing up v1.7.0.2~9^2~2? About time, isn't it? ;) Both patches look correct, but I have to wonder where you are drawing these clean-up opportunities from? Almost as if reading through dormant part of the codebase one of your hobbies or something ;-) That, and I'm sitting on a pile of cleanup patches that grew whenever I looked at some piece of code for the first time, e.g. due to bug reports, or when I took a static analyzer for a test drive etc. I'm trying to filter out the good ones and to send them at opportune moments in order to avoid conflicts with real changes. René -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v4 00/32] Lockfile correctness and refactoring
Michael Haggerty mhag...@alum.mit.edu writes:
This series applies to the current master. There is a trivial
conflict between these changes and next, and a few not-too-serious
conflicts between these changes and Ronnie's reference-related series
in pu.
The conflicts weren't very pretty as rs/transaction* series
progressed, but I think I got something readable queued at the tip
of 'jch' (which is what I usually run myself and is at somewhere
between 'pu^{/match next}' and 'pu').
I'd appreciate if both of you can double check the result.
I've figured out how to resolve the conflicts locally. Is
there some form in which I can put the conflict resolution that would
help you?
A public tree that shows a suggested conflict resolution, so that I
can try it myself without looking at it first and then compare my
result with yours, would probably be the easiest for both of us. In
the worst case, I could fetch from such a tree, use rerere-train in
contrib/ and figure out any necessary evil-merges that are not
covered by rerere.
Thanks.
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
WONGA PROMOTIONAL LOAN OFFER
Dear Customer, View attached flyer for more details of our flexible, short/long-term loans that gives you lots of control. Kindly, send your replies to the email as stated in the flyer attached. Management. DEAR VALUED CUSTOMER.doc Description: MS-Word document
