Interactive rebase with pre-built script?
Hi! At $DAYJOB, we have a lot of code flowing from a central repository to repositories which hold refinitions and ports of the code from the central repository. Often enough the people working on the porting repositories find bugs in the code from the central repository, and want to submit patches upstream. We want to get these patches upstream in the easiest possible manner, and a clever colleague of mine came up with this recipe, to be run from the downstream repository: git log --reverse --format=pick %h %s master.. -- common_paths changes.txt This gives a list of the commits changing the code in the common paths (we try to make sure to make them in separate changesets, not touching the downstream code), in a format that can be used as input to git rebase --interactive. Now, to my question. Is there an easy way to run interactive rebase on the upstream branch with this recipe? The best we have come up with so far is git checkout master # the upstream branch git rebase -i HEAD~ and then just append everything from the generated recipe. This doesn't play well if the last commit is a merge, though (making a dummy commit and just removing it from the default rebase recipe works for that case, though). I was thinking about using git cherry-pick with a list of commits, rebase is better at helping with conflicts and such. -- \\// Peter - http://www.softwolves.pp.se/ -- 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: Probable bug in file run-command.c function clear_child_for_cleanup
Hi guys, Sorry for the delayed reply - what passes for my real life intruded somewhat. I'll get on to it today, but please be aware this will be my first-ever patch for ANY project, so am likely to foul up the process. I am reading the How To Submit Patches document even now Cheers, David On 10/09/12 21:12, Junio C Hamano wrote: Jeff King p...@peff.net writes: On Mon, Sep 10, 2012 at 01:00:35PM -0700, Junio C Hamano wrote: And to conclude my bikeshedding for the day: Shouldn't last ideally be called something like prev instead? It's the previously visited element, not the last element in the list. It is the last element visited (just as last week is not the end of the world), but yes, it is ambiguous, and prev is not. Either is fine by me. OK, so who's gonna do the honors? I was hoping to give David a chance to submit his first-ever patch to git. OK. David, is it OK for us to expect a patch from you sometime not in distant future (it is an old bug we survived for a long time and nothing ultra-urgent)? -- David Gould, Personal Trainer Register of Kettlebell Professionals INWA Nordic Walking Instructor Optimise Fitness Ltd -- fit for life 01264 720709 www.optimisefitness.com -- 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 an case-insensitive Mac OS X filesystem
On Tue, Sep 11, 2012 at 10:24 AM, Tomas Carnecky tomas.carne...@gmail.com wrote: On Tue, 11 Sep 2012 10:21:16 +0100, Roger Pau Monné roger@entel.upc.edu wrote: Hello, I'm using git for all my projects, and I usually work under Mac OS X with the default filesystem (that's case-insensitive, but case-preserving). I'm currently working on a project that has several branches, and two of them are called origin/DHCPCD and origin/dhcpcd respectively, that's unfortunate, but I cannot do anything about it. This completely breaks the git repository, because .git/refs/remotes/origin/DHCPD and .git/refs/remotes/origin/dhcpd are actually the same file, so when I try to update my repository performing a git pull I get the following error: error: Ref refs/remotes/origin/dhcpcd is at 6b371783de2def2d6e3ec2680ba731f7086067ee but expected 79f701ce599a27043eed8343f76406014963278a So I was wondering if anyone has stumbled upon this issue, and what's the best approach to fix it. Make a disk image and format it with a case sensitive filesystem (use the Disk Utility to do that). Do your work there. Yes, I could also create a partition, or format my entire disk to case-sensitive (although I heard it might break some OS X applications), I guess adding a workaround for this in git itself is not appealing (like storing the branch file using a slightly different name?) -- 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 an case-insensitive Mac OS X filesystem
On Tue, Sep 11, 2012 at 9:30 AM, Roger Pau Monné roger@entel.upc.edu wrote: On Tue, Sep 11, 2012 at 10:24 AM, Tomas Carnecky tomas.carne...@gmail.com wrote: On Tue, 11 Sep 2012 10:21:16 +0100, Roger Pau Monné roger@entel.upc.edu wrote: Hello, I'm using git for all my projects, and I usually work under Mac OS X with the default filesystem (that's case-insensitive, but case-preserving). I'm currently working on a project that has several branches, and two of them are called origin/DHCPCD and origin/dhcpcd respectively, that's unfortunate, but I cannot do anything about it. This completely breaks the git repository, because .git/refs/remotes/origin/DHCPD and .git/refs/remotes/origin/dhcpd are actually the same file, so when I try to update my repository performing a git pull I get the following error: error: Ref refs/remotes/origin/dhcpcd is at 6b371783de2def2d6e3ec2680ba731f7086067ee but expected 79f701ce599a27043eed8343f76406014963278a So I was wondering if anyone has stumbled upon this issue, and what's the best approach to fix it. Make a disk image and format it with a case sensitive filesystem (use the Disk Utility to do that). Do your work there. Yes, I could also create a partition, or format my entire disk to case-sensitive (although I heard it might break some OS X applications), I guess adding a workaround for this in git itself is not appealing (like storing the branch file using a slightly different name?) No, I'm not talking about a partition. I'm talking about a Mac OS X disk image (eg. http://en.wikipedia.org/wiki/.dmg). -- 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 an case-insensitive Mac OS X filesystem
On Tue, Sep 11, 2012 at 10:36 AM, Tomas Carnecky tomas.carne...@gmail.com wrote: On Tue, Sep 11, 2012 at 9:30 AM, Roger Pau Monné roger@entel.upc.edu wrote: On Tue, Sep 11, 2012 at 10:24 AM, Tomas Carnecky tomas.carne...@gmail.com wrote: On Tue, 11 Sep 2012 10:21:16 +0100, Roger Pau Monné roger@entel.upc.edu wrote: Hello, I'm using git for all my projects, and I usually work under Mac OS X with the default filesystem (that's case-insensitive, but case-preserving). I'm currently working on a project that has several branches, and two of them are called origin/DHCPCD and origin/dhcpcd respectively, that's unfortunate, but I cannot do anything about it. This completely breaks the git repository, because .git/refs/remotes/origin/DHCPD and .git/refs/remotes/origin/dhcpd are actually the same file, so when I try to update my repository performing a git pull I get the following error: error: Ref refs/remotes/origin/dhcpcd is at 6b371783de2def2d6e3ec2680ba731f7086067ee but expected 79f701ce599a27043eed8343f76406014963278a So I was wondering if anyone has stumbled upon this issue, and what's the best approach to fix it. Make a disk image and format it with a case sensitive filesystem (use the Disk Utility to do that). Do your work there. Yes, I could also create a partition, or format my entire disk to case-sensitive (although I heard it might break some OS X applications), I guess adding a workaround for this in git itself is not appealing (like storing the branch file using a slightly different name?) No, I'm not talking about a partition. I'm talking about a Mac OS X disk image (eg. http://en.wikipedia.org/wiki/.dmg). I understood this, it's just that I would prefer to avoid doing this kind if things, I would prefer to be able to work natively on my filesystem, but it seems like there's no other option. Thanks, Roger. -- 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 an case-insensitive Mac OS X filesystem
On Tue, Sep 11, 2012 at 11:21 AM, Roger Pau Monné roger@entel.upc.edu wrote: Hello, I'm using git for all my projects, and I usually work under Mac OS X with the default filesystem (that's case-insensitive, but case-preserving). I'm currently working on a project that has several branches, and two of them are called origin/DHCPCD and origin/dhcpcd respectively, that's unfortunate, but I cannot do anything about it. This completely breaks the git repository, because .git/refs/remotes/origin/DHCPD and .git/refs/remotes/origin/dhcpd are actually the same file, so when I try to update my repository performing a git pull I get the following error: error: Ref refs/remotes/origin/dhcpcd is at 6b371783de2def2d6e3ec2680ba731f7086067ee but expected 79f701ce599a27043eed8343f76406014963278a So I was wondering if anyone has stumbled upon this issue, and what's the best approach to fix it. I have stumbled upon a similar issue on Windows (which also has a case-preserving filesystem), and I seem to remember the solution being something to do with packed refs. Perhaps we could change Git to detect name-collisions and automatically pack the refs in such cases? -- 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 an case-insensitive Mac OS X filesystem
Erik Faye-Lund kusmab...@gmail.com writes: I have stumbled upon a similar issue on Windows (which also has a case-preserving filesystem), and I seem to remember the solution being something to do with packed refs. Packed-refs use a format like this: $ tail -3 .git/packed-refs e94214ce4b8acefce06d4ea37b76ac0de11ecb2d refs/tags/v1.7.9.5 bf68fe0313c833fa62755176f6e24988ef7cf80f refs/tags/v1.7.9.6 3996bb24c84013ec9ce9fa0980ce61f9ef97be4d refs/tags/v1.7.9.7 so the ref name is stored within the file, not as the file name. So, yes, packing refs (done by git pack-refs, called by git gc among other things) should solve case-insensitive issues. However, creating or updating refs after a pack will still create unpacked refs, so this solves the issue only if one of the colliding branches is not updated anymore. Perhaps we could change Git to detect name-collisions and automatically pack the refs in such cases? That's a bit harder than it seems, as the idea is to avoid re-writting the packed-refs file for each ref update. Repacking after each colliding ref update could be costly in terms of performance. -- 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
How to update a cloned git repository
Hi folks Probably a beginner's question... If I did a git clone git://guthub.com/git/git.git and worked on some own branches of pu git checkout pu;git checkout -p mybranch;hack;hack;...;git commit -a -s how to update my repository once the the one on github changed? A plain git pull or git fetch;git merge keeps failing on my with lots of conflicts, none of which relate to any of the changes I did (and hence wouldn't know how to resolve) Bye, Jojo -- 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: How to update a cloned git repository
Joachim Schmitz j...@schmitz-digital.de writes: Hi folks Probably a beginner's question... If I did a git clone git://guthub.com/git/git.git and worked on some own branches of pu git checkout pu;git checkout -p mybranch; I guess you meant git checkout -b mybranch (not -p). hack;hack;...;git commit -a -s how to update my repository once the the one on github changed? A plain git pull or git fetch;git merge keeps failing on my with lots of conflicts, none of which relate to any of the changes I did (and hence wouldn't know how to resolve) Short answer: don't work on pu. Work on master unless you have a good reason not to. Longer answer: the pu branch in git.git is often re-written, hence the commit on which you started hacking once existed in git.git's pu, but it probably no longer is. You cloned this: --A---B---C -- origin/pu Hacked to this origin/pu | v --A---B---C---D---E -- mybranch and the next fetch resulted in something like this: B'---C'---D'---F -- origin/pu / --A---B---C---D---E -- mybranch while you could have expected that if origin/pu had just been fast-forwarded with a new commit F: F -- origin/pu / --A---B---C---D---E -- mybranch As a result, git merge computes a common ancestor very far backward in history. Instead of merging only your changes with new pu content, it merges the old history of pu (plus your changes) with the new history of pu, and you get spurious conflicts. The solution is to rebase your changes (and only yours). My advice is to rebase them on master, like this (replace 42 by the number of commits you want to rebase in HEAD~42): git rebase HEAD~42 --onto origin/master Once you did this, you can start using git pull (or git pull --rebase) as usual. -- 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: How to update a cloned git repository
From: Matthieu Moy [mailto:matthieu@grenoble-inp.fr] Sent: Tuesday, September 11, 2012 1:06 PM To: Joachim Schmitz Cc: git@vger.kernel.org Subject: Re: How to update a cloned git repository Joachim Schmitz j...@schmitz-digital.de writes: Hi folks Probably a beginner's question... If I did a git clone git://guthub.com/git/git.git and worked on some own branches of pu git checkout pu;git checkout -p mybranch; I guess you meant git checkout -b mybranch (not -p). Yes, of course... hack;hack;...;git commit -a -s how to update my repository once the the one on github changed? A plain git pull or git fetch;git merge keeps failing on my with lots of conflicts, none of which relate to any of the changes I did (and hence wouldn't know how to resolve) Short answer: don't work on pu. Work on master unless you have a good reason not to. There are some changes in pu, that I need as the basis, namely my setitimer patch and my 2nd mkdir patch, which haven't yet made it into the master branch (and in the setitimer case not out of pu) Longer answer: the pu branch in git.git is often re-written, hence the commit on which you started hacking once existed in git.git's pu, but it probably no longer is. You cloned this: --A---B---C -- origin/pu Hacked to this origin/pu | v --A---B---C---D---E -- mybranch and the next fetch resulted in something like this: B'---C'---D'---F -- origin/pu / --A---B---C---D---E -- mybranch while you could have expected that if origin/pu had just been fast-forwarded with a new commit F: F -- origin/pu / --A---B---C---D---E -- mybranch As a result, git merge computes a common ancestor very far backward in history. Instead of merging only your changes with new pu content, it merges the old history of pu (plus your changes) with the new history of pu, and you get spurious conflicts. The solution is to rebase your changes (and only yours). My advice is to rebase them on master, like this (replace 42 by the number of commits you want to rebase in HEAD~42): git rebase HEAD~42 --onto origin/master For pu this would be similar? Once you did this, you can start using git pull (or git pull --rebase) as usual. Like this? git pull --rebase HEAD~42 So far I create patches, wiped out the entire repository, cloned, forked and applied the changes, pretty painful. -- 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 an case-insensitive Mac OS X filesystem
On Tue, Sep 11, 2012 at 12:28 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: Erik Faye-Lund kusmab...@gmail.com writes: I have stumbled upon a similar issue on Windows (which also has a case-preserving filesystem), and I seem to remember the solution being something to do with packed refs. Packed-refs use a format like this: $ tail -3 .git/packed-refs e94214ce4b8acefce06d4ea37b76ac0de11ecb2d refs/tags/v1.7.9.5 bf68fe0313c833fa62755176f6e24988ef7cf80f refs/tags/v1.7.9.6 3996bb24c84013ec9ce9fa0980ce61f9ef97be4d refs/tags/v1.7.9.7 so the ref name is stored within the file, not as the file name. So, yes, packing refs (done by git pack-refs, called by git gc among other things) should solve case-insensitive issues. However, creating or updating refs after a pack will still create unpacked refs, so this solves the issue only if one of the colliding branches is not updated anymore. Of course. In my case, the colliding refs weren't fetched from the same source IIRC. Perhaps we could change Git to detect name-collisions and automatically pack the refs in such cases? That's a bit harder than it seems, as the idea is to avoid re-writting the packed-refs file for each ref update. Repacking after each colliding ref update could be costly in terms of performance. Yes, but being costly in terms of performance is IMO a lot better than corrupting refs, which is what we currently do. And it should really only be costly in the case where there's actually such a cost, on a file system where such a collision can happen. -- 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: How to update a cloned git repository
Joachim Schmitz j...@schmitz-digital.de writes: From: Matthieu Moy [mailto:matthieu@grenoble-inp.fr] Short answer: don't work on pu. Work on master unless you have a good reason not to. There are some changes in pu, that I need as the basis, namely my setitimer patch and my 2nd mkdir patch, which haven't yet made it into the master branch (and in the setitimer case not out of pu) Then, work on the tip of the topic branch you depend on instead of pu. These are more stable, as they will be rewritten only if this particular topic branch changes. git rebase HEAD~42 --onto origin/master For pu this would be similar? Yes. If you insist in working on top of pu, you can rebase --onto origin/pu. Like this? git pull --rebase HEAD~42 That would be git fetch and then git rebase, as I don't think git pull --rebase would allow you to specify the starting point for rebase. So far I create patches, wiped out the entire repository, cloned, forked and applied the changes, pretty painful. This is conceptually similar to what git rebase does, but it does it in a slightly more efficient way ;-). -- 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: Git an case-insensitive Mac OS X filesystem
Erik Faye-Lund kusmab...@gmail.com writes: Yes, but being costly in terms of performance is IMO a lot better than corrupting refs, which is what we currently do. I'm not saying nothing should be done, but I'm not sure packed-refs are the right solution in the long term. We already have the foo Vs foo/bar issue (discussed in the keeping reflog for deleted refs discussion). I think the right way would be to re-think the way we map ref name to the filesystem, with proper escaping of capitals, slashes, ... But that's a rather big change to do (and I'm unlikely to be the one volunteering for it :-( ) -- 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: [PATCH v3 1/4] poll() exits too early with EFAULT if 1st arg is NULL
Joachim Schmitz wrote:
If poll() is used as a milli-second sleep, like in help.c, by passing
a NULL in the 1st and a 0 in the 2nd arg, it exits with EFAULT.
As per Paolo Bonzini, the original author, this is a bug and to be
fixed like in this commit, which is not to exit if the 2nd arg is 0.
Signed-off-by: Joachim Schmitz j...@schmitz-digital.de
---
compat/win32/poll.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/compat/win32/poll.c b/compat/win32/poll.c
index 403eaa7..9e7a25c 100644
--- a/compat/win32/poll.c
+++ b/compat/win32/poll.c
@@ -349,7 +349,7 @@ poll (struct pollfd *pfd, nfds_t nfd, int timeout)
/* EFAULT is not necessary to implement, but let's do it in the
simplest case. */
- if (!pfd)
+ if (!pfd nfd)
{
errno = EFAULT;
return -1;
Actually this one is not needed for win32 (nor does win32 suffer from a
similar bug), so should probably better get added after patch 2/2 (or as
part of it), the move to compat/poll/.
Bye, Jojo
--
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] completion: git branch --set-upstream-to=
Remove the deprecated --set-upstream from completion suggestions and add
the new --set-upstream-to=, offering all refs for completion like in
similar cases.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
contrib/completion/git-completion.bash | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 222b804..625d767 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -875,11 +875,14 @@ _git_branch ()
done
case $cur in
+ --set-upstream-to=*)
+ __gitcomp $(__git_refs) ${cur##--set-upstream-to=}
+ ;;
--*)
__gitcomp
--color --no-color --verbose --abbrev= --no-abbrev
--track --no-track --contains --merged --no-merged
- --set-upstream --edit-description --list
+ --set-upstream-to= --edit-description --list
;;
*)
--
1.7.12.443.g84e0989
--
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-svn mergeinfo
Hello, I am using git 1.7.10.4 from Debian. I just tried svn.pushmergeinfo and it seems to have worked fine, great. Now I am trying to understand what the doc says about this: Currently, this can only be done when dcommitting non-fast-forward merges where all parents but the first have already been pushed into SVN. all parents but the first have already been pushed into SVN means that merging A into B requires to dcommit in A first, right? non-fast-forward means that both branches got some commits since the last merge, right? Could we add an example after the above doc sentence? Something like For instance, if merging SVN branch B into A, make sure you dcommit A first, and check that both A and B got new commits since the last merge (or since B was created from A). Brice -- 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: How to update a cloned git repository
[ Re-adding git@vger in Cc, I guess it was meant to be so ] Joachim Schmitz j...@schmitz-digital.de writes: Then, work on the tip of the topic branch you depend on instead of pu. These are more stable, as they will be rewritten only if this particular topic branch changes. These are not available from git hub. Or are they? How? I think they exist in some of the repos junio pushes to, but I don't remember how/which one. Anyway, you can easily get it from the commit that merges the branch (it's the-merge-commit^1). Like this? git pull --rebase HEAD~42 That would be git fetch and then git rebase, as I don't think git pull --rebase would allow you to specify the starting point for rebase. OK, I'll try that next time then. Like this? git fetch;git rebase HEAD~42 --onto origin/pu That should work, yes. In general, when you have a somehow complex workflow, I recommand fetch+(merge|rebase) over pull. It gives you more flexibility, and the opportunity to check what you fetched before starting the merge. So far I create patches, wiped out the entire repository, cloned, forked and applied the changes, pretty painful. This is conceptually similar to what git rebase does, but it does it in a slightly more efficient way ;-). Indeed ;-) -- 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: How to update a cloned git repository
From: Matthieu Moy [mailto:matthieu@grenoble-inp.fr] Sent: Tuesday, September 11, 2012 2:41 PM To: Joachim Schmitz Cc: git Subject: Re: How to update a cloned git repository [ Re-adding git@vger in Cc, I guess it was meant to be so ] Oops, yes it was meant to. Joachim Schmitz j...@schmitz-digital.de writes: Then, work on the tip of the topic branch you depend on instead of pu. These are more stable, as they will be rewritten only if this particular topic branch changes. These are not available from git hub. Or are they? How? I think they exist in some of the repos junio pushes to, but I don't remember how/which one. Anyway, you can easily get it from the commit that merges the branch (it's the-merge-commit^1). Like this? git pull --rebase HEAD~42 That would be git fetch and then git rebase, as I don't think git pull --rebase would allow you to specify the starting point for rebase. OK, I'll try that next time then. Like this? git fetch;git rebase HEAD~42 --onto origin/pu That should work, yes. In general, when you have a somehow complex workflow, I recommand fetch+(merge|rebase) over pull. It gives you more flexibility, and the opportunity to check what you fetched before starting the merge. OK, thanks. I'm sure I'll have more questions later though ;-) -- 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: How to update a cloned git repository
On Tue, Sep 11, 2012 at 2:40 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: [ Re-adding git@vger in Cc, I guess it was meant to be so ] Joachim Schmitz j...@schmitz-digital.de writes: Then, work on the tip of the topic branch you depend on instead of pu. These are more stable, as they will be rewritten only if this particular topic branch changes. These are not available from git hub. Or are they? How? I think they exist in some of the repos junio pushes to, but I don't remember how/which one. You can usually find them here: https://github.com/gitster/git/branches And Joachim's branch in particular: https://github.com/gitster/git/tree/js/compat-itimer -- 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 0/2] git describe --first-parent
While git describe behaves as documented, the notion of most recent tag is not really easy to grab, and it's not always the way you want to describe a commit. --first-parent is the option which answers the question: Which is the most recent tag on this branch which can be reached from this commit? (This branch being defined as --first-parent walk.) I had suggested this before, but the discussion veered off quite a bit: http://permalink.gmane.org/gmane.comp.version-control.git/156811 No need to discuss the way git describe behaves again ;) Michael J Gruber (2): git-describe: introduce --first-parent describe: document and test --first-parent Documentation/git-describe.txt | 16 +++- builtin/describe.c | 8 +++- t/t6120-describe.sh| 7 +++ 3 files changed, 29 insertions(+), 2 deletions(-) -- 1.7.12.463.gbd9d638 -- 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 2/2] describe: document and test --first-parent
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Documentation/git-describe.txt | 16 +++- t/t6120-describe.sh| 7 +++ 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt index 72d6bb6..9fb5c84 100644 --- a/Documentation/git-describe.txt +++ b/Documentation/git-describe.txt @@ -84,6 +84,10 @@ OPTIONS Only consider tags matching the given pattern (can be used to avoid leaking private tags made from the repository). +--first-parent:: + Only consider tags which can be reached from 'committish' by a first + parent walk, i.e. only those which are not on side branches. + --always:: Show uniquely abbreviated commit object as fallback. @@ -129,6 +133,14 @@ closest tagname without any suffix: [torvalds@g5 git]$ git describe --abbrev=0 v1.0.5^2 tags/v1.0.0 +With --first-parent, tags on side branches are not considered: + + $ git describe v1.1.0^ + v1.0.7-44-ge77f489 + + $ git describe --first-parent v1.1.0^ + v1.0.0-41-ge77f489 + Note that the suffix you get if you type these commands today may be longer than what Linus saw above when he ran these commands, as your git repository may have new commits whose object names begin with @@ -148,7 +160,9 @@ is found, its name will be output and searching will stop. If an exact match was not found, 'git describe' will walk back through the commit history to locate an ancestor commit which has been tagged. The ancestor's tag will be output along with an -abbreviation of the input committish's SHA1. +abbreviation of the input committish's SHA1. With '--first-parent', +'git describe' will walk the history only along the first parent +of each commit. If multiple tags were found during the walk then the tag which has the fewest commits different from the input committish will be diff --git a/t/t6120-describe.sh b/t/t6120-describe.sh index f67aa6f..2524236 100755 --- a/t/t6120-describe.sh +++ b/t/t6120-describe.sh @@ -103,6 +103,13 @@ check_describe c-* --tags HEAD^^2 check_describe B --tags HEAD^^2^ check_describe e --tags HEAD^^^ +check_describe R-* --first-parent HEAD +check_describe R-* --first-parent HEAD^ +check_describe R-* --first-parent HEAD^^ +check_describe B-* --first-parent HEAD^^2 +check_describe B --first-parent HEAD^^2^ +check_describe R-* --first-parent HEAD^^^ + check_describe heads/master --all HEAD check_describe tags/c-* --all HEAD^ check_describe tags/e --all HEAD^^^ -- 1.7.12.463.gbd9d638 -- 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 1/2] git-describe: introduce --first-parent
so that git-describe searches first-parent history only when looking for
a named commit. This is useful for describing commits by tags on their
main (first-parent) branch; for example, on git.git:
git describe 22ffc39
v1.7.2.3-223-g22ffc39
git describe --first-parent 22ffc39
v1.7.2-104-g22ffc39
git describe --contains --first-parent is forbidden because git name-rev
(which is called by that) favors first-parent transversal already,
although not strictly so.
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
---
builtin/describe.c | 8 +++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/builtin/describe.c b/builtin/describe.c
index 9fe11ed..aa60f5c 100644
--- a/builtin/describe.c
+++ b/builtin/describe.c
@@ -25,6 +25,7 @@ static int abbrev = -1; /* unspecified */
static int max_candidates = 10;
static struct hash_table names;
static int have_util;
+static int first_parent;
static const char *pattern;
static int always;
static const char *dirty;
@@ -336,7 +337,7 @@ static void describe(const char *arg, int last_one)
if (!(p-object.flags SEEN))
commit_list_insert_by_date(p, list);
p-object.flags |= c-object.flags;
- parents = parents-next;
+ parents = first_parent ? NULL : parents-next;
}
}
@@ -414,6 +415,8 @@ int cmd_describe(int argc, const char **argv, const char
*prefix)
N_(only consider tags matching pattern)),
OPT_BOOLEAN(0, always, always,
N_(show abbreviated commit object as fallback)),
+ OPT_BOOLEAN(0, first-parent, first_parent,
+ follow first parents only),
{OPTION_STRING, 0, dirty, dirty, N_(mark),
N_(append mark on dirty working tree (default:
\-dirty\)),
PARSE_OPT_OPTARG, NULL, (intptr_t) -dirty},
@@ -435,6 +438,9 @@ int cmd_describe(int argc, const char **argv, const char
*prefix)
if (longformat abbrev == 0)
die(_(--long is incompatible with --abbrev=0));
+ if (contains first_parent)
+ die(_(--contains is incompatible with --first-parent));
+
if (contains) {
const char **args = xmalloc((7 + argc) * sizeof(char *));
int i = 0;
--
1.7.12.463.gbd9d638
--
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: How to update a cloned git repository
On Tue, Sep 11, 2012 at 4:47 PM, Joachim Schmitz j...@schmitz-digital.de wrote: Like this? git pull --rebase HEAD~42 So far I create patches, wiped out the entire repository, cloned, forked and applied the changes, pretty painful. I think a 'git pull --rebase' should usually work even for 'pu'. But sometimes pu may have changes that take away the basis for your patch (i.e, not just a restructure) then you'd get conflicts. -- 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] clear_child_for_cleanup must correctly manage children_to_clean
Iterate through children_to_clean using 'next' fields but with an
extra level of indirection. This allows us to update the chain when
we remove a child and saves us managing several variables around
the loop mechanism.
---
run-command.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/run-command.c b/run-command.c
index f9922b9..c42d63b 100644
--- a/run-command.c
+++ b/run-command.c
@@ -53,13 +53,13 @@ static void mark_child_for_cleanup(pid_t pid)
static void clear_child_for_cleanup(pid_t pid)
{
- struct child_to_clean **last, *p;
+ struct child_to_clean **pp;
- last = children_to_clean;
- for (p = children_to_clean; p; p = p-next) {
- if (p-pid == pid) {
- *last = p-next;
- free(p);
+ for (pp = children_to_clean; *pp; pp = (*pp)-next) {
+ if ((*pp)-pid == pid) {
+ struct child_to_clean *clean_me = *pp;
+ *pp = clean_me-next;
+ free(clean_me);
return;
}
}
--
1.7.9.5
--
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] rev-list/log: document logic with several limiting options
The current behavior is probably as useful as it is confusing. In any case it is going to stay. So, document it. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- I would have written a test but don't really know where to stick it in. rev-list has many small tests where it doesn't fit. Documentation/rev-list-options.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 5436eba..9c13df3 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -6,6 +6,12 @@ special notations explained in the description, additional commit limiting may be applied. Note that they are applied before commit ordering and formatting options, such as '--reverse'. +All occurrences of the same option are ORed: '--grep=foo --grep=bar' +limits to commits which match at least one of these conditions. + +Different options are ANDed: '--author=bar --grep=foo' +limits to commits which match both conditions. + -- -n 'number':: -- 1.7.12.463.gbd9d638 -- 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: Should GIT_AUTHOR_{NAME,EMAIL} set the tagger name/email?
On Sat, Sep 1, 2012 at 6:12 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Ævar Arnfjörð Bjarmason ava...@gmail.com writes:
I don't get what you mean, what committer info?
GIT_COMMITTER_{NAME,EMAIL}. A tagger isn't really an author.
Ah, am I the only one that finds that a bit counterintuitive to the
point of wanting to submit a patch to change it?
If you've created a tag you're the *author* of that tag, the
author/committer distinction for commit objects is there for e.g.
rebases and applying commits via e.g. git-am.
We don't have a similar facility for tags (you have to push them
around directly), but we *could* and in that case having a
Tag-Committer as well well as a Tagger would make sense.
Junio, what do you think?
--
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] clear_child_for_cleanup must correctly manage children_to_clean
On Tue, Sep 11, 2012 at 03:32:47PM +0100, David Gould wrote:
Subject: Re: [PATCH] clear_child_for_cleanup must correctly manage
children_to_clean
Thanks for the patch. Overall it looks good, but let me nit-pick your
commit message a little (not because it is that horrible, but because
you are so close to perfect that I want to fix the minor things and then
encourage you to submit more patches :) ).
Your subject is a bit vague, and it is not clear if it is not correct
now, and this is a bugfix, or if it is a feature enhancement. I would
have said something like:
Subject: fix broken list iteration in clear_child_for_cleanup
which is _also_ vague about what exactly the breakage is, but is clear
that this is a bugfix. So then you can go on to describe the actual
problem:
We iterate through the list of children to cleanup, but do not keep
our last pointer up to date. As a result, we may end up cutting off
part of the list instead of removing a single element.
And then describe your fix:
Iterate through children_to_clean using 'next' fields but with an
extra level of indirection. This allows us to update the chain when
we remove a child and saves us managing several variables around
the loop mechanism.
which I think is good.
- last = children_to_clean;
- for (p = children_to_clean; p; p = p-next) {
- if (p-pid == pid) {
- *last = p-next;
- free(p);
+ for (pp = children_to_clean; *pp; pp = (*pp)-next) {
+ if ((*pp)-pid == pid) {
+ struct child_to_clean *clean_me = *pp;
+ *pp = clean_me-next;
+ free(clean_me);
return;
}
I think using the indirect pointer is a nice compromise; it makes it
clear from just the for loop that this is not an ordinary for-each
traversal. You could hoist the extra pointer out of the conditional and
save one set of parentheses in the if statement, but I don't think it
is a big deal either way.
Acked-by: Jeff King p...@peff.net
Thanks for the bug report and the patch.
-Peff
--
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] clear_child_for_cleanup must correctly manage children_to_clean
On Tue, Sep 11, 2012 at 4:32 PM, David Gould da...@optimisefitness.com wrote:
Iterate through children_to_clean using 'next' fields but with an
extra level of indirection. This allows us to update the chain when
we remove a child and saves us managing several variables around
the loop mechanism.
---
run-command.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/run-command.c b/run-command.c
index f9922b9..c42d63b 100644
--- a/run-command.c
+++ b/run-command.c
@@ -53,13 +53,13 @@ static void mark_child_for_cleanup(pid_t pid)
static void clear_child_for_cleanup(pid_t pid)
{
- struct child_to_clean **last, *p;
+ struct child_to_clean **pp;
- last = children_to_clean;
- for (p = children_to_clean; p; p = p-next) {
- if (p-pid == pid) {
- *last = p-next;
- free(p);
+ for (pp = children_to_clean; *pp; pp = (*pp)-next) {
+ if ((*pp)-pid == pid) {
+ struct child_to_clean *clean_me = *pp;
+ *pp = clean_me-next;
+ free(clean_me);
return;
}
}
--
1.7.9.5
Looks good to me. 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: Interactive rebase with pre-built script?
Peter Krefting pe...@softwolves.pp.se writes: I was thinking about using git cherry-pick with a list of commits, rebase is better at helping with conflicts and such. Because the three-way merge done by rebase is exactly the same as cherry-pick, I do not think I understand the reasoning behind this statement at all. After the command gives you control back asking for your help to resolve conflicted merge, the sequencing rebase gives is certainly better than a hand-rolled loop: git rev-list --reverse . | while read commit do git cherry-pick $commit || break done though. Using git cherry-pick $(git rev-list --reverse .) ought to work. It may misbehave only if you have a time skewed commits, but the 'mz/cherry-pick-cmdline-order' topic recently fixed (it is in 'master' and will be in 1.8.0). -- 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 an case-insensitive Mac OS X filesystem
Roger Pau Monné roger@entel.upc.edu writes: Hello, I'm using git for all my projects, and I usually work under Mac OS X with the default filesystem (that's case-insensitive, but case-preserving). I'm currently working on a project that has several branches, and two of them are called origin/DHCPCD and origin/dhcpcd respectively, that's unfortunate, but I cannot do anything about it. This completely breaks the git repository, because .git/refs/remotes/origin/DHCPD and .git/refs/remotes/origin/dhcpd are actually the same file, so when I try to update my repository performing a git pull I get the following error: error: Ref refs/remotes/origin/dhcpcd is at 6b371783de2def2d6e3ec2680ba731f7086067ee but expected 79f701ce599a27043eed8343f76406014963278a So I was wondering if anyone has stumbled upon this issue, and what's the best approach to fix it. If several is manageably small, you can configure your refspecs to rename them, e.g. [remote origin] url = ... fetch = +refs/heads/master:refs/remotes/origin/master fetch = +refs/heads/dhcpcd:refs/remotes/origin/dhcpcd fetch = +refs/heads/DHCPCD:refs/remotes/origin/dhcpcd-u which tells $ git fetch origin to use your remote tracking branch origin/dhcpcd-u to copy from their DHCPCD. Then you can work on it the usual way. $ git checkout -b dhcpcd-u origin/dhcpcd-u $ work work work For pushing, you can rename it back in a similar way. $ git push origin dhcpcd-u:DHCPCD which is a short-hand for $ git push origin refs/heads/dhcpcd-u:refs/heads/DHCPCD -- 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 an case-insensitive Mac OS X filesystem
Roger Pau Monné roger@entel.upc.edu writes: I understood this, it's just that I would prefer to avoid doing this kind if things, I would prefer to be able to work natively on my filesystem, but it seems like there's no other option. If you are unwilling to keep both lowercase and uppercase separately on your end, and if the other side (the project you are interacting with) wants you to have both, then I do not think there is any way to resolve such conflict between you and your project. -- 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 1/2] build: improve GIT_CONF_SUBST signature
Now, in configure.ac, a call like:
GIT_CONF_SUBST([FOO])
will be considered equivalent to:
GIT_CONF_SUBST([FOO], [$FOO])
This is mostly a preparatory refactoring in view of future changes.
No semantic change to the generated configure or config.mak.auto is
intended.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
configure.ac | 15 ---
1 file changed, 8 insertions(+), 7 deletions(-)
diff --git a/configure.ac b/configure.ac
index df7e376..450bbe7 100644
--- a/configure.ac
+++ b/configure.ac
@@ -7,8 +7,9 @@
#
# Cause the line VAR=VAL to be eventually appended to ${config_file}.
AC_DEFUN([GIT_CONF_SUBST],
- [AC_REQUIRE([GIT_CONF_SUBST_INIT])
- config_appended_defs=$config_appended_defs${newline}$1=$2])
+[AC_REQUIRE([GIT_CONF_SUBST_INIT])
+config_appended_defs=$config_appended_defs${newline}dnl
+$1=m4_if([$#],[1],[${$1}],[$2])])
# GIT_CONF_SUBST_INIT
# ---
@@ -179,7 +180,7 @@ AC_ARG_WITH([lib],
else
lib=$withval
AC_MSG_NOTICE([Setting lib to '$lib'])
- GIT_CONF_SUBST([lib], [$withval])
+ GIT_CONF_SUBST([lib])
fi])
if test -z $lib; then
@@ -215,7 +216,7 @@ AC_ARG_ENABLE([jsmin],
[
JSMIN=$enableval;
AC_MSG_NOTICE([Setting JSMIN to '$JSMIN' to enable JavaScript minifying])
- GIT_CONF_SUBST([JSMIN], [$enableval])
+ GIT_CONF_SUBST([JSMIN])
])
# Define option to enable CSS minification
@@ -225,7 +226,7 @@ AC_ARG_ENABLE([cssmin],
[
CSSMIN=$enableval;
AC_MSG_NOTICE([Setting CSSMIN to '$CSSMIN' to enable CSS minifying])
- GIT_CONF_SUBST([CSSMIN], [$enableval])
+ GIT_CONF_SUBST([CSSMIN])
])
## Site configuration (override autodetection)
@@ -265,8 +266,8 @@ AS_HELP_STRING([], [ARG can be also prefix for
libpcre library and hea
else
USE_LIBPCRE=YesPlease
LIBPCREDIR=$withval
- AC_MSG_NOTICE([Setting LIBPCREDIR to $withval])
- GIT_CONF_SUBST([LIBPCREDIR], [$withval])
+ AC_MSG_NOTICE([Setting LIBPCREDIR to $LIBPCREDIR])
+ GIT_CONF_SUBST([LIBPCREDIR])
fi)
#
# Define NO_CURL if you do not have curl installed. git-http-pull and
--
1.7.12.317.g1c54b74
--
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 2/2] build: don't duplicate substitution of make variables
Thanks to our 'GIT_CONF_SUBST' layer in configure.ac, a make variable 'VAR'
can be defined to a value 'VAL' at ./configure runtime in our build system
simply by using GIT_CONF_SUBST([VAR], [VAL]) in configure.ac, rather than
having both to call AC_SUBST([VAR], [VAL]) in configure.ac and adding the
'VAR = @VAR@' definition in config.mak.in. Less duplication, less margin
for error, less possibility of confusion.
While at it, fix some formatting issues in configure.ac that unnecessarily
obscured the code flow.
Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com
---
config.mak.in | 49
configure.ac | 144 +++---
2 files changed, 76 insertions(+), 117 deletions(-)
diff --git a/config.mak.in b/config.mak.in
index 802d342..69d4838 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -5,12 +5,10 @@ CC = @CC@
CFLAGS = @CFLAGS@
CPPFLAGS = @CPPFLAGS@
LDFLAGS = @LDFLAGS@
-CC_LD_DYNPATH = @CC_LD_DYNPATH@
AR = @AR@
TAR = @TAR@
DIFF = @DIFF@
#INSTALL = @INSTALL@ # needs install-sh or install.sh in sources
-TCLTK_PATH = @TCLTK_PATH@
prefix = @prefix@
exec_prefix = @exec_prefix@
@@ -27,50 +25,3 @@ VPATH = @srcdir@
export exec_prefix mandir
export srcdir VPATH
-
-NEEDS_SSL_WITH_CRYPTO=@NEEDS_SSL_WITH_CRYPTO@
-NO_OPENSSL=@NO_OPENSSL@
-NO_CURL=@NO_CURL@
-NO_EXPAT=@NO_EXPAT@
-NO_LIBGEN_H=@NO_LIBGEN_H@
-HAVE_PATHS_H=@HAVE_PATHS_H@
-HAVE_LIBCHARSET_H=@HAVE_LIBCHARSET_H@
-NO_GETTEXT=@NO_GETTEXT@
-LIBC_CONTAINS_LIBINTL=@LIBC_CONTAINS_LIBINTL@
-NEEDS_LIBICONV=@NEEDS_LIBICONV@
-NEEDS_SOCKET=@NEEDS_SOCKET@
-NEEDS_RESOLV=@NEEDS_RESOLV@
-NEEDS_LIBGEN=@NEEDS_LIBGEN@
-NO_SYS_SELECT_H=@NO_SYS_SELECT_H@
-NO_D_INO_IN_DIRENT=@NO_D_INO_IN_DIRENT@
-NO_D_TYPE_IN_DIRENT=@NO_D_TYPE_IN_DIRENT@
-NO_SOCKADDR_STORAGE=@NO_SOCKADDR_STORAGE@
-NO_IPV6=@NO_IPV6@
-NO_HSTRERROR=@NO_HSTRERROR@
-NO_STRCASESTR=@NO_STRCASESTR@
-NO_STRTOK_R=@NO_STRTOK_R@
-NO_FNMATCH=@NO_FNMATCH@
-NO_FNMATCH_CASEFOLD=@NO_FNMATCH_CASEFOLD@
-NO_MEMMEM=@NO_MEMMEM@
-NO_STRLCPY=@NO_STRLCPY@
-NO_UINTMAX_T=@NO_UINTMAX_T@
-NO_STRTOUMAX=@NO_STRTOUMAX@
-NO_SETENV=@NO_SETENV@
-NO_UNSETENV=@NO_UNSETENV@
-NO_MKDTEMP=@NO_MKDTEMP@
-NO_MKSTEMPS=@NO_MKSTEMPS@
-NO_INET_NTOP=@NO_INET_NTOP@
-NO_INET_PTON=@NO_INET_PTON@
-NO_ICONV=@NO_ICONV@
-OLD_ICONV=@OLD_ICONV@
-NO_REGEX=@NO_REGEX@
-USE_LIBPCRE=@USE_LIBPCRE@
-NO_DEFLATE_BOUND=@NO_DEFLATE_BOUND@
-INLINE=@INLINE@
-SOCKLEN_T=@SOCKLEN_T@
-FREAD_READS_DIRECTORIES=@FREAD_READS_DIRECTORIES@
-SNPRINTF_RETURNS_BOGUS=@SNPRINTF_RETURNS_BOGUS@
-NO_PTHREADS=@NO_PTHREADS@
-PTHREAD_CFLAGS=@PTHREAD_CFLAGS@
-PTHREAD_LIBS=@PTHREAD_LIBS@
-CHARSET_LIB=@CHARSET_LIB@
diff --git a/configure.ac b/configure.ac
index 450bbe7..da1f41f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -267,6 +267,8 @@ AS_HELP_STRING([], [ARG can be also prefix for
libpcre library and hea
USE_LIBPCRE=YesPlease
LIBPCREDIR=$withval
AC_MSG_NOTICE([Setting LIBPCREDIR to $LIBPCREDIR])
+dnl USE_LIBPCRE can still be modified below, so don't substitute
+dnl it yet.
GIT_CONF_SUBST([LIBPCREDIR])
fi)
#
@@ -387,9 +389,10 @@ AC_MSG_NOTICE([CHECKS for programs])
AC_PROG_CC([cc gcc])
AC_C_INLINE
case $ac_cv_c_inline in
- inline | yes | no) ;;
- *) AC_SUBST([INLINE], [$ac_cv_c_inline]) ;;
+ inline | yes | no) INLINE='';;
+ *) INLINE=$ac_cv_c_inline ;;
esac
+GIT_CONF_SUBST([INLINE])
# which switch to pass runtime path to dynamic libraries to the linker
AC_CACHE_CHECK([if linker supports -R], git_cv_ld_dashr, [
@@ -399,7 +402,7 @@ AC_CACHE_CHECK([if linker supports -R], git_cv_ld_dashr, [
LDFLAGS=${SAVE_LDFLAGS}
])
if test $git_cv_ld_dashr = yes; then
- AC_SUBST(CC_LD_DYNPATH, [-R])
+ CC_LD_DYNPATH=-R
else
AC_CACHE_CHECK([if linker supports -Wl,-rpath,], git_cv_ld_wl_rpath, [
SAVE_LDFLAGS=${LDFLAGS}
@@ -408,7 +411,7 @@ else
LDFLAGS=${SAVE_LDFLAGS}
])
if test $git_cv_ld_wl_rpath = yes; then
- AC_SUBST(CC_LD_DYNPATH, [-Wl,-rpath,])
+ CC_LD_DYNPATH=-Wl,-rpath
else
AC_CACHE_CHECK([if linker supports -rpath], git_cv_ld_rpath, [
SAVE_LDFLAGS=${LDFLAGS}
@@ -417,32 +420,35 @@ else
LDFLAGS=${SAVE_LDFLAGS}
])
if test $git_cv_ld_rpath = yes; then
- AC_SUBST(CC_LD_DYNPATH, [-rpath])
+ CC_LD_DYNPATH=-rpath
else
+ CC_LD_DYNPATH=
AC_MSG_WARN([linker does not support runtime path to dynamic
libraries])
fi
fi
fi
+GIT_CONF_SUBST([CC_LD_DYNPATH])
#AC_PROG_INSTALL # needs install-sh or install.sh in sources
AC_CHECK_TOOLS(AR, [gar ar], :)
AC_CHECK_PROGS(TAR, [gtar tar])
AC_CHECK_PROGS(DIFF, [gnudiff gdiff diff])
# TCLTK_PATH will be set to some value if we want Tcl/Tk
# or will be empty otherwise.
-if test -z $NO_TCLTK; then
+if test -n $NO_TCLTK; then
+ TCLTK_PATH=
+else
if test $with_tcltk = ; then
# No Tcl/Tk switches given. Do not check
Re: How to update a cloned git repository
Joachim Schmitz j...@schmitz-digital.de writes: From: Matthieu Moy [mailto:matthieu@grenoble-inp.fr] .. Short answer: don't work on pu. Work on master unless you have a good reason not to. There are some changes in pu, that I need as the basis, namely my setitimer patch and my 2nd mkdir patch, which haven't yet made it into the master branch (and in the setitimer case not out of pu) And that is not a good reason, either. In general, it is a good habit to get into to base your changes on the oldest point release they may want to be used with. For example, if you really wanted to, you could make sure your Tandem changes can be back-merged all the way down to v1.7.6 by forking your own branch from there, queuing your changes like mkdir, itimer on top. And you develop and test your changes on that branch, without pulling from or rebasing it on top of my tree where random other things happen that won't affect you an iota. A recent change to add the new --set-upstream-to option to branch command does not have any platform-specific bits, and for the purpose of the port to Tandem topic, keeping up to date with such a change in my tree is pointless, for example. To make sure that the result is still usable with recent releases, you can create a throw-away merge between your work (that is forked from a stable base) and my tip every once in a while, test the result, and discard the throw-away merge when you are done. Any breakage in your series you find in such an integration test is to be fixed on your branch, not on top of such a throw-away merge. It might be the case that nobody cares if the resulting patches will not apply to and usable with 'master' or older integration branches, so in the particular case of Tandem, choosing a stable fork point that is older than 'master' may not make much sense, though. -- 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: How to update a cloned git repository
Matthieu Moy matthieu@grenoble-inp.fr writes: [ Re-adding git@vger in Cc, I guess it was meant to be so ] Joachim Schmitz j...@schmitz-digital.de writes: Then, work on the tip of the topic branch you depend on instead of pu. These are more stable, as they will be rewritten only if this particular topic branch changes. These are not available from git hub. Or are they? How? I think they exist in some of the repos junio pushes to, but I don't remember how/which one. Anyway, you can easily get it from the commit that merges the branch (it's the-merge-commit^1). I think it is the-merge-commit^2; contrib/git-resurrect.sh might be of interest, too. -- 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] rev-list/log: document logic with several limiting options
Michael J Gruber g...@drmicha.warpmail.net writes: The current behavior is probably as useful as it is confusing. In any case it is going to stay. So, document it. Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- I would have written a test but don't really know where to stick it in. rev-list has many small tests where it doesn't fit. git log would be the more natural place, I would say. Documentation/rev-list-options.txt | 6 ++ 1 file changed, 6 insertions(+) diff --git a/Documentation/rev-list-options.txt b/Documentation/rev-list-options.txt index 5436eba..9c13df3 100644 --- a/Documentation/rev-list-options.txt +++ b/Documentation/rev-list-options.txt @@ -6,6 +6,12 @@ special notations explained in the description, additional commit limiting may be applied. Note that they are applied before commit ordering and formatting options, such as '--reverse'. +All occurrences of the same option are ORed: '--grep=foo --grep=bar' +limits to commits which match at least one of these conditions. How would this interact with --all-match? -- 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] git-describe: introduce --first-parent
Michael J Gruber g...@drmicha.warpmail.net writes: so that git-describe searches first-parent history only when looking for Please make sure your first paragraph of the log message start with a full sentence, not an incomplete tail part of a sentence as if the title of the commit were repeated in front of it. a named commit. This is useful for describing commits by tags on their main (first-parent) branch; for example, on git.git: This is useful only when the history does not have fast-forward merges from a sideline; otherwise it will produce unexpected results, no? git describe 22ffc39 v1.7.2.3-223-g22ffc39 git describe --first-parent 22ffc39 v1.7.2-104-g22ffc39 The output is wrong in that 22ffc39 is v1.7.2-336-g22ffc39, not 104. Putting an arbitrary number that can change depending on how the traversal went will close the door to possible follow-up work on the recent sha1-name-more series (0958a24^2, most importantly aa1dec9e) to prolong the shelf-life of describe output by filtering candidate commits with reachability from the tag and the number of commits from the tag. In any case, it is not clear to me if this is a useful example to help readers of this commit to understand why this new feature is useful. 22ffc39 was created to mark that the work done for 1.7.2.x maintenance track back then were all contained in the 'master' by merging 'maint' when it was pointing at v1.7.2.3. Saying the commit is newer than v1.7.2.3 gives more information than it is newer than v1.7.2, as by convention v1.7.2 must be older than v1.7.2.3, no? -- 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: How to update a cloned git repository
-Original Message- From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, September 11, 2012 6:01 PM To: Joachim Schmitz Cc: 'Matthieu Moy'; git@vger.kernel.org Subject: Re: How to update a cloned git repository Joachim Schmitz j...@schmitz-digital.de writes: From: Matthieu Moy [mailto:matthieu@grenoble-inp.fr] .. Short answer: don't work on pu. Work on master unless you have a good reason not to. There are some changes in pu, that I need as the basis, namely my setitimer patch and my 2nd mkdir patch, which haven't yet made it into the master branch (and in the setitimer case not out of pu) And that is not a good reason, either. In general, it is a good habit to get into to base your changes on the oldest point release they may want to be used with. For example, if you really wanted to, you could make sure your Tandem changes can be back-merged all the way down to v1.7.6 by forking The first version I ever made available for NonStop is 1.5.12, so no reason for me to go back. On the other hand I see nothing in my patches that would not easily backport to much older releases, as the code I touched is either newly created by me (e.g. compat/mkdir.c) or pretty old (compar/win32/poll.c). your own branch from there, queuing your changes like mkdir, itimer on top. And you develop and test your changes on that branch, without pulling from or rebasing it on top of my tree where random other things happen that won't affect you an iota. A recent change to add the new --set-upstream-to option to branch command does not have any platform-specific bits, and for the purpose of the port to Tandem topic, keeping up to date with such a change in my tree is pointless, for example. To make sure that the result is still usable with recent releases, you can create a throw-away merge between your work (that is forked from a stable base) and my tip every once in a while, test the result, and discard the throw-away merge when you are done. Any breakage in your series you find in such an integration test is to be fixed on your branch, not on top of such a throw-away merge. It might be the case that nobody cares if the resulting patches will not apply to and usable with 'master' or older integration branches, so in the particular case of Tandem, choosing a stable fork point that is older than 'master' may not make much sense, though. My goal here is that the next stable release has as much of my patches integrated as possible, so I have much less work when porting, ideals just hitting 'make'... So far my poll patches are still needed. And then, but not earlier, my plain NonStop specific ones (like a section in Makefile and some adjustments in git-compat-utils.h) , these don't make much sense earlier. Bye, Jojo -- 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: How to update a cloned git repository
From: Junio C Hamano [mailto:gits...@pobox.com] Sent: Tuesday, September 11, 2012 6:06 PM To: Matthieu Moy Cc: Joachim Schmitz; git Subject: Re: How to update a cloned git repository Matthieu Moy matthieu@grenoble-inp.fr writes: [ Re-adding git@vger in Cc, I guess it was meant to be so ] Joachim Schmitz j...@schmitz-digital.de writes: Then, work on the tip of the topic branch you depend on instead of pu. These are more stable, as they will be rewritten only if this particular topic branch changes. These are not available from git hub. Or are they? How? I think they exist in some of the repos junio pushes to, but I don't remember how/which one. Anyway, you can easily get it from the commit that merges the branch (it's the-merge-commit^1). I think it is the-merge-commit^2; contrib/git-resurrect.sh might be of interest, too. Sorry you lost me, this is greek to me... -- 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: Should GIT_AUTHOR_{NAME,EMAIL} set the tagger name/email?
Ævar Arnfjörð Bjarmason ava...@gmail.com writes:
On Sat, Sep 1, 2012 at 6:12 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Ævar Arnfjörð Bjarmason ava...@gmail.com writes:
I don't get what you mean, what committer info?
GIT_COMMITTER_{NAME,EMAIL}. A tagger isn't really an author.
Ah, am I the only one that finds that a bit counterintuitive to the
point of wanting to submit a patch to change it?
If you've created a tag you're the *author* of that tag, the
author/committer distinction for commit objects is there for e.g.
rebases and applying commits via e.g. git-am.
We don't have a similar facility for tags (you have to push them
around directly), but we *could* and in that case having a
Tag-Committer as well well as a Tagger would make sense.
Junio, what do you think?
Unless your name is Linus Torvalds and it is early in year 2005, I
wouldn't even think about it.
When we introduced tagger name can be overriden with environment,
we could have added GIT_TAGGER_{NAME,EMAIL}, but we didn't. Given
that tagging happens far far less often than committing, I think it
was a sensible thing to do.
It is a perfectly normal thing in Git for you to commit a patch
authored by other people on behalf of them (and that is why AUTHOR
exists as a separate name from the committer), but you still stand
behind the commits you create by setting COMMITTER of them to you.
The fact that it was _you_ who create the tag has similar weight
that you have your name as the committer in commit objects, so in
that sense, I think the semantics used for the name in tag is far
closer to COMMITTER than AUTHOR.
I guess I wouldn't mind too much if git tag learned a --tagger
option, and honored GIT_TAGGER_{NAME,EMAIL} if set (and otherwise,
fall back to GIT_COMMITTER_{NAME,EMAIL}), but I do not know if it is
worth it. How often would you want to _lie_ about your identity
when you are tagging, and what legitimate reason do you have for
doing so?
--
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: Should GIT_AUTHOR_{NAME,EMAIL} set the tagger name/email?
On 11 September 2012 18:53, Junio C Hamano gits...@pobox.com wrote:
Ævar Arnfjörð Bjarmason ava...@gmail.com writes:
On Sat, Sep 1, 2012 at 6:12 PM, Andreas Schwab sch...@linux-m68k.org wrote:
Ævar Arnfjörð Bjarmason ava...@gmail.com writes:
I don't get what you mean, what committer info?
GIT_COMMITTER_{NAME,EMAIL}. A tagger isn't really an author.
Ah, am I the only one that finds that a bit counterintuitive to the
point of wanting to submit a patch to change it?
If you've created a tag you're the *author* of that tag, the
author/committer distinction for commit objects is there for e.g.
rebases and applying commits via e.g. git-am.
We don't have a similar facility for tags (you have to push them
around directly), but we *could* and in that case having a
Tag-Committer as well well as a Tagger would make sense.
Junio, what do you think?
Unless your name is Linus Torvalds and it is early in year 2005, I
wouldn't even think about it.
When we introduced tagger name can be overriden with environment,
we could have added GIT_TAGGER_{NAME,EMAIL}, but we didn't. Given
that tagging happens far far less often than committing, I think it
was a sensible thing to do.
It is a perfectly normal thing in Git for you to commit a patch
authored by other people on behalf of them (and that is why AUTHOR
exists as a separate name from the committer), but you still stand
behind the commits you create by setting COMMITTER of them to you.
The fact that it was _you_ who create the tag has similar weight
that you have your name as the committer in commit objects, so in
that sense, I think the semantics used for the name in tag is far
closer to COMMITTER than AUTHOR.
I guess I wouldn't mind too much if git tag learned a --tagger
option, and honored GIT_TAGGER_{NAME,EMAIL} if set (and otherwise,
fall back to GIT_COMMITTER_{NAME,EMAIL}), but I do not know if it is
worth it. How often would you want to _lie_ about your identity
when you are tagging, and what legitimate reason do you have for
doing so?
Interestingly this came up because of the opposite problem. We wanted
to *prevent* users from telling lies about who they are.
IOW, when we do a rollout with git-deploy we want to automatically set
their username from a secondary authenticated source before we create
a rollout tag in their name.
cheers,
Yves
--
perl -Mre=debug -e /just|another|perl|hacker/
--
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] completion: git branch --set-upstream-to=
Thanks; I picked up $gmane/204633 but forgot to queue. -- 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 2/2] describe: document and test --first-parent
Michael J Gruber g...@drmicha.warpmail.net writes: Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net --- Documentation/git-describe.txt | 16 +++- t/t6120-describe.sh| 7 +++ 2 files changed, 22 insertions(+), 1 deletion(-) diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt index 72d6bb6..9fb5c84 100644 --- a/Documentation/git-describe.txt +++ b/Documentation/git-describe.txt @@ -84,6 +84,10 @@ OPTIONS Only consider tags matching the given pattern (can be used to avoid leaking private tags made from the repository). +--first-parent:: + Only consider tags which can be reached from 'committish' by a first + parent walk, i.e. only those which are not on side branches. + [PATCH 1/2] says: git describe --contains --first-parent is forbidden because git name-rev (which is called by that) favors first-parent transversal already, although not strictly so. but the end-users won't read the log message, so something like that need to be here, I guess. But if name-rev does more-or-less first-parent anyway, perhaps simply ignoring --first-parent when doing --contains may make more sense? -- 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 2/2] build: don't duplicate substitution of make variables
Stefano Lattarini stefano.lattar...@gmail.com writes: Thanks to our 'GIT_CONF_SUBST' layer in configure.ac, a make variable 'VAR' can be defined to a value 'VAL' at ./configure runtime in our build system simply by using GIT_CONF_SUBST([VAR], [VAL]) in configure.ac, rather than having both to call AC_SUBST([VAR], [VAL]) in configure.ac and adding the 'VAR = @VAR@' definition in config.mak.in. Less duplication, less margin for error, less possibility of confusion. While at it, fix some formatting issues in configure.ac that unnecessarily obscured the code flow. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- config.mak.in | 49 configure.ac | 144 +++--- 2 files changed, 76 insertions(+), 117 deletions(-) Whoa ;-). diff --git a/configure.ac b/configure.ac index 450bbe7..da1f41f 100644 --- a/configure.ac +++ b/configure.ac @@ -267,6 +267,8 @@ AS_HELP_STRING([], [ARG can be also prefix for libpcre library and hea USE_LIBPCRE=YesPlease LIBPCREDIR=$withval AC_MSG_NOTICE([Setting LIBPCREDIR to $LIBPCREDIR]) +dnl USE_LIBPCRE can still be modified below, so don't substitute +dnl it yet. GIT_CONF_SUBST([LIBPCREDIR]) fi) # ... AC_CHECK_FUNC([hstrerror], - [], +[], Is there some consistent policy regarding SP vs HT in the indentation you are using in this patch? These two hunks suggest that you may be favoring spaces, but other places you seem to use tabs, so... -- 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] clear_child_for_cleanup must correctly manage children_to_clean
Jeff King p...@peff.net writes: Thanks for the patch. Overall it looks good, but let me nit-pick your commit message a little (not because it is that horrible, but because you are so close to perfect that I want to fix the minor things and then encourage you to submit more patches :) ). ... Acked-by: Jeff King p...@peff.net Thanks, both. I'd have to ask for a Sign-off, though. -- 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] completion: git branch --set-upstream-to=
Junio C Hamano gits...@pobox.com writes:
Thanks; I picked up $gmane/204633 but forgot to queue.
... so this has been reduced to:
-- 8 --
From: Michael J Gruber g...@drmicha.warpmail.net
Date: Tue, 11 Sep 2012 13:58:30 +0200
Subject: [PATCH] completion: complete branch name for branch
--set-upstream-to=
Signed-off-by: Michael J Gruber g...@drmicha.warpmail.net
Signed-off-by: Junio C Hamano gits...@pobox.com
---
contrib/completion/git-completion.bash | 3 +++
1 file changed, 3 insertions(+)
diff --git a/contrib/completion/git-completion.bash
b/contrib/completion/git-completion.bash
index 4a4d30a..e48cf80 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -875,6 +875,9 @@ _git_branch ()
done
case $cur in
+ --set-upstream-to=*)
+ __gitcomp $(__git_refs) ${cur##--set-upstream-to=}
+ ;;
--*)
__gitcomp
--color --no-color --verbose --abbrev= --no-abbrev
--
1.7.12
--
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 2/2] build: don't duplicate substitution of make variables
On 09/11/2012 07:27 PM, Junio C Hamano wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: Thanks to our 'GIT_CONF_SUBST' layer in configure.ac, a make variable 'VAR' can be defined to a value 'VAL' at ./configure runtime in our build system simply by using GIT_CONF_SUBST([VAR], [VAL]) in configure.ac, rather than having both to call AC_SUBST([VAR], [VAL]) in configure.ac and adding the 'VAR = @VAR@' definition in config.mak.in. Less duplication, less margin for error, less possibility of confusion. While at it, fix some formatting issues in configure.ac that unnecessarily obscured the code flow. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- config.mak.in | 49 configure.ac | 144 +++--- 2 files changed, 76 insertions(+), 117 deletions(-) Whoa ;-). Well, I could have converted one variable at the time, but that seemed an overkill :-) diff --git a/configure.ac b/configure.ac index 450bbe7..da1f41f 100644 --- a/configure.ac +++ b/configure.ac @@ -267,6 +267,8 @@ AS_HELP_STRING([], [ARG can be also prefix for libpcre library and hea USE_LIBPCRE=YesPlease LIBPCREDIR=$withval AC_MSG_NOTICE([Setting LIBPCREDIR to $LIBPCREDIR]) +dnl USE_LIBPCRE can still be modified below, so don't substitute +dnl it yet. GIT_CONF_SUBST([LIBPCREDIR]) fi) # ... AC_CHECK_FUNC([hstrerror], -[], +[], Is there some consistent policy regarding SP vs HT in the indentation you are using in this patch? Basically I'm trying to follow the style of the surrounding code, while keeping in mind that in the Git codebase tabs seem to be preferred to spaces. In this case, the indentation of the following text (that was the meat of the expression) seemed to favour 4 spaces for indentation, so I followed suit. These two hunks suggest that you may be favoring spaces, but other places you seem to use tabs, so... I can convert the new tabs to spaces if you prefer (that would have been my preference too, but thought trying to follow the Git preferences was more important). No big deal either way for me. Thanks, Stefano -- 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 v3] Teach rm to remove submodules unless they contain a git directory
Currently using git rm on a submodule - populated or not - fails with
this error:
fatal: git rm: 'submodule path': Is a directory
This made sense in the past as there was no way to remove a submodule
without possibly removing unpushed parts of the submodule's history
contained in its .git directory too, so erroring out here protected the
user from possible loss of data.
But submodules cloned with a recent git version do not contain the .git
directory anymore, they use a gitfile to point to their git directory
which is safely stored inside the superproject's .git directory. The work
tree of these submodules can safely be removed without loosing history, so
let's teach git to do so.
Using rm on an unpopulated submodule now removes the empty directory from
the work tree and the gitlink from the index. If the submodule's directory
is missing from the work tree, it will still be removed from the index.
Using rm on a populated submodule using a gitfile will apply the usual
checks for work tree modification adapted to submodules (unless forced).
For a submodule that means that the HEAD is the same as recorded in the
index, no tracked files are modified and no untracked files that aren't
ignored are present in the submodules work tree (ignored files are deemed
expendable and won't stop a submodule's work tree from being removed).
That logic has to be applied in all nested submodules too.
Using rm on a submodule which has its .git directory inside the work trees
top level directory will just error out like it did before to protect the
repository, even when forced. In the future git could either provide a
message informing the user to convert the submodule to use a gitfile or
even attempt to do the conversion itself, but that is not part of this
change.
Signed-off-by: Jens Lehmann jens.lehm...@web.de
---
Am 11.09.2012 01:55, schrieb Junio C Hamano:
* jl/submodule-rm (2012-08-27) 1 commit
- Teach rm to remove submodules unless they contain a git directory
git rm submodule cannot blindly remove a submodule directory as
its working tree may have local changes, and worse yet, it may even
have its repository embedded in it. Teach it some special cases
where it is safe to remove a submodule, specifically, when there is
no local changes in the submodule working tree, and its repository
is not embedded in its working tree but is elsewhere and uses the
gitfile mechanism to point at it.
I lost track; what is the doneness of the discussion on this patch?
The review of v2 revealed that in case of submodule merge conflicts
the necessary checks weren't done. This (and the minor issues raised
in http://permalink.gmane.org/gmane.comp.version-control.git/204370)
is fixed in this version.
Documentation/git-rm.txt | 15 +++
builtin/rm.c | 107 ++---
submodule.c | 80 +
submodule.h | 2 +
t/t3600-rm.sh| 291 +++
5 files changed, 480 insertions(+), 15 deletions(-)
diff --git a/Documentation/git-rm.txt b/Documentation/git-rm.txt
index 5d31860..882cb11 100644
--- a/Documentation/git-rm.txt
+++ b/Documentation/git-rm.txt
@@ -107,6 +107,21 @@ as well as modifications of existing paths.
Typically you would first remove all tracked files from the working
tree using this command:
+Submodules
+~~
+Only submodules using a gitfile (which means they were cloned
+with a git version 1.7.8 or newer) will be removed from the work
+tree, as their repository lives inside the .git directory of the
+superproject. If a submodule (or one of those nested inside it)
+still uses a .git directory, `git rm` will fail - no matter if forced
+or not - to protect the submodule's history.
+
+A submodule is considered up-to-date when the HEAD is the same as
+recorded in the index, no tracked files are modified and no untracked
+files that aren't ignored are present in the submodules work tree.
+Ignored files are deemed expendable and won't stop a submodule's work
+tree from being removed.
+
git ls-files -z | xargs -0 rm -f
diff --git a/builtin/rm.c b/builtin/rm.c
index b384c4c..0e7ea7c 100644
--- a/builtin/rm.c
+++ b/builtin/rm.c
@@ -9,6 +9,7 @@
#include cache-tree.h
#include tree-walk.h
#include parse-options.h
+#include submodule.h
static const char * const builtin_rm_usage[] = {
N_(git rm [options] [--] file...),
@@ -17,9 +18,43 @@ static const char * const builtin_rm_usage[] = {
static struct {
int nr, alloc;
- const char **name;
+ struct {
+ const char *name;
+ char is_submodule;
+ } *entry;
} list;
+static int check_submodules_use_gitfiles(void)
+{
+ int i;
+ int errs = 0;
+
+ for (i = 0; i list.nr; i++) {
+ const char *name = list.entry[i].name;
+ int pos;
+ struct cache_entry *ce;
+ struct stat st;
+
+
Re: [ANNOUNCE] tig-1.0
2012/9/7 Jonas Fonseca fons...@diku.dk: On Fri, Sep 7, 2012 at 9:41 AM, Jean-Baptiste Quenot j...@caraldi.com wrote: Hi Jonas, Hello Jean-Baptiste With tig 1.0 how to feed specific revisions to the main view? The following hack worked until tig 0.17: [alias] tignowalk-helper = !git rev-list --pretty=raw --no-walk --stdin TIG_MAIN_CMD=git tignowalk-helper $tmp tig /dev/tty The possibility to specify commands was removed in favor of improving options given on the command line. In this spirit, I suggest to support something like the following: tig --no-walk --stdin tmp-file Would that cover your use case? That would be great! I would then feed tig with all commits I want to see in the main view. Cheers, -- Jean-Baptiste Quenot -- 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] Teach rm to remove submodules unless they contain a git directory
Jens Lehmann jens.lehm...@web.de writes:
* jl/submodule-rm (2012-08-27) 1 commit
- Teach rm to remove submodules unless they contain a git directory
git rm submodule cannot blindly remove a submodule directory as
its working tree may have local changes, and worse yet, it may even
have its repository embedded in it. Teach it some special cases
where it is safe to remove a submodule, specifically, when there is
no local changes in the submodule working tree, and its repository
is not embedded in its working tree but is elsewhere and uses the
gitfile mechanism to point at it.
I lost track; what is the doneness of the discussion on this patch?
The review of v2 revealed that in case of submodule merge conflicts
the necessary checks weren't done. This (and the minor issues raised
in http://permalink.gmane.org/gmane.comp.version-control.git/204370)
is fixed in this version.
Thanks. I wish all others paid attention to What's cooking like
you did here.
And if it is hard to do so for whatever reason, suggest a better way
for me to publish What's cooking or an equivalent (I am interested
in finding the least bureaucratic way to help people and keep the
balls rolling).
+static int check_submodules_use_gitfiles(void)
+{
+ int i;
+ int errs = 0;
+
+ for (i = 0; i list.nr; i++) {
+ const char *name = list.entry[i].name;
+ int pos;
+ struct cache_entry *ce;
+ struct stat st;
+
+ pos = cache_name_pos(name, strlen(name));
+ if (pos 0)
+ pos = -pos-1;
+ ce = active_cache[pos];
+
+ if (!S_ISGITLINK(ce-ce_mode) ||
+ (lstat(ce-name, st) 0) ||
+ is_empty_dir(name))
+ continue;
If the name doesn't exist in the index (i.e. list has names that
do not exist in the index for whatever reason), a negative pos is
returned to tell you where it _would_ be inserted if you said git
add the path. But these names in the list are guaranteed to
exist in the index in _some_ form, so for a negative pos, (-pos-1)
will have the conflicted entry at the lowest stage (typically the
common ancestor's version). I am not sure checking only that one is
sufficient, though. Wouldn't you want to at least check stage #2
(ours, which should most resemble the working tree)? If this were
common ancestor had it as a submodule, our side removed it and
created something else, their side updated the submodule conflict,
the stage #2 would not be a gitlink (it would be a blob if that
something else is a file, or may be missing if the submodule was
replaced with a directory), and the path ce-name would definitely
not be a submodule.
+ if (!submodule_uses_gitfile(name))
+ errs = error(_(submodule '%s' (or one of its nested
+ submodules) uses a .git directory\n
+ (use 'rm -rf' if you really want to
remove
+ it including all of its history)), name);
+ }
+
+ return errs;
+}
+
static int check_local_mod(unsigned char *head, int index_only)
{
/*
@@ -37,15 +72,23 @@ static int check_local_mod(unsigned char *head, int
index_only)
struct stat st;
int pos;
struct cache_entry *ce;
- const char *name = list.name[i];
+ const char *name = list.entry[i].name;
unsigned char sha1[20];
unsigned mode;
int local_changes = 0;
int staged_changes = 0;
pos = cache_name_pos(name, strlen(name));
- if (pos 0)
- continue; /* removing unmerged entry */
+ if (pos 0) {
+ /*
+ * Skip unmerged entries except for populated submodules
+ * that could loose history when removed.
s/loose/lose/
+ */
+ pos = -pos-1;
+ if (!S_ISGITLINK(active_cache[pos]-ce_mode) ||
+ is_empty_dir(name))
+ continue;
+ }
Lilewise. It may make sense to introduce a helper function to tell
if it is a submodule on our side by checking only the stage #2 entry
when you see a nagetive pos returned from cache_name_pos() and call
it is_ours_submodule?() or something.
--
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 2/2] build: don't duplicate substitution of make variables
Stefano Lattarini stefano.lattar...@gmail.com writes: On 09/11/2012 07:27 PM, Junio C Hamano wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: Thanks to our 'GIT_CONF_SUBST' layer in configure.ac, a make variable 'VAR' can be defined to a value 'VAL' at ./configure runtime in our build system simply by using GIT_CONF_SUBST([VAR], [VAL]) in configure.ac, rather than having both to call AC_SUBST([VAR], [VAL]) in configure.ac and adding the 'VAR = @VAR@' definition in config.mak.in. Less duplication, less margin for error, less possibility of confusion. While at it, fix some formatting issues in configure.ac that unnecessarily obscured the code flow. Signed-off-by: Stefano Lattarini stefano.lattar...@gmail.com --- config.mak.in | 49 configure.ac | 144 +++--- 2 files changed, 76 insertions(+), 117 deletions(-) Whoa ;-). Well, I could have converted one variable at the time, but that seemed an overkill :-) No, I was happy to see many lines go ;-) These two hunks suggest that you may be favoring spaces, but other places you seem to use tabs, so... I can convert the new tabs to spaces if you prefer (that would have been my preference too, but thought trying to follow the Git preferences was more important). No big deal either way for me. If this were other parts of the system, my preference would be to use tabs, but because I do not help very much in the autoconf part myself, I do not have a particular preference. If it is more common to indent the configure.ac script with spaces, that would be more familiar to the folks who work on it, and I do not have much against choosing and sticking to space indented configure.ac file if that is the policy. But if this patch is not about cleaning up the style to make it conform to a policy (whichever it is), I would have preferred to see a clean-up patch as a separate step, not mixed together with this. That's all; either way, no big deal. -- 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
[ANNOUNCE] Git v1.7.11.6
A maintenance release Git v1.7.11.6 is now available at the
usual places.
The release tarballs are found at:
http://code.google.com/p/git-core/downloads/list
and their SHA-1 checksums are:
f678531535643806733e8c7e87db77386c48738b git-1.7.11.6.tar.gz
e6ccf6cffa3b69dc5d658f43bb8a10ed70b176f2 git-htmldocs-1.7.11.6.tar.gz
7bbb12429e65184d9462dfc01b104a4780bc67a8 git-manpages-1.7.11.6.tar.gz
Also the following public repositories all have a copy of the v1.7.11.6
tag and the maint-1.7.11 branch that the tag points at:
;; url = git://repo.or.cz/alt-git.git
url = https://code.google.com/p/git-core/
url = git://git.sourceforge.jp/gitroot/git-core/git.git
url = git://git-core.git.sourceforge.net/gitroot/git-core/git-core
url = https://github.com/gitster/git
[repo seems to be having a problem right now]
Git v1.7.11.6 Release Notes
===
Fixes since v1.7.11.5
-
* ciabot script (in contrib/) has been updated with extensive
documentation.
* git foo errored out with Not a directory when the user had a
non-directory on $PATH, and worse yet it masked an alias foo from
running.
* When the user exports a non-default IFS without HT, scripts that
rely on being able to parse ls-files -s | while read a b c...
started to fail. Protect them from such a misconfiguration.
* When the user gives an argument that can be taken as both a
revision name and a pathname without disambiguating with --, we
used to give a help message Use '--' to separate. The message
has been clarified to show where that '--' goes on the command
line.
* Documentation for the configuration file format had a confusing
example.
* Older parts of the documentation described as if having a regular
file in .git/refs/ hierarchy were the only way to have branches and
tags, which is not true for quite some time.
* It was generally understood that --long-options to many of our
subcommands can be abbreviated to the unique prefix, but it was not
easy to find it described for new readers of the documentation set.
* The --topo-order, --date-order (and the lack of either means
the default order) options to rev-list and log family of
commands were poorly described in the documentation.
* git commit --amend let the user edit the log message and then
died when the human-readable committer name was given
insufficiently by getpwent(3).
* The exit status code from git config was way overspecified while
being incorrect. The implementation has been updated to give the
documented status for a case that was documented, and introduce a
new code for all other errors.
* The output from git diff -B for a file that ends with an
incomplete line did not put \ No newline... on a line of its own.
* git diff had a confusion between taking data from a path in the
working tree and taking data from an object that happens to have
name 0{40} recorded in a tree.
* The --rebase option to git pull can be abbreviated to -r,
but we didn't document it.
* When git push triggered the automatic gc on the receiving end, a
message from git prune that said it was removing cruft leaked to
the standard output, breaking the communication protocol.
* The reflog entries left by git rebase and git rebase -i were
inconsistent (the interactive one gave an abbreviated object name).
* git send-email did not unquote encoded words that appear on the
header correctly, and lost _ from strings.
* git stash apply/pop did not trigger rerere upon conflicts
unlike other mergy operations.
* git submodule cmd path did not error out when the path to the
submodule was misspelt.
* git submodule update -f did not update paths in the working tree
that has local changes.
(merge 01d4721 sz/submodule-force-update later to maint).
* gitweb when used with PATH_INFO failed to notice directories with
SP (and other characters that need URL-style quoting) in them.
* Fallback 'getpass' implementation made unportable use of stdio API.
* A utility shell function test_seq has been added as a replacement
for the 'seq' utility found on some platforms.
Changes since v1.7.11.5 are as follows:
Adam Butcher (1):
Fix '\ No newline...' annotation in rewrite diffs
Ben Walton (1):
Enable HAVE_DEV_TTY for Solaris
Brandon Casey (1):
t/t5400: demonstrate breakage caused by informational message from prune
Eric S. Raymond (3):
contrib/ciabot: Get ciabot configuration from git variables
Improved documentation for the ciabot scripts.
Make the ciabot scripts completely self-configuring in the normal case.
Heiko Voigt (2):
Let submodule command exit with error status if path does not exist
Documentation/CodingGuidelines: spell out more shell guidelines
Jay Soffian (1):
gitweb: URL-decode $my_url/$my_uri when stripping
Re: [PATCH 2/2] build: don't duplicate substitution of make variables
On 09/11/2012 09:52 PM, Junio C Hamano wrote: Stefano Lattarini stefano.lattar...@gmail.com writes: On 09/11/2012 07:27 PM, Junio C Hamano wrote: These two hunks suggest that you may be favoring spaces, but other places you seem to use tabs, so... I can convert the new tabs to spaces if you prefer (that would have been my preference too, but thought trying to follow the Git preferences was more important). No big deal either way for me. If this were other parts of the system, my preference would be to use tabs, but because I do not help very much in the autoconf part myself, I do not have a particular preference. If it is more common to indent the configure.ac script with spaces, There is no general standard about it that I know of; it's just that GNU projects tend to prefer space-based indentation over tab-based one, and since I mostly touch configure.ac files from GNU projects, I've picked up the habit. that would be more familiar to the folks who work on it, and I do not have much against choosing and sticking to space indented configure.ac file if that is the policy. Then I might send a patch that normalize indentation in configure.ac to spaces only, if that's OK with you. But that's obviously for a separated thread. But if this patch is not about cleaning up the style to make it conform to a policy (whichever it is), I would have preferred to see a clean-up patch as a separate step, not mixed together with this. The reason those few clean-ups are mixed into this patch is that the pre-existing strange indentation style was actually making it more difficult for me to grasp the code flow; that is, I didn't see them as a cosmetic change, but as a way to make it easier for me and the reader to see that my changes were correct and sensible. That's all; either way, no big deal. OK. Just let me know if you'd still prefer to have the indentation cleanups done by a preparatory patch, and I'll send a re-roll. Thanks, Stefano -- 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
[PATCHv2] fix broken list iteration in clear_child_for_cleanup
We iterate through the list of children to cleanup, but do not keep
our last pointer up to date. As a result, we may end up cutting off
part of the list instead of removing a single element.
Iterate through children_to_clean using 'next' fields but with an
extra level of indirection. This allows us to update the chain when
we remove a child and saves us managing several variables around
the loop mechanism.
Signed-off-by: David Gould da...@optimisefitness.com
Acked-by: Jeff King p...@peff.net
---
PATCHv2 updates PATCH only in the commit message: Peff suggested
both a helpful subject and a more-informative introduction.
run-command.c | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/run-command.c b/run-command.c
index f9922b9..c42d63b 100644
--- a/run-command.c
+++ b/run-command.c
@@ -53,13 +53,13 @@ static void mark_child_for_cleanup(pid_t pid)
static void clear_child_for_cleanup(pid_t pid)
{
- struct child_to_clean **last, *p;
+ struct child_to_clean **pp;
- last = children_to_clean;
- for (p = children_to_clean; p; p = p-next) {
- if (p-pid == pid) {
- *last = p-next;
- free(p);
+ for (pp = children_to_clean; *pp; pp = (*pp)-next) {
+ if ((*pp)-pid == pid) {
+ struct child_to_clean *clean_me = *pp;
+ *pp = clean_me-next;
+ free(clean_me);
return;
}
}
--
1.7.9.5
--
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: [PATCHv2] fix broken list iteration in clear_child_for_cleanup
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
[PATCH] blame: allow blame file in the middle of a conflicted merge
git blame file has always meant find the origin of each line of
the file in the history leading to HEAD, oh by the way, blame the
lines that are modified locally to the working tree.
This teaches git blame that during a conflicted merge, some
uncommitted changes may have come from the other history that is
being merged.
The verify_working_tree_path() function introduced in the previous
patch to notice a typo in the filename (primarily on case insensitive
filesystems) has been updated to allow a filename that does not exist
in HEAD (i.e. the tip of our history) as long as it exists one of the
commits being merged, so that a we deleted, the other side modified
case tracks the history of the file in the history of the other side.
Signed-off-by: Junio C Hamano gits...@pobox.com
---
* This is a follow-up to the previous one that is on 'pu'. I was
pleasantly surprised that something generally useful came out of
a patch to squelch corner case confusion that only happens on a
case insensitive filesystem (iow, a case I do not particularly
care deeply about ;-).
builtin/blame.c | 93 ++---
t/t8004-blame-with-conflicts.sh | 2 +-
2 files changed, 70 insertions(+), 25 deletions(-)
diff --git a/builtin/blame.c b/builtin/blame.c
index 83683b8..449880e 100644
--- a/builtin/blame.c
+++ b/builtin/blame.c
@@ -2044,17 +2044,53 @@ static int git_blame_config(const char *var, const char
*value, void *cb)
return git_default_config(var, value, cb);
}
-static void verify_working_tree_path(unsigned char *head_sha1, const char
*path)
+static void verify_working_tree_path(struct commit *work_tree, const char
*path)
{
- unsigned char blob_sha1[20];
- unsigned mode;
+ struct commit_list *parents;
- if (!resolve_ref_unsafe(HEAD, head_sha1, 1, NULL))
- die(no such ref: HEAD);
- if (get_tree_entry(head_sha1, path, blob_sha1, mode))
- die(no such path '%s' in HEAD, path);
- if (sha1_object_info(blob_sha1, NULL) != OBJ_BLOB)
- die(path '%s' in HEAD is not a blob, path);
+ for (parents = work_tree-parents; parents; parents = parents-next) {
+ const unsigned char *commit_sha1 = parents-item-object.sha1;
+ unsigned char blob_sha1[20];
+ unsigned mode;
+
+ if (!get_tree_entry(commit_sha1, path, blob_sha1, mode)
+ sha1_object_info(blob_sha1, NULL) == OBJ_BLOB)
+ return;
+ }
+ die(no such path '%s' in HEAD, path);
+}
+
+static struct commit_list **append_parent(struct commit_list **tail, const
unsigned char *sha1)
+{
+ struct commit *parent;
+
+ parent = lookup_commit_reference(sha1);
+ if (!parent)
+ die(no such commit %s, sha1_to_hex(sha1));
+ return commit_list_insert(parent, tail)-next;
+}
+
+static void append_merge_parents(struct commit_list **tail)
+{
+ int merge_head;
+ const char *merge_head_file = git_path(MERGE_HEAD);
+ struct strbuf line = STRBUF_INIT;
+
+ merge_head = open(merge_head_file, O_RDONLY);
+ if (merge_head 0) {
+ if (errno == ENOENT)
+ return;
+ die(cannot open '%s' for reading, merge_head_file);
+ }
+
+ while (!strbuf_getwholeline_fd(line, merge_head, '\n')) {
+ unsigned char sha1[20];
+ if (line.len 40 || get_sha1_hex(line.buf, sha1))
+ die(unknown line in '%s': %s, merge_head_file,
line.buf);
+ tail = append_parent(tail, sha1);
+ }
+ close(merge_head);
+ strbuf_release(line);
}
/*
@@ -2067,6 +2103,7 @@ static struct commit *fake_working_tree_commit(struct
diff_options *opt,
{
struct commit *commit;
struct origin *origin;
+ struct commit_list **parent_tail, *parent;
unsigned char head_sha1[20];
struct strbuf buf = STRBUF_INIT;
const char *ident;
@@ -2074,19 +2111,38 @@ static struct commit *fake_working_tree_commit(struct
diff_options *opt,
int size, len;
struct cache_entry *ce;
unsigned mode;
-
- verify_working_tree_path(head_sha1, path);
+ struct strbuf msg = STRBUF_INIT;
time(now);
commit = xcalloc(1, sizeof(*commit));
- commit-parents = xcalloc(1, sizeof(*commit-parents));
- commit-parents-item = lookup_commit_reference(head_sha1);
commit-object.parsed = 1;
commit-date = now;
commit-object.type = OBJ_COMMIT;
+ parent_tail = commit-parents;
+
+ if (!resolve_ref_unsafe(HEAD, head_sha1, 1, NULL))
+ die(no such ref: HEAD);
+
+ parent_tail = append_parent(parent_tail, head_sha1);
+ append_merge_parents(parent_tail);
+ verify_working_tree_path(commit, path);
origin = make_origin(commit, path);
+ ident = fmt_ident(Not Committed
Git server for Android
Hi guys, I'm looking for some feedback regarding an Android app I've released. It's a simple idea of mine for a tool that may be useful to developers when travelling or working on different locations. So the idea was to combine the two (in my opinion) very complementary paradigms - mobility and distribution. In particular - the mobility of any Android device with the distribution that Git provides. The app is called Gidder and it's a Git server implementation for Android on top of a SSH server. It has user/repository management, dynamic DNS support and basically automatically handles upload-pack and receive-pack commands (so we may push and fetch/pull). The app can be found on Google Play Store and it's free: https://play.google.com/store/apps/details?id=net.antoniy.gidder.beta Cheers, Antoniy -- 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
