GSoC idea: allow git rebase --interactive todo lines to take options
I just submitted the idea below as a pull request [1] to the GSoC ideas page, but I'd like to get some mailing list feedback first that the idea is sensible... And, is there anybody else willing to volunteer as a mentor for this project? (There should be at least two.) Michael [1] https://github.com/git/git.github.io/pull/5 ## Line options for `git rebase --interactive` One of the more powerful features in Git is the command `git rebase --interactive`, which allows recent commits to be reordered, squashed together, or even revised completely. The command creates a todo list and opens it in an editor. The original todo list might look like: pick deadbee Implement feature XXX pick c0ffeee The oneline of the next commit pick 01a01a0 This change is questionable pick f1a5c00 Fix to feature XXX pick deadbab The oneline of the commit after The user can edit the list to make changes to the history, for example to pick deadbee Implement feature XXX squash f1a5c00 Fix to feature XXX exec make edit c0ffeee The oneline of the next commit pick deadbab The oneline of the commit after This would cause commits `deadbee` and `f1a5c00` to be squashed together into one commit followed by running `make` to test-compile the results, delete commit `01a01a0` altogether, and stop after committing commit `c0ffeee` to allow the user to make changes. It would be nice to support more flexibility in the todo-list commands by allowing the commands to take options. Maybe * Convert a commit into a merge commit: pick -p c0ffeee -p e1ee712 deadbab The oneline of the commit after * After squashing two commits, add a Signed-off-by line to the commit log message: pick deadbee Implement feature XXX squash --signoff f1a5c00 Fix to feature XXX or GPG-sign a commit: pick --gpg-sign=keyid deadbee Implement feature XXX * Reset the author of the commit to the current user or a specified user: pick --reset-author deadbee Implement feature XXX pick --author=A U Thor aut...@example.com deadbab The oneline of the commit after The goal of this project would be (1) to add the infrastructure for handling options on todo-list lines, and (2) implement some concrete options. A big part of the difficulty of this project is that `git rebase --interactive` is implemented via a sparsely-commented shell script. Adding comments and cleaning up the script as you go would be very welcome. - Language: sh - Difficulty: medium - Possible mentors: Michael Haggerty -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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 stash pop` UX Problem
Omar Othman omar.oth...@booking.com writes: Though I don't know why you think this is important: Now, the real question is: when would Git stop showing this advice. I don't see a real way to answer this, and I'd rather avoid doing just a guess. If it is really annoying for the user, we can just have a configuration parameter to switch this message on/off. Just saying You have X stash is OK to me as long as there is an option to deactivate it. Hinting You should now run git stash drop. OTOH is far more dangerous if guessed wrong. Keeping a stash active when you don't need it does no real harm, but droping one you actually needed is data loss. -- 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
An idea for git bisect and a GSoC enquiry
Hey everyone, my name is Jacopo, a student developer from Italy, and I'm interested in applying to this years' Google Summer of Code. I set my eyes on the project called git-bisect improvements, in particular the subtask about swapping the good and bad labels when looking for a bug-fixing release. I have a very simple proposal for that: add a new mark subcommand. Here is an example of how it should work: 1) A developer wants to find in which commit a past regression was fixed. She start bisecting as usual with git bisect start. 2) The current HEAD has the bugfix, so she marks it as fixed with git bisect mark fixed. 3) She knows that HEAD~100 had the regression, so she marks it as unfixed with git bisect mark unfixed. 4) Now that git knows what the two labels are, it starts bisecting as usual. For compatibility with already written scripts, git bisect good and git bisect bad will alias to git bisect mark good and git bisect mark bad respectively. Does this make sense? Did I overlook some details? There were already several proposals on this topic, among which those listed at https://git.wiki.kernel.org/index.php/SmallProjectsIdeas#git_bisect_fix.2Funfixed. I'm interested in contacting the prospective mentor, Christian Couder, to go over these. What's the proper way to ask for an introduction? I tried asking on IRC, but had no success. Cheers, Jacopo Notarstefano -- 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] tag: support --sort=spec
On Tue, Feb 25, 2014 at 07:22:15PM +0700, Nguyễn Thái Ngọc Duy wrote:
versioncmp() is copied from string/strverscmp.c in glibc commit
ee9247c38a8def24a59eb5cfb7196a98bef8cfdc, reformatted to Git coding
style. The implementation is under LGPL-2.1 and according to [1] I can
relicense it to GPLv2.
Cool. I think doing this makes the most sense, as we do not have to
worry about build-time config (and I do not see any particular reason
why we would want to use the system strverscmp on glibc systems).
+static int parse_opt_sort(const struct option *opt, const char *arg, int
unset)
+{
+ int *sort = opt-value;
+ if (*arg == '-') {
+ *sort = REVERSE_SORT;
+ arg++;
+ } else
+ *sort = STRCMP_SORT;
+ if (starts_with(arg, version:)) {
+ *sort |= VERCMP_SORT;
+ arg += 8;
+ } else if (starts_with(arg, v:)) {
+ *sort |= VERCMP_SORT;
+ arg += 2;
+ }
+ if (strcmp(arg, refname))
+ die(_(unsupported sort specification %s), arg);
I found this logic a bit weird, as STRCMP_SORT and VERCMP_SORT are not
mutually exclusive flags, but REVERSE and STRCMP are. I would have
thought REVERSE is the flag, and the other two are selections. Like:
int flags = 0;
if (*arg == '-') {
flags |= REVERSE_SORT;
arg++;
}
if (starts_with(arg, version:)) {
*sort = VERCMP_SORT;
arg += 8;
} else
*sort = STRCMP_SORT;
*sort |= flags;
I think they end up doing the same thing, but maybe I am missing
something.
-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
[PATCH] commit.c: use the generic sha1_pos function for lookup sha1
Refactor binary search in commit_graft_pos function: use
generic sha1_pos function.
Signed-off-by: Dmitry S. Dolzhenko dmitrys.dolzhe...@yandex.ru
---
commit.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/commit.c b/commit.c
index 6bf4fe0..8edaeb7 100644
--- a/commit.c
+++ b/commit.c
@@ -10,6 +10,7 @@
#include mergesort.h
#include commit-slab.h
#include prio-queue.h
+#include sha1-lookup.h
static struct commit_extra_header *read_commit_extra_header_lines(const char
*buf, size_t len, const char **);
@@ -114,23 +115,16 @@ static unsigned long parse_commit_date(const char *buf,
const char *tail)
static struct commit_graft **commit_graft;
static int commit_graft_alloc, commit_graft_nr;
+static const unsigned char *commit_graft_sha1_access(size_t index, void
*table)
+{
+ struct commit_graft **commit_graft_table = table;
+ return commit_graft_table[index]-sha1;
+}
+
static int commit_graft_pos(const unsigned char *sha1)
{
- int lo, hi;
- lo = 0;
- hi = commit_graft_nr;
- while (lo hi) {
- int mi = (lo + hi) / 2;
- struct commit_graft *graft = commit_graft[mi];
- int cmp = hashcmp(sha1, graft-sha1);
- if (!cmp)
- return mi;
- if (cmp 0)
- hi = mi;
- else
- lo = mi + 1;
- }
- return -lo - 1;
+ return sha1_pos(sha1, commit_graft, commit_graft_nr,
+ commit_graft_sha1_access);
}
int register_commit_graft(struct commit_graft *graft, int ignore_dups)
--
1.8.5.3
Re: [PATCH] repack: add `repack.honorpackkeep` config var
On Mon, Feb 24, 2014 at 11:10:49AM -0800, Junio C Hamano wrote:
The best name I could come up with is --pack-keep-objects, since that
is literally what it is doing. I'm not wild about the name because it is
easy to read keep as a verb (and pack as a noun). I think it's OK,
but suggestions are welcome.
pack-kept-objects then?
Hmm. That does address my point above, but somehow the word kept feels
awkward to me. I'm ambivalent between the two.
Here's the kept version if you want to apply that.
-- 8 --
From: Vicent Marti tan...@gmail.com
Subject: [PATCH] repack: add `repack.packKeptObjects` config var
The git-repack command always passes `--honor-pack-keep`
to pack-objects. This has traditionally been a good thing,
as we do not want to duplicate those objects in a new pack,
and we are not going to delete the old pack.
However, when bitmaps are in use, it is important for a full
repack to include all reachable objects, even if they may be
duplicated in a .keep pack. Otherwise, we cannot generate
the bitmaps, as the on-disk format requires the set of
objects in the pack to be fully closed.
Even if the repository does not generally have .keep files,
a simultaneous push could cause a race condition in which a
.keep file exists at the moment of a repack. The repack may
try to include those objects in one of two situations:
1. The pushed .keep pack contains objects that were
already in the repository (e.g., blobs due to a revert of
an old commit).
2. Receive-pack updates the refs, making the objects
reachable, but before it removes the .keep file, the
repack runs.
In either case, we may prefer to duplicate some objects in
the new, full pack, and let the next repack (after the .keep
file is cleaned up) take care of removing them.
This patch introduces an option to disable the
`--honor-pack-keep` option. It is not triggered by default,
even when pack.writeBitmaps is turned on, because its use
depends on your overall packing strategy and use of .keep
files.
Note that this option just disables the pack-objects
behavior. We still leave packs with a .keep in place, as we
do not necessarily know that we have duplicated all of their
objects.
Signed-off-by: Jeff King p...@peff.net
---
Documentation/config.txt | 5 +
Documentation/git-repack.txt | 8
builtin/repack.c | 10 +-
t/t7700-repack.sh| 16
4 files changed, 38 insertions(+), 1 deletion(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index becbade..3a3d84f 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -2136,6 +2136,11 @@ repack.usedeltabaseoffset::
false and repack. Access from old Git versions over the
native protocol are unaffected by this option.
+repack.packKeptObjects::
+ If set to true, makes `git repack` act as if
+ `--pack-kept-objects` was passed. See linkgit:git-repack[1] for
+ details. Defaults to false.
+
rerere.autoupdate::
When set to true, `git-rerere` updates the index with the
resulting contents after it cleanly resolves conflicts using
diff --git a/Documentation/git-repack.txt b/Documentation/git-repack.txt
index 002cfd5..4786a78 100644
--- a/Documentation/git-repack.txt
+++ b/Documentation/git-repack.txt
@@ -117,6 +117,14 @@ other objects in that pack they already have locally.
must be able to refer to all reachable objects. This option
overrides the setting of `pack.writebitmaps`.
+--pack-kept-objects::
+ Include objects in `.keep` files when repacking. Note that we
+ still do not delete `.keep` packs after `pack-objects` finishes.
+ This means that we may duplicate objects, but this makes the
+ option safe to use when there are concurrent pushes or fetches.
+ This option is generally only useful if you are writing bitmaps
+ with `-b` or `pack.writebitmaps`, as it ensures that the
+ bitmapped packfile has the necessary objects.
Configuration
-
diff --git a/builtin/repack.c b/builtin/repack.c
index 49f5857..49947b2 100644
--- a/builtin/repack.c
+++ b/builtin/repack.c
@@ -9,6 +9,7 @@
#include argv-array.h
static int delta_base_offset = 1;
+static int pack_kept_objects;
static char *packdir, *packtmp;
static const char *const git_repack_usage[] = {
@@ -22,6 +23,10 @@ static int repack_config(const char *var, const char *value,
void *cb)
delta_base_offset = git_config_bool(var, value);
return 0;
}
+ if (!strcmp(var, repack.packkeptobjects)) {
+ pack_kept_objects = git_config_bool(var, value);
+ return 0;
+ }
return git_default_config(var, value, cb);
}
@@ -175,6 +180,8 @@ int cmd_repack(int argc, const char **argv, const char
*prefix)
N_(limits the maximum delta depth)),
OPT_STRING(0, max-pack-size, max_pack_size,
Re: Git in GSoC 2014
On Tue, Feb 25, 2014 at 06:15:28PM +0100, Michael Haggerty wrote: We didn't discuss earlier whether we would have any specific requirements for students during the proposal period (e.g., having a patch accepted). It would be good to put together rules (or barring any specific requirements, guidelines to help students put together a good proposal) as soon as possible. Suggestions are welcome. Requiring students to submit a reasonable patch and follow up on review comments seems like it would be a good way to filter out non-serious students. (I hesitate to require that the patch be accepted because it can take quite a while for a patch to make it to master, despite of the student's efforts.) Yeah, I think the early stages of accepted are somewhat vague. Probably patch is in next is a reasonable definition, but I do not think we even need to bind ourselves so strictly. Humans read, evaluate, and rank the proposals, so we can use our judgement about whether a patch looks promising. Does anybody know whether other organizations have had good experience with criteria like that? Does it chase *all* the applicants away? If you haven't seen it, there is a guide written by mentors and admins from past years: http://en.flossmanuals.net/GSoCMentoring/ I did not see this particular subject covered, though I seem to recall it has come up on the mentor list in past years. I can't search the archive now, because they haven't re-added me for this year yet, but I'll do so once I have access. I think I'm in favor. It seems like a minimal hurdle to overcome, and I think everybody is more than happy to coach new contributors through the process. If we wanted to impose such a hurdle, then we would definitely have to make up a list of microprojects so that the students don't have to start from nothing. I imagine it shouldn't be too hard to find tiny projects estimated at 10-30 minutes of actual work, which should be plenty difficult for a student who also has to figure out how to check out the code, conform to our coding standards, run the unit tests, create a patch submission, etc. The hack-a-thon bug list I posted earlier has some potential points of interest, but I need to update it to reflect the work done that day (a lot of that is trickling in to me for initial comments, and then I'll direct them to the list, but I'm a bit behind on dealing with it). If the reaction is positive to this idea then I volunteer to spend several hours tomorrow looking for microprojects, and I suggest other core developers do so as well. They should presumably be submitted as patches to the ideas repository [1]. Yes, though I think it makes sense to put them on a separate page. We should probably write up some notes for students, too: how to get in touch with us, what do we expect of them in the pre-proposal period, what would we expect in terms of communication and day-to-day workflow during the summer, etc. -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: `git stash pop` UX Problem
Junio C Hamano gits...@pobox.com wrote: Stephen Leake stephen_le...@stephe-leake.org writes: Dropping the stash on a git add operation would be really, really weird... Why? That is when the merge conflicts are resolved, which is what logically indicates that the stash is no longer needed,... Not necessarily. Imagine a case where you used stash to quickly save away a tangled mess that was not ready for a logically single commit and now you are in the process of creating the first commit by applying it piece-by-piece to create multiple resulting ones. After you commit the result, you would still want to keep the parts of that stashed change you did not include in the first commit so that you can go back, no? You may run git add, but that does not say anything about what you are going to use the rest of the stash for. Not even git commit may be a good enough sign. But we are only talking about the situation where you typed git stash pop, and this resulted in a merge conflict. Your intention was clearly to drop the stash, it just wasn't dropped because of the conflict. Dropping it automatically once the conflict is resolved would be nice. I know it happened to me too that I forgot to drop a stash after resolving conflicts, so I'd appreciate a feature that somehow does this automatically for me. -- Stefan Haller Berlin, Germany http://www.haller-berlin.de/ -- 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 in GSoC 2014
On 02/26/2014 11:23 AM, Jeff King wrote: On Tue, Feb 25, 2014 at 06:15:28PM +0100, Michael Haggerty wrote: Requiring students to submit a reasonable patch and follow up on review comments seems like it would be a good way to filter out non-serious students. (I hesitate to require that the patch be accepted because it can take quite a while for a patch to make it to master, despite of the student's efforts.) Yeah, I think the early stages of accepted are somewhat vague. Probably patch is in next is a reasonable definition, but I do not think we even need to bind ourselves so strictly. Humans read, evaluate, and rank the proposals, so we can use our judgement about whether a patch looks promising. Agreed. [...] If we wanted to impose such a hurdle, then we would definitely have to make up a list of microprojects so that the students don't have to start from nothing. [...] If the reaction is positive to this idea then I volunteer to spend several hours tomorrow looking for microprojects, and I suggest other core developers do so as well. They should presumably be submitted as patches to the ideas repository [1]. Yes, though I think it makes sense to put them on a separate page. We should probably write up some notes for students, too: how to get in touch with us, what do we expect of them in the pre-proposal period, what would we expect in terms of communication and day-to-day workflow during the summer, etc. Since time is short, I already started on this. I wrote a first draft of an introduction for the students. I also started looking for microprojects. I started going through our source files alphabetically, and have already found six suggestions by bundle.c, so I don't think there will be a problem finding enough tiny things to do. See my branch on GitHub [1] or read the appended text below. I've been looking for *really* tiny projects. Feedback is welcome about whether they are too trivial to be meaningful in distinguishing promising students from no-hopers. My feeling is that there is so much process involved in submitting a patch that it will take even a well-prepared student quite a while to make a change, no matter how trivial. Also, how many suggested microprojects do you think we need (i.e., when can I stop :-) )? Michael [1] https://github.com/mhagger/git.github.io/tree/microprojects --- layout: default title: SoC 2014 Applicant Microprojects --- ## Introduction It is strongly recommended that students who want to apply to the Git project for the Summer of Code 2014 should submit a small code-related patch to the Git project as part of their application. Think of these microprojects as the Hello, world of getting involved with the Git project; the coding aspect of the change can be almost trivial, but to make the change the student has to become familiar with many of the practical aspects of working on the Git project: * Downloading the source code: clone the repository using the [Git via Git](http://git-scm.com/downloads) instructions and read the `README` file. * Build the source code: this is described in the file `INSTALL`. * Glance over our coding guidelines in the file `Documentation/CodingGuidelines`. We take things like proper code formatting very seriously. * Read about the process for submitting patches to Git: this is described in `Documentation/SubmittingPatches`. * Making the actual change. * Run the test suite: this is described in the file `t/README`. (If you have added new functionality, you should also add tests, but most microprojects will not add new functionality.) * Commit your change. Surprise: we use Git for that, so you will need to gain at least [a basic familiarity](http://git-scm.com/documentation) with using Git. Make sure to write a good commit message that explains the reason for the change and any ramifications. Remember to add a Signed-off-by line (see the coding guidelines for more information). * Submit your change to the Git mailing list. For this step you probably want to use the commands `git format-patch` and `git send-email`. * Expect feedback, criticism, suggestions, etc. from the mailing list. *Respond to it!* and follow up with improved versions of your change. Even for a trivial patch you shouldn't be surprised if it takes two or more iterations before your patch is accepted. *This is the best part of the Git community; it is your chance to get personalized instruction from very experienced peers!* The coding part of the microproject should be very small (say, 10-30 minutes). We don't require that your patch be accepted into master by the time of your formal application; we mostly want to see that you have a basic level of competence and especially the ability to interact with the other Git developers. When you submit your patch, please mention that you plan to apply for the GSoC. This will ensure that we take special care not to overlook your
Re: [PATCH] commit.c: use the generic sha1_pos function for lookup sha1
On Wed, Feb 26, 2014 at 02:07:47PM +0400, Dmitry S. Dolzhenko wrote:
Refactor binary search in commit_graft_pos function: use
generic sha1_pos function.
Sounds sensible.
A few administrative points for your patch:
- we usually try to send patches inline, rather than as attachments.
It almost looks like your mailer or a server on the path converted
your mail to a multipart/mixed and stuck a useless empty attachment
on the end.
- Your patch did not apply for me, nor to the blobs mentioned in its
header. Did you modify it after it was generated? I think this part
in particular looks suspicious:
diff --git a/commit.c b/commit.c
index 6bf4fe0..8edaeb7 100644
--- a/commit.c
+++ b/commit.c
@@ -10,6 +10,7 @@
#include mergesort.h
#include commit-slab.h
#include prio-queue.h
+#include sha1-lookup.h
static struct commit_extra_header *read_commit_extra_header_lines(const
char *buf, size_t len, const char **);
There are 3 context lines above, but only one below?
@@ -114,23 +115,16 @@ static unsigned long parse_commit_date(const char
*buf, const char *tail)
static struct commit_graft **commit_graft;
static int commit_graft_alloc, commit_graft_nr;
+static const unsigned char *commit_graft_sha1_access(size_t index, void
*table)
+{
+ struct commit_graft **commit_graft_table = table;
+ return commit_graft_table[index]-sha1;
+}
+
And here we have only two context lines, and the first addition line is
indented (making it look like a context line).
static int commit_graft_pos(const unsigned char *sha1)
{
- int lo, hi;
- lo = 0;
- hi = commit_graft_nr;
- while (lo hi) {
- int mi = (lo + hi) / 2;
- struct commit_graft *graft = commit_graft[mi];
- int cmp = hashcmp(sha1, graft-sha1);
- if (!cmp)
- return mi;
- if (cmp 0)
- hi = mi;
- else
- lo = mi + 1;
- }
- return -lo - 1;
+ return sha1_pos(sha1, commit_graft, commit_graft_nr,
+commit_graft_sha1_access);
The patch itself looks correct.
-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: `git stash pop` UX Problem
li...@haller-berlin.de (Stefan Haller) writes: Your intention was clearly to drop the stash, it just wasn't dropped because of the conflict. Dropping it automatically once the conflict is resolved would be nice. Your intention when you ran git stash pop, yes. Your intention when you ran git add, I call that guessing. The condition for dropping the stash should be more conflits resolutions are done AND the user is happy with it. Otherwise, if you mess up your conflict resolution, and notice it after running git add, then you're screwed because Git just happily discarded your important data. The point of keeping the stash is to leave it up to the user to decide between I'm happy, I can drop or I'm not, I should re-apply, and Git cannot tell which is which. Hinting the user to run stash pop would be more acceptable, but talking about git stash in git add's code is somehow a dependency order violation (stash is normally implemented on top of Git's basic features, not the other way around). Does not seem serious from at first from the user point of view, but this pushes the codebase one step in the direction of an unmaintainable mess. -- 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: GSoC idea: allow git rebase --interactive todo lines to take options
On Wed, Feb 26, 2014 at 09:04:30AM +0100, Michael Haggerty wrote: It would be nice to support more flexibility in the todo-list commands by allowing the commands to take options. Maybe * Convert a commit into a merge commit: pick -p c0ffeee -p e1ee712 deadbab The oneline of the commit after This seems like a reasonable feature to me. All of your examples are possible with an edit and another git command, but the convenience may be worth it (though personally, most of the examples you gave are particularly interesting to me[1]). I'd worry a little that it is not a summer's worth of work, but I suspect there are other parts of rebase--interactive that could use attention once the student is familiar with the code. * After squashing two commits, add a Signed-off-by line to the commit log message: pick deadbee Implement feature XXX squash --signoff f1a5c00 Fix to feature XXX or GPG-sign a commit: pick --gpg-sign=keyid deadbee Implement feature XXX * Reset the author of the commit to the current user or a specified user: pick --reset-author deadbee Implement feature XXX pick --author=A U Thor aut...@example.com deadbab The oneline of the commit after Your first example would need some commit-tree magic, I think. But could you implement these two with: pick deadbee Implement feature XXX exec git commit --amend --signoff --reset-author ? You could even alias the amend command to exec git commit --amend, like: amend --signoff --reset-author Maybe that is unnecessarily unfriendly to the user, though. -Peff [1] The one feature I would like in this vein is that editing the title in the instruction-sheet would modify the commit message of the relevant commit. For some reason I try to do this every few weeks, but of course the changes are just thrown away. -- 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] commit.c: use the generic sha1_pos function for lookup sha1
On Wed, Feb 26, 2014 at 5:07 PM, Dmitry S. Dolzhenko dmitrys.dolzhe...@yandex.ru wrote: Refactor binary search in commit_graft_pos function: use generic sha1_pos function. For fun, try to break your changes deliberately then run make test and see if the failed tests can lead you back to this function. I hear some people gather in irc. I think they could help you faster when you need to track this code. Else get support from this mailing list. If the test suite does not detect it at all, you can add new tests to cover it. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/25] Add new environment variable $GIT_COMMON_DIR
On Wed, Feb 26, 2014 at 8:24 AM, Eric Sunshine sunsh...@sunshineco.com wrote: +'GIT_COMMON_DIR':: + If this variable is set to a path, non-worktree files that are + normally in $GIT_DIR will be taken from this path + instead. Worktree-specific files such as HEAD or index are + taken from $GIT_DIR. This variable has lower precedence than + other path variables such as GIT_INDEX_FILE, + GIT_OBJECT_DIRECTORY... For a person not familiar with git checkout --to or its underlying implementation, this description may be lacking. Such a reader may be left wondering about GIT_COMMON_DIR's overall purpose, and when and how it should be used. Perhaps it would make sense to talk a bit about git checkout --to here? I don't want to repeat too much. Maybe mention about git checkout --to and point them to git-checkout man page? -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3] tag: support --sort=spec
On Wed, Feb 26, 2014 at 4:05 PM, Jeff King p...@peff.net wrote:
On Tue, Feb 25, 2014 at 07:22:15PM +0700, Nguyễn Thái Ngọc Duy wrote:
versioncmp() is copied from string/strverscmp.c in glibc commit
ee9247c38a8def24a59eb5cfb7196a98bef8cfdc, reformatted to Git coding
style. The implementation is under LGPL-2.1 and according to [1] I can
relicense it to GPLv2.
Cool. I think doing this makes the most sense, as we do not have to
worry about build-time config (and I do not see any particular reason
why we would want to use the system strverscmp on glibc systems).
Another reason I want to stay away from glibc is I want to fix the
algorithm to sort YY-preXX and YY-rcXX before YY. There could be
reasons that glibc might reject such a change even if it makes sense
in our context. Even if we make it to newer glibc and fix compat
version, people on older glibc will not receive the fix while people
on compat do. Not so good.
+static int parse_opt_sort(const struct option *opt, const char *arg, int
unset)
+{
+ int *sort = opt-value;
+ if (*arg == '-') {
+ *sort = REVERSE_SORT;
+ arg++;
+ } else
+ *sort = STRCMP_SORT;
+ if (starts_with(arg, version:)) {
+ *sort |= VERCMP_SORT;
+ arg += 8;
+ } else if (starts_with(arg, v:)) {
+ *sort |= VERCMP_SORT;
+ arg += 2;
+ }
+ if (strcmp(arg, refname))
+ die(_(unsupported sort specification %s), arg);
I found this logic a bit weird, as STRCMP_SORT and VERCMP_SORT are not
mutually exclusive flags, but REVERSE and STRCMP are. I would have
thought REVERSE is the flag, and the other two are selections. Like:
int flags = 0;
if (*arg == '-') {
flags |= REVERSE_SORT;
arg++;
}
if (starts_with(arg, version:)) {
*sort = VERCMP_SORT;
arg += 8;
} else
*sort = STRCMP_SORT;
*sort |= flags;
I think they end up doing the same thing, but maybe I am missing
something.
No you're not. I did not make it absolute beautiful because I expected
it to be deleted soon after you polish your f-e-r series. Will resend
with this change shortly.
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git in GSoC 2014
On Wed, Feb 26, 2014 at 11:41:21AM +0100, Michael Haggerty wrote: Yes, though I think it makes sense to put them on a separate page. We should probably write up some notes for students, too: how to get in touch with us, what do we expect of them in the pre-proposal period, what would we expect in terms of communication and day-to-day workflow during the summer, etc. Since time is short, I already started on this. I wrote a first draft of an introduction for the students. I also started looking for microprojects. I started going through our source files alphabetically, and have already found six suggestions by bundle.c, so I don't think there will be a problem finding enough tiny things to do. Thanks, the intro text looks great. We probably need some intro text to go on the ideas page (that is what Google links to for prospective students) that points them to the microproject page. See my branch on GitHub [1] or read the appended text below. I've merged and pushed out your branch (I'll work on getting push access for people, as there's no real reason for me to be an integration bottleneck with this stuff). I've been looking for *really* tiny projects. Feedback is welcome about whether they are too trivial to be meaningful in distinguishing promising students from no-hopers. My feeling is that there is so much process involved in submitting a patch that it will take even a well-prepared student quite a while to make a change, no matter how trivial. I really like the level of the projects below. It should be more about the process than the code, and I think you nailed that. I especially like the ones that require some digging in history. The bug list I mentioned before is probably too heavyweight in that sense (they're more like 4-6 hour projects for somebody who isn't familiar with the code, plus submission headaches on top of that). Also, how many suggested microprojects do you think we need (i.e., when can I stop :-) )? I think it depends on how quickly people do them. We can always add more if they run low (though 6 does not provide a huge buffer, so we may want a few more). 6. Change `bundle.c:add_to_ref_list()` to use `ALLOC_GROW()`. This is the only one that seemed like it might be _too_ trivial to me. The memcpy/hashcpy one is similarly trivial, but I like the add-on of look for other places. I guess we could do that here, too. -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 v3] tag: support --sort=spec
On Wed, Feb 26, 2014 at 06:03:40PM +0700, Duy Nguyen wrote: Cool. I think doing this makes the most sense, as we do not have to worry about build-time config (and I do not see any particular reason why we would want to use the system strverscmp on glibc systems). Another reason I want to stay away from glibc is I want to fix the algorithm to sort YY-preXX and YY-rcXX before YY. There could be reasons that glibc might reject such a change even if it makes sense in our context. Even if we make it to newer glibc and fix compat version, people on older glibc will not receive the fix while people on compat do. Not so good. Yeah, the handling of -rc has bugged me, too (in my personal alias, I just grep out the -rc before feeding the list to sort -V :) ). I'd worry slightly, though, that there are other schemes where that behaves poorly. Should we optimize for git's version numbering, or for what most other projects want? There could even be room for two types of version-compare. But before thinking about that, I'd want to know why glibc behaves as it does. -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 v3] tag: support --sort=spec
On Wed, Feb 26, 2014 at 6:08 PM, Jeff King p...@peff.net wrote: I'd worry slightly, though, that there are other schemes where that behaves poorly. Should we optimize for git's version numbering, or for what most other projects want? There could even be room for two types of version-compare. But before thinking about that, I'd want to know why glibc behaves as it does. We don't have to force one version style for all projects. We could provide --sort=thisver:refname vs. thatver:refname, or put the -pre part in config file. The important thing is we can control the version algorithm. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC idea: allow git rebase --interactive todo lines to take options
On 02/26/2014 11:52 AM, Jeff King wrote: On Wed, Feb 26, 2014 at 09:04:30AM +0100, Michael Haggerty wrote: It would be nice to support more flexibility in the todo-list commands by allowing the commands to take options. Maybe * Convert a commit into a merge commit: pick -p c0ffeee -p e1ee712 deadbab The oneline of the commit after This seems like a reasonable feature to me. All of your examples are possible with an edit and another git command, but the convenience may be worth it (though personally, most of the examples you gave are particularly interesting to me[1]). I'd worry a little that it is not a summer's worth of work, but I suspect there are other parts of rebase--interactive that could use attention once the student is familiar with the code. * After squashing two commits, add a Signed-off-by line to the commit log message: pick deadbee Implement feature XXX squash --signoff f1a5c00 Fix to feature XXX or GPG-sign a commit: pick --gpg-sign=keyid deadbee Implement feature XXX * Reset the author of the commit to the current user or a specified user: pick --reset-author deadbee Implement feature XXX pick --author=A U Thor aut...@example.com deadbab The oneline of the commit after Your first example would need some commit-tree magic, I think. But could you implement these two with: pick deadbee Implement feature XXX exec git commit --amend --signoff --reset-author ? You could even alias the amend command to exec git commit --amend, like: amend --signoff --reset-author Maybe that is unnecessarily unfriendly to the user, though. The whole point is to make these things easy. But I have to admit that amend would be another nice todo-list command. Once the infrastructure is there to handle options, it would be no big deal to add an amend command with a --signoff option and offer the same --signoff option on other, existing commands. [1] The one feature I would like in this vein is that editing the title in the instruction-sheet would modify the commit message of the relevant commit. For some reason I try to do this every few weeks, but of course the changes are just thrown away. Given that commit messages can be more than one line long, a feature like this would be confusing, I think, and perhaps subtly encourage people to limit their commit messages to a single line, which would be a bad thing. Plus, until now such edits were thrown away, so there are backwards compatibility problems if we suddenly start preserving such edits. But using the other ideas discussed here one could do pick -m New log message sha1 or amend -m Revised log message It also might be reasonable, if the user edits the title in a way that does not simply delete characters at the end, to do an implicit reword with the edited title stuck in at the first line (and maybe the original title following it, commented out with #). Another, more wonkish idea I though of would be pick --tree=treeish sha1 to force the tree of the commit to be set to that of the specified treeish while keeping the commit metadata from sha1. What would this be useful for? When swapping two commits, it is often the case that conflicts have to be resolved twice. But the tree should be the same after both commits are applied, regardless of the order in which they are applied. So one could change pick aaa pick bbb to pick bbb pick --tree=bbb aaa On the other hand, maybe git rebase --interactive should have the intelligence to do this automatically whenever the set of commits pre/post rewriting is identical, possibly if a --reorder-only option is used. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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: [PATCH v3] tag: support --sort=spec
On Wed, Feb 26, 2014 at 06:11:54PM +0700, Duy Nguyen wrote: On Wed, Feb 26, 2014 at 6:08 PM, Jeff King p...@peff.net wrote: I'd worry slightly, though, that there are other schemes where that behaves poorly. Should we optimize for git's version numbering, or for what most other projects want? There could even be room for two types of version-compare. But before thinking about that, I'd want to know why glibc behaves as it does. We don't have to force one version style for all projects. We could provide --sort=thisver:refname vs. thatver:refname, or put the -pre part in config file. The important thing is we can control the version algorithm. Right, exactly. It may make sense to just do it the way _we_ think is sensible for now, then, and we can add a glibc-compatible one later if somebody actually wants it. -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: Git in GSoC 2014
On Tue, Feb 25, 2014 at 10:41 PM, Jeff King p...@peff.net wrote: I'm pleased to announce that Git has been accepted to this year's Google Summer of Code. Student proposals will start coming in on March 22. In the meantime students will be reading our Ideas page[1] and enquiring about the program on the mailing list and on irc. There are many ways that existing git developers can help: - continue to add to and polish the Ideas page One thing I noticed after tg/index-v4-format is both libgit2 and jgit do not seem to support index v4. So we could add index v4 support on libgit2 to the idea page. It's a relatively small task though once you get a hang on index format. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git in GSoC 2014
On Wed, Feb 26, 2014 at 12:25:36PM +0100, Vicent Martí wrote: On Wed, Feb 26, 2014 at 11:41 AM, Michael Haggerty mhag...@alum.mit.edu wrote: Since time is short, I already started on this. I wrote a first draft of an introduction for the students. I also started looking for microprojects. I started going through our source files alphabetically, and have already found six suggestions by bundle.c, so I don't think there will be a problem finding enough tiny things to do. Note that for projects that are either libgit2-centric or mix Core Git and libgit2, it would be worth it to the students to submit a pull request on libgit2 (or ideally, on both projects, although that's going to be hard) in order to make themselves familiar with the code base. Yeah, that makes sense. I think if students are thinking primarily about one of the libgit2 projects, they should focus on interacting with that community. Interacting with the mailing list is good, too, but I don't see a need to do a patch for both. Can you come up with a short list of micro-projects for libgit2, similar to what Michael did for Git? -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: Git in GSoC 2014
On Wed, Feb 26, 2014 at 11:41 AM, Michael Haggerty mhag...@alum.mit.edu wrote: Since time is short, I already started on this. I wrote a first draft of an introduction for the students. I also started looking for microprojects. I started going through our source files alphabetically, and have already found six suggestions by bundle.c, so I don't think there will be a problem finding enough tiny things to do. Note that for projects that are either libgit2-centric or mix Core Git and libgit2, it would be worth it to the students to submit a pull request on libgit2 (or ideally, on both projects, although that's going to be hard) in order to make themselves familiar with the code base. -- 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 in GSoC 2014
On Wed, Feb 26, 2014 at 12:16 PM, Duy Nguyen pclo...@gmail.com wrote: On Tue, Feb 25, 2014 at 10:41 PM, Jeff King p...@peff.net wrote: I'm pleased to announce that Git has been accepted to this year's Google Summer of Code. Student proposals will start coming in on March 22. In the meantime students will be reading our Ideas page[1] and enquiring about the program on the mailing list and on irc. There are many ways that existing git developers can help: - continue to add to and polish the Ideas page One thing I noticed after tg/index-v4-format is both libgit2 and jgit do not seem to support index v4. So we could add index v4 support on libgit2 to the idea page. It's a relatively small task though once you get a hang on index format. That sounds like a nice task for the Summer of Code too, specially with the current effort to make Index v4 more visible in Core Git. I wonder if anybody from JGit would also be interested on mentoring for the equivalent task (index v4 on JGit). I've CC'ed Shawn Pearce. -- 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 in GSoC 2014
On Wed, Feb 26, 2014 at 12:24:13PM +0100, Vicent Martí wrote: One thing I noticed after tg/index-v4-format is both libgit2 and jgit do not seem to support index v4. So we could add index v4 support on libgit2 to the idea page. It's a relatively small task though once you get a hang on index format. That sounds like a nice task for the Summer of Code too, specially with the current effort to make Index v4 more visible in Core Git. Yeah, I'd agree. Want to write it up? I wonder if anybody from JGit would also be interested on mentoring for the equivalent task (index v4 on JGit). I've CC'ed Shawn Pearce. A project that added to both libgit2 and JGit would be cool, but I don't know if that is asking too much of the student (multiple languages and projects is going to increase the time spent on non-code friction). -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 v3] tag: support --sort=spec
On Wed, Feb 26, 2014 at 6:08 PM, Jeff King p...@peff.net wrote: But before thinking about that, I'd want to know why glibc behaves as it does. Pure guess. It may be because it targets more than software version. In strverscmp man page, the example is jan1, jan10, jan2 versionsort() in glibc might be the reason that strverscmp was added and it's used to compare/sort dir entries, so the target might be numbered log files. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: GSoC idea: allow git rebase --interactive todo lines to take options
On Wed, Feb 26, 2014 at 12:14:11PM +0100, Michael Haggerty wrote: [1] The one feature I would like in this vein is that editing the title in the instruction-sheet would modify the commit message of the relevant commit. For some reason I try to do this every few weeks, but of course the changes are just thrown away. Given that commit messages can be more than one line long, a feature like this would be confusing, I think, and perhaps subtly encourage people to limit their commit messages to a single line, which would be a bad thing. Right, I was assuming it would just modify the subject-line, and leave the rest intact (I often want to use it to just replace one word or fix a typo, since I am starting right at it in the insn sheet). Plus, until now such edits were thrown away, so there are backwards compatibility problems if we suddenly start preserving such edits. Good point. For true interactive use it probably wouldn't be that big a deal, but people do weird things with GIT_EDITOR and auto-munging the list of commits. A heuristic like is there any message there at all might work, as you mentioned, but heuristics make me nervous. But using the other ideas discussed here one could do pick -m New log message sha1 Yeah, that would work, though you have to retype the whole thing, which is potentially annoying (clever use of your editor can pull it over from the other side, but it's not super-friendly). Something like: pick --subject sha1 modified message... would be simpler. amend -m Revised log message That would replace the whole message, which I definitely don't want (and would encourage bad habits). Another, more wonkish idea I though of would be pick --tree=treeish sha1 to force the tree of the commit to be set to that of the specified treeish while keeping the commit metadata from sha1. I think there's a large foot-shooting capacity there. Any commit you've reordered from after the --tree to before it will mysteriously get undone in the --tree commit. E.g.: pick aaa pick bbb pick ccc being done as: pick ccc pick bbb pick --tree=bbb aaa -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
[PATCH] git p4 submit: Add --{skip-,}edit-submit option
This allows skipping interactively editting the p4 changelist before
submit. This is useful for pushing series of patches to p4 quickly.
This was already possible through a config option.
Signed-off-by: Crestez Dan Leonard cdleon...@gmail.com
---
Documentation/git-p4.txt | 4
git-p4.py| 11 ++-
2 files changed, 14 insertions(+), 1 deletion(-)
diff --git a/Documentation/git-p4.txt b/Documentation/git-p4.txt
index 6ab5f94..619f45f 100644
--- a/Documentation/git-p4.txt
+++ b/Documentation/git-p4.txt
@@ -299,6 +299,10 @@ These options can be used to modify 'git p4 submit' behavior.
to bypass the prompt, causing conflicting commits to be automatically
skipped, or to quit trying to apply commits, without prompting.
+--skip-submit-edit --edit-submit::
+ Edit the changelist before template or not. This defaults to true,
+ unless overridden by the git-p4.skipSubmitEdit config option.
+
--branch branch::
After submitting, sync this named branch instead of the default
p4/master. See the Sync options section above for more
diff --git a/git-p4.py b/git-p4.py
index cdfa2df..cafd997 100755
--- a/git-p4.py
+++ b/git-p4.py
@@ -998,6 +998,10 @@ class P4Submit(Command, P4UserMap):
optparse.make_option(--prepare-p4-only, dest=prepare_p4_only, action=store_true),
optparse.make_option(--conflict, dest=conflict_behavior,
choices=self.conflict_behavior_choices),
+optparse.make_option(--skip-edit-submit, dest=edit_submit, action=store_true,
+help=Skip editting the changelist before submit),
+optparse.make_option(--edit-submit, dest=edit_submit, action=store_false,
+help=Edit the changelist before submit (default)),
optparse.make_option(--branch, dest=branch),
]
self.description = Submit changes from git to the perforce depot.
@@ -1203,12 +1207,17 @@ class P4Submit(Command, P4UserMap):
return template
+def get_edit_submit_value(self):
+if hasattr(self, 'edit_submit'):
+return self.edit_submit
+return gitConfigBool('git-p4.skipSubmitEdit')
+
def edit_template(self, template_file):
Invoke the editor to let the user change the submission
message. Return true if okay to continue with the submit.
# if configured to skip the editing part, just submit
-if gitConfigBool(git-p4.skipSubmitEdit):
+if self.get_edit_submit_value():
return True
# look at the modification time, to check later if the user saved
Re: GSoC idea: allow git rebase --interactive todo lines to take options
On Wed, Feb 26, 2014 at 6:52 PM, Jeff King p...@peff.net wrote: I'd worry a little that it is not a summer's worth of work, but I suspect there are other parts of rebase--interactive that could use attention once the student is familiar with the code. It might be worthwhile to check for prior projects that were a bag of small projects that were accepted into GSoC. I don't have the time to do this right now, I'll get to it at a later time. -- Cheers, Ray Chuan -- 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 stash pop` UX Problem
On Tue, Feb 25, 2014 at 11:12:10AM -0800, Junio C Hamano wrote:
So, I tend to agree with you, while I do understand where I want to
know about what is in stash is coming from (and that is why we do
have git stash list command).
One thing that would be nice is if there was built-in git stash list
option which only shows the stash items which match the current
branch. The discussion on this thread inspired me to create the
following:
#!/bin/sh
b=$(git symbolic-ref HEAD | sed -e 's;refs/heads/;;')
git stash list --pretty=%gd %cr on: %s | grep WIP on $b | \
sed -e s/ WIP on $b: [0-9a-f]*//
This results in:
stash@{0} 4 weeks ago on: mke2fs: add make_hugefile feature
stash@{1} 5 weeks ago on: e2fsck, mke2fs: enable octal integers in the
profile/config file
stash@{2} 5 weeks ago on: e2fsck, mke2fs: enable octal integers in the
profile/config file
stash@{3} 5 weeks ago on: mke2fs: optimize fix_cluster_bg_counts()
stash@{4} 8 weeks ago on: e4defrag: choose the best available posix_fadvise
variant
stash@{5} 9 weeks ago on: e2image: add -c option to optimize file system
copying for flash devices
stash@{6} 9 weeks ago on: e2image: clean up gcc -Wall and sparse nits
stash@{7} 9 weeks ago on: e2fsck: fix printf conversion specs in ea_refcount.c
(Yes, I have a lot of junk on my git stash; showing the relative time
is going to help my GC what I have left on my git stash list.)
Cheers,
- Ted
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Cygwin + git log = no pager!
On Wed, Feb 26, 2014 at 3:26 AM, Jeff King p...@peff.net wrote: On Mon, Feb 24, 2014 at 01:34:34PM -0600, Robert Dailey wrote: So I set GIT_PAGER to 'echo custom pager' as you instructed, and I noticed that wasn't being printed when I ran my git log alias. So what I did after that was set GIT_TRACE=1 and here is the output I see before my logs start printing: [...] Does using an alias have something to do with this? The aliases shouldn't matter (and I constructed a scenario like the one you showed and it starts the pager for me on Linux). It's more like git is deciding not to show a pager at all (e.g., it thinks your stdout is not a tty). Does running: git log not use a pager, but: git -p log does? In that case, I think that your stdout is not a tty for some reason. If that is the case, try: git -p lg That _should_ turn on the pager, but I think it does not due to a bug with setup_pager and aliases. Something like the patch below would make it work (but if you are having to use -p manually, there is something to fix in your cygwin environment, which does not think you are on a terminal). -Peff snip I have tried `git -p log` and `git log` and neither use the pager. Should I apply the provided patch to the Git for Windows master branch? Also I'm not sure if there is a convenient way to apply a patch via email, so should I copy paste it to a file then apply the file? I'm assuming your patch depended on -p working but not without it, so I'm not sure if you still think the patch might help. Let me know! Thanks for your help. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/25] Add new environment variable $GIT_COMMON_DIR
From: Duy Nguyen pclo...@gmail.com On Wed, Feb 26, 2014 at 8:24 AM, Eric Sunshine sunsh...@sunshineco.com wrote: +'GIT_COMMON_DIR':: + If this variable is set to a path, non-worktree files that are + normally in $GIT_DIR will be taken from this path + instead. Worktree-specific files such as HEAD or index are + taken from $GIT_DIR. This variable has lower precedence than + other path variables such as GIT_INDEX_FILE, + GIT_OBJECT_DIRECTORY... For a person not familiar with git checkout --to or its underlying implementation, this description may be lacking. Such a reader may be left wondering about GIT_COMMON_DIR's overall purpose, and when and how it should be used. Perhaps it would make sense to talk a bit about git checkout --to here? I don't want to repeat too much. Maybe mention about git checkout --to and point them to git-checkout man page? I've just looked at both https://www.kernel.org/pub/software/scm/git/docs/git-checkout.html and http://git-htmldocs.googlecode.com/git/git-checkout.html and neither appear to mention the --to option. Is it missing from the man page? Or is it me that's missing something? -- Philip -- 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
Doc target fails to parse user-manual.xml
Hi, I'm installing git 1.9.0 from source, on a freshly installed SLES 11 SP3. The git binaries work fine to compile and install, but `make doc` fails on some XML parsing errors. The system is fully updated with the latest stable packages in the SLES 11 SP3 distribution. What I've done is: - Extracted the 1.9.0 source code from GitHub. - Ran `make configure` as regular user. - Ran `./configure --prefix=/usr/local` as regular user. - Ran `make all` as regular user - this works fine. - Ran `make doc` as regular user - the log from this is below. - 8 - foo@bar:~ rpm -qa|grep xml libxml2-python-2.7.6-0.23.1 php53-xmlwriter-5.3.17-0.13.7 libxml2-2.7.6-0.23.1 libxml2-32bit-2.7.6-0.23.1 php53-xmlreader-5.3.17-0.13.7 xmlcharent-0.3-403.14 python-xml-2.6.8-0.15.1 yast2-xml-2.16.1-1.23 foo@bar:~ rpm -qa|grep doc docbook_4-4.5-111.14 pam-doc-1.1.5-0.10.17 perl-doc-5.10.0-64.67.52 readline-doc-5.2-147.17.30 docbook-xsl-stylesheets-1.78.1-0.7.17 apparmor-docs-2.5.1.r1445-55.59.1 asciidoc-8.2.7-29.21 PolicyKit-doc-0.9-14.39.2 nfs-doc-1.2.3-18.29.1 bash-doc-3.2-147.17.30 postgresql91-docs-9.1.9-0.3.1 foo@bar:~/git-1.9.0 make doc make -C Documentation all make[1]: Entering directory `/home/foo/git-1.9.0/Documentation' GEN mergetools-list.made GEN cmd-list.made GEN doc.dep make[2]: Entering directory `/home/foo/git-1.9.0' make[2]: `GIT-VERSION-FILE' is up to date. make[2]: Leaving directory `/home/foo/git-1.9.0' make[1]: Leaving directory `/home/foo/git-1.9.0/Documentation' make[1]: Entering directory `/home/foo/git-1.9.0/Documentation' make[2]: Entering directory `/home/foo/git-1.9.0' make[2]: `GIT-VERSION-FILE' is up to date. make[2]: Leaving directory `/home/foo/git-1.9.0' ASCIIDOC git-add.html ASCIIDOC git-am.html ASCIIDOC git-annotate.html ASCIIDOC git-apply.html ASCIIDOC git-archimport.html ASCIIDOC git-archive.html ASCIIDOC git-bisect.html ASCIIDOC git-blame.html ASCIIDOC git-branch.html ASCIIDOC git-bundle.html ASCIIDOC git-cat-file.html ASCIIDOC git-check-attr.html ASCIIDOC git-check-ignore.html ASCIIDOC git-check-mailmap.html ASCIIDOC git-checkout-index.html ASCIIDOC git-checkout.html ASCIIDOC git-check-ref-format.html ASCIIDOC git-cherry-pick.html ASCIIDOC git-cherry.html ASCIIDOC git-citool.html ASCIIDOC git-clean.html ASCIIDOC git-clone.html ASCIIDOC git-column.html ASCIIDOC git-commit-tree.html ASCIIDOC git-commit.html ASCIIDOC git-config.html ASCIIDOC git-count-objects.html ASCIIDOC git-credential-cache--daemon.html ASCIIDOC git-credential-cache.html ASCIIDOC git-credential-store.html ASCIIDOC git-credential.html ASCIIDOC git-cvsexportcommit.html ASCIIDOC git-cvsimport.html ASCIIDOC git-cvsserver.html ASCIIDOC git-daemon.html ASCIIDOC git-describe.html ASCIIDOC git-diff-files.html ASCIIDOC git-diff-index.html ASCIIDOC git-difftool.html ASCIIDOC git-diff-tree.html ASCIIDOC git-diff.html ASCIIDOC git-fast-export.html ASCIIDOC git-fast-import.html ASCIIDOC git-fetch-pack.html ASCIIDOC git-fetch.html ASCIIDOC git-filter-branch.html ASCIIDOC git-fmt-merge-msg.html ASCIIDOC git-for-each-ref.html ASCIIDOC git-format-patch.html ASCIIDOC git-fsck-objects.html ASCIIDOC git-fsck.html ASCIIDOC git-gc.html ASCIIDOC git-get-tar-commit-id.html ASCIIDOC git-grep.html ASCIIDOC git-gui.html ASCIIDOC git-hash-object.html ASCIIDOC git-help.html ASCIIDOC git-http-backend.html ASCIIDOC git-http-fetch.html ASCIIDOC git-http-push.html ASCIIDOC git-imap-send.html ASCIIDOC git-index-pack.html ASCIIDOC git-init-db.html ASCIIDOC git-init.html ASCIIDOC git-instaweb.html ASCIIDOC git-log.html ASCIIDOC git-ls-files.html ASCIIDOC git-ls-remote.html ASCIIDOC git-ls-tree.html ASCIIDOC git-mailinfo.html ASCIIDOC git-mailsplit.html ASCIIDOC git-merge-base.html ASCIIDOC git-merge-file.html ASCIIDOC git-merge-index.html ASCIIDOC git-merge-one-file.html ASCIIDOC git-mergetool--lib.html ASCIIDOC git-mergetool.html ASCIIDOC git-merge-tree.html ASCIIDOC git-merge.html ASCIIDOC git-mktag.html ASCIIDOC git-mktree.html ASCIIDOC git-mv.html ASCIIDOC git-name-rev.html ASCIIDOC git-notes.html ASCIIDOC git-p4.html ASCIIDOC git-pack-objects.html ASCIIDOC git-pack-redundant.html ASCIIDOC git-pack-refs.html ASCIIDOC git-parse-remote.html ASCIIDOC git-patch-id.html ASCIIDOC git-prune-packed.html ASCIIDOC git-prune.html ASCIIDOC git-pull.html ASCIIDOC git-push.html ASCIIDOC git-quiltimport.html ASCIIDOC git-read-tree.html ASCIIDOC git-rebase.html ASCIIDOC git-receive-pack.html ASCIIDOC git-reflog.html ASCIIDOC git-relink.html ASCIIDOC git-remote-ext.html WARNING: git-remote-ext.txt: line 11: missing macro section: [ext]-inlinemacro
Re: Cygwin + git log = no pager!
Copying the patch from the email text results in corrupted patch, something isn't quite right with it so it won't let me apply it. Can you attach it as an actual file so I can try again? 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] GSoC 2014 Microproject 1 rewrite skip_prefix() as loop
Hi,
I am Faiz Kothari, I am a GSoC aspirant and want to contribute to git.
I am submitting the patch in reponse to Microproject 1,
rewrite git-compat-util.h:skip_prefix() as a loop.
Signed-off-by: Faiz Kothari faiz.of...@gmail.com
---
git-compat-util.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/git-compat-util.h b/git-compat-util.h
index cbd86c3..bb2582a 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -357,8 +357,11 @@ extern int suffixcmp(const char *str, const char
*suffix);
static inline const char *skip_prefix(const char *str, const char
*prefix)
{
- size_t len = strlen(prefix);
- return strncmp(str, prefix, len) ? NULL : str + len;
+ for (; ; str++, prefix++)
+ if (!*prefix)
+ return str;//code same as strbuf.c:starts_with()
+ else if (*str != *prefix)
+ return NULL;
}
#if defined(NO_MMAP) || defined(USE_WIN32_MMAP)
--
1.9.0.1.ge8df331
--
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 in GSoC 2014
On Wed, Feb 26, 2014 at 3:30 AM, Jeff King p...@peff.net wrote: On Wed, Feb 26, 2014 at 12:24:13PM +0100, Vicent Martí wrote: One thing I noticed after tg/index-v4-format is both libgit2 and jgit do not seem to support index v4. So we could add index v4 support on libgit2 to the idea page. It's a relatively small task though once you get a hang on index format. That sounds like a nice task for the Summer of Code too, specially with the current effort to make Index v4 more visible in Core Git. Yeah, I'd agree. Want to write it up? I wonder if anybody from JGit would also be interested on mentoring for the equivalent task (index v4 on JGit). I've CC'ed Shawn Pearce. A project that added to both libgit2 and JGit would be cool, but I don't know if that is asking too much of the student (multiple languages and projects is going to increase the time spent on non-code friction). I agree, its too much to ask from a single student to add it to both projects. As far as JGit supporting index v4, I am holding my breath and waiting for index v5. We keep spinning through dircache versions with relatively little gain for each one, but a lot of complexity. As it was a prior version was sort of a disaster with the fixed length portion of records being either 62 or 64 bytes depending on a bit set per record. Yuck. I haven't been reading every message in the v4 topic but nothing impressed me as being worth my time to implement in JGit, other than to be compatible with a version of git-core that won't land in Debian stable for at least 2 more years. -- 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 in GSoC 2014 Suggestion: core.filemode always false for cygwin
On 2014-02-25 16.41, Jeff King wrote: I'm pleased to announce that Git has been accepted to this year's Google Summer of Code. I'm not sure if this is the right way to propose mini projects, but in case the answer is not no, may I suggest one: Motivation, the problem: Since commit c28facd216b501d41ca76f cygwin: stop forcing core.filemode=false Git under cygwin initializes repos with core.filemode = true under NTFS This allows a smooth workflow, when e.g. *.sh files are pushed and pulled between Cygwin, Linux/Unix or Mac OS. However when I visit such a repo under Mingw, then Mingw reads core.filemode =true, but is unable to detect whether the X-bit is set, and reads it as not set. Therefore git status thinks that e.g. all *.sh files have lost the executable bit, abd reports them as changed. Proposal: Under Mingw, keep trust_executable_bit always false, regardless what core.filemode says. Activate NO_TRUSTABLE_FILEMODE in config.mak.uname for Mingw (currently it is not used to anything) Keep the logic in init-db.c to initialize core.filemode = false under Mingw Language: C Difficulty: easy -- 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 10/25] Add new environment variable $GIT_COMMON_DIR
On Wed, Feb 26, 2014 at 11:12 AM, Philip Oakley philipoak...@iee.org wrote: From: Duy Nguyen pclo...@gmail.com On Wed, Feb 26, 2014 at 8:24 AM, Eric Sunshine sunsh...@sunshineco.com wrote: +'GIT_COMMON_DIR':: + If this variable is set to a path, non-worktree files that are + normally in $GIT_DIR will be taken from this path + instead. Worktree-specific files such as HEAD or index are + taken from $GIT_DIR. This variable has lower precedence than + other path variables such as GIT_INDEX_FILE, + GIT_OBJECT_DIRECTORY... For a person not familiar with git checkout --to or its underlying implementation, this description may be lacking. Such a reader may be left wondering about GIT_COMMON_DIR's overall purpose, and when and how it should be used. Perhaps it would make sense to talk a bit about git checkout --to here? I don't want to repeat too much. Maybe mention about git checkout --to and point them to git-checkout man page? I've just looked at both https://www.kernel.org/pub/software/scm/git/docs/git-checkout.html and http://git-htmldocs.googlecode.com/git/git-checkout.html and neither appear to mention the --to option. Is it missing from the man page? Or is it me that's missing something? 'git checkout --to' is the new feature being introduced by this 25-patch series [1] from Duy (to which we are responding). [1]: http://thread.gmane.org/gmane.comp.version-control.git/242300 -- 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
[RFC 3/3] reset: Change the default behavior to use --merge during a merge
If the user wants to do git reset during a merge, the user most likely
wants to do a git reset --merge. This is especially true during a
merge conflict and the user had local changes, because git reset would
leave the merged changes mixed in with the local changes. This makes
git reset a little more user-friendly during a merge.
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
builtin/reset.c | 7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
diff --git a/builtin/reset.c b/builtin/reset.c
index 6004803..740263d 100644
--- a/builtin/reset.c
+++ b/builtin/reset.c
@@ -318,7 +318,12 @@ int cmd_reset(int argc, const char **argv, const char
*prefix)
_(reset_type_names[reset_type]));
}
if (reset_type == NONE)
- reset_type = MIXED; /* by default */
+ {
+ if(is_merge())
+ reset_type = MERGE;
+ else
+ reset_type = MIXED;
+ }
if (reset_type != SOFT reset_type != MIXED)
setup_work_tree();
--
1.9.0.6.g16e5f9a
--
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
[RFC 2/3] merge: Add hints to tell users about git merge --abort
Signed-off-by: Andrew Wong andrew.k...@gmail.com --- builtin/merge.c | 3 ++- wt-status.c | 3 +++ 2 files changed, 5 insertions(+), 1 deletion(-) diff --git a/builtin/merge.c b/builtin/merge.c index e576a7f..07af427 100644 --- a/builtin/merge.c +++ b/builtin/merge.c @@ -909,7 +909,8 @@ static int suggest_conflicts(int renormalizing) fclose(fp); rerere(allow_rerere_auto); printf(_(Automatic merge failed; - fix conflicts and then commit the result.\n)); + fix conflicts and then commit the result.\n + To abort the merge, use \git merge --abort\.\n)); return 1; } diff --git a/wt-status.c b/wt-status.c index 6e1ad7d..54c2203 100644 --- a/wt-status.c +++ b/wt-status.c @@ -907,6 +907,9 @@ static void show_merge_in_progress(struct wt_status *s, status_printf_ln(s, color, _( (use \git commit\ to conclude merge))); } + if (s-hints) + status_printf_ln(s, color, + _( (use \git merge --abort\ to abort the merge)\n)); wt_status_print_trailer(s); } -- 1.9.0.6.g16e5f9a -- 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
[RFC 1/3] wt-status: Make conflict hint message more consistent with other hints
Signed-off-by: Andrew Wong andrew.k...@gmail.com
---
wt-status.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/wt-status.c b/wt-status.c
index 4e55810..6e1ad7d 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -899,7 +899,7 @@ static void show_merge_in_progress(struct wt_status *s,
status_printf_ln(s, color, _(You have unmerged paths.));
if (s-hints)
status_printf_ln(s, color,
- _( (fix conflicts and run \git commit\)));
+ _( (fix conflicts, and use \git commit\ to
conclude the merge)));
} else {
status_printf_ln(s, color,
_(All conflicts fixed but you are still merging.));
--
1.9.0.6.g16e5f9a
--
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
[RFC 0/3] Make git more user-friendly during a merge conflict
Users may not be aware that they need to use git merge --abort or git reset --merge to properly abort a merge conflict. They are likely to just use git reset, because that usually cleans up the repo. But in the case where the user had local changes, git reset would leave the repo in a messy state where merged changes and local changes are mixed together. The first two patches are just about rewording a message, and adding messages to tell users to use git merge --abort to abort a merge. We could stop here and hope that the users would read the messages, but I think git could be a bit more user-friendly. The last patch might be a bit more controversial. It changes the default behavior of git reset to default to git reset --merge during a merge conflict. I imagine that's what the user would want most of the time, and not git reset --mixed. I haven't updated the git reset docs yet, I'll update it if we decide to use this new behavior. Comments? Andrew Wong (3): wt-status: Make conflict hint message more consistent with other hints merge: Add hints to tell users about git merge --abort reset: Change the default behavior to use --merge during a merge builtin/merge.c | 3 ++- builtin/reset.c | 7 ++- wt-status.c | 5 - 3 files changed, 12 insertions(+), 3 deletions(-) -- 1.9.0.6.g16e5f9a -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] reset: Change the default behavior to use --merge during a merge
Andrew Wong andrew.k...@gmail.com writes: If the user wants to do git reset during a merge, the user most likely wants to do a git reset --merge. This is especially true during a merge conflict and the user had local changes, because git reset would leave the merged changes mixed in with the local changes. This makes git reset a little more user-friendly during a merge. But this breaks backward compatibility. I sometimes run git reset during a merge to only reset the index and then examine the changes introduced by the merge. With your changes, someone doing so would abort the merge and discard the merge resolution. I very rarely do this, but even rarely, I wouldn't like Git to start droping data silently for me ;-). I'm not really convinced that this is such a good change, and if we go this way, there should be a transition to let users stop using argumentless git reset to reset the index during a merge. The other 2 patches look good to me. -- 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
Compiling git for Windows
Oddly I'm not able to find any instructions on how to build Git for Windows. I've done a clone of the repository here: https://github.com/msysgit/git I did attempt to try doing it myself. I installed 'make' and mingw-gcc in Cygwin and attempted 'make' from the git directory but it fails immediately (I can post information on the failure if needed, but I'm assuming I'm not taking the correct approach). Can someone point me to some instructions on how to build Git for Windows? 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 v2] commit.c: use the generic sha1_pos function for lookup
Refactor binary search in commit_graft_pos function: use
generic sha1_pos function.
Signed-off-by: Dmitry S. Dolzhenko dmitrys.dolzhe...@yandex.ru
---
commit.c | 24 +---
1 file changed, 9 insertions(+), 15 deletions(-)
diff --git a/commit.c b/commit.c
index 6bf4fe0..6ceee6a 100644
--- a/commit.c
+++ b/commit.c
@@ -10,6 +10,7 @@
#include mergesort.h
#include commit-slab.h
#include prio-queue.h
+#include sha1-lookup.h
static struct commit_extra_header *read_commit_extra_header_lines(const char
*buf, size_t len, const char **);
@@ -114,23 +115,16 @@ static unsigned long parse_commit_date(const char *buf,
const char *tail)
static struct commit_graft **commit_graft;
static int commit_graft_alloc, commit_graft_nr;
+static const unsigned char *commit_graft_sha1_access(size_t index, void *table)
+{
+ struct commit_graft **commit_graft_table = table;
+ return commit_graft_table[index]-sha1;
+}
+
static int commit_graft_pos(const unsigned char *sha1)
{
- int lo, hi;
- lo = 0;
- hi = commit_graft_nr;
- while (lo hi) {
- int mi = (lo + hi) / 2;
- struct commit_graft *graft = commit_graft[mi];
- int cmp = hashcmp(sha1, graft-sha1);
- if (!cmp)
- return mi;
- if (cmp 0)
- hi = mi;
- else
- lo = mi + 1;
- }
- return -lo - 1;
+ return sha1_pos(sha1, commit_graft, commit_graft_nr,
+ commit_graft_sha1_access);
}
int register_commit_graft(struct commit_graft *graft, int ignore_dups)
--
1.8.3.2
--
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] commit.c: use the generic sha1_pos function for lookup sha1
Thank you for your remarks. I'll try to fix my patch and send it again. -- 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 stash pop` UX Problem
Matthieu Moy matthieu@grenoble-inp.fr writes: Omar Othman omar.oth...@booking.com writes: Though I don't know why you think this is important: Now, the real question is: when would Git stop showing this advice. I don't see a real way to answer this, and I'd rather avoid doing just a guess. If it is really annoying for the user, we can just have a configuration parameter to switch this message on/off. Just saying You have X stash is OK to me as long as there is an option to deactivate it. Hinting You should now run git stash drop. OTOH is far more dangerous if guessed wrong. Keeping a stash active when you don't need it does no real harm, but droping one you actually needed is data loss. Yes, definitely. I'm inclined to say that we should go in the direction you suggested earlier in Message-ID: vpqlhx0a3cb@anie.imag.fr, that is: One easy thing to do OTOH would be to show a hint at the end of git stash pop's output, like $ git stash pop Auto-merging foo.txt CONFLICT (content): Merge conflict in foo.txt 'stash pop' failed. Please, resolve the conflicts manually. The stash was not dropped in case you need to restart the operation. When you are done resolving the merge, you may run the following to drop the stash: git stash drop or so (I couldn't find a concise yet accurate wording). I'd however have to say that even please resolve the conflicts manually is over-assuming. I often start some WIP of a fix, realize that the fix should apply to a lot older maintenance branch than where I happened to have started the WIP (which typically is at the tip of somebody else's branch where I received the series from the list---and then noticed some existing breakage that needs to be fixed), stash the WIP, and then repeat: (1) checkout an old maintenance track; (2) try to pop; (3) if it succeeds, stop the iteration; (4) otherwise, reset and go back to (1) to checkout a bit newer maintenance track. to decide. So resolve the conflicts is assuming the intention of the user who issued pop too much (let alone manually---it does not matter how the user resolves conflicts---the only thing we want to say is Git did all it would and no further automated help in resolving is availble, but manually is not quite the word). The stash was not dropped is the most important thing in your additional text. How about rephrasing like this? $ git stash pop Auto-merging foo.txt CONFLICT (content): Merge conflict in foo.txt The stashed change could not be replayed cleanly, leaving conflicts in the working tree. The stash was not dropped in case you need it again. After you are done with the stash, you may want to git stash drop to discard it. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Compiling git for Windows
From: Robert Dailey rcdailey.li...@gmail.com Oddly I'm not able to find any instructions on how to build Git for Windows. I've done a clone of the repository here: https://github.com/msysgit/git I did attempt to try doing it myself. I installed 'make' and mingw-gcc in Cygwin and attempted 'make' from the git directory but it fails immediately (I can post information on the failure if needed, but I'm assuming I'm not taking the correct approach). Can someone point me to some instructions on how to build Git for Windows? Thanks. -- Try the wiki https://github.com/msysgit/msysgit/wiki The dev list is at msys...@googlegroups.com; -- Philip -- 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 10/25] Add new environment variable $GIT_COMMON_DIR
On Wed, Feb 26, 2014 at 5:55 AM, Duy Nguyen pclo...@gmail.com wrote: On Wed, Feb 26, 2014 at 8:24 AM, Eric Sunshine sunsh...@sunshineco.com wrote: +'GIT_COMMON_DIR':: + If this variable is set to a path, non-worktree files that are + normally in $GIT_DIR will be taken from this path + instead. Worktree-specific files such as HEAD or index are + taken from $GIT_DIR. This variable has lower precedence than + other path variables such as GIT_INDEX_FILE, + GIT_OBJECT_DIRECTORY... For a person not familiar with git checkout --to or its underlying implementation, this description may be lacking. Such a reader may be left wondering about GIT_COMMON_DIR's overall purpose, and when and how it should be used. Perhaps it would make sense to talk a bit about git checkout --to here? I don't want to repeat too much. Maybe mention about git checkout --to and point them to git-checkout man page? Yes, that might be sufficient. git checkout --to documentation points the reader at the MULTIPLE CHECKOUT MODE section which gives a more detailed explanation of GIT_COMMON_DIR, so a user wanting to understand GIT_COMMON_DIR better would have a way to find the information. -- 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 in GSoC 2014
Michael Haggerty mhag...@alum.mit.edu writes:
See my branch on GitHub [1] or read the appended text below.
Very nice.
## Introduction
It is strongly recommended that students who want to apply to the Git
project for the Summer of Code 2014 should submit a small code-related
patch to the Git project as part of their application. Think of these
microprojects as the Hello, world of getting involved with the Git
project; the coding aspect of the change can be almost trivial, but to
make the change the student has to become familiar with many of the
practical aspects of working on the Git project:
I'd suggest one step before all of the below.
* Here (http://thread.gmane.org/{TBD1,TBD2,TBD3...}) are a sample
set of threads that show how a change and a patch to implement it
is proposed by a developer X, the problem it attempts to solve,
the design of the proposed solution and the implementation of
that design are reviewed and discussed, and that after several
iterations it resulted in inclusion to our codebase. As a GSoC
student, you will be playing the role of X and engaging in a
similar discussion. Get familar with the flow, need for clarity
on both sides (i.e. you need to clearly defend your design, and
need to ask clarifications when questions/suggestions you are
offered are not clear enough), the pace at which the discussion
takes place, and the general tone of the discussion, to learn
what is expected of you.
That would help the later step, namely:
* Expect feedback, criticism, suggestions, etc. from the mailing list.
*Respond to it!* and follow up with improved versions of your
change. Even for a trivial patch you shouldn't be surprised if it
takes two or more iterations before your patch is accepted. *This
is the best part of the Git community; it is your chance to get
personalized instruction from very experienced peers!*
--
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: GSoC idea: allow git rebase --interactive todo lines to take options
Jeff King p...@peff.net writes: On Wed, Feb 26, 2014 at 09:04:30AM +0100, Michael Haggerty wrote: It would be nice to support more flexibility in the todo-list commands by allowing the commands to take options. Maybe * Convert a commit into a merge commit: pick -p c0ffeee -p e1ee712 deadbab The oneline of the commit after This seems like a reasonable feature to me. All of your examples are possible with an edit and another git command, but the convenience may be worth it (though personally, most of the examples you gave are particularly interesting to me[1]). I actually had a completely opposite reaction to the above one. It took considerable mental effort to decipher what that pick -p ... line was trying to do, and I am not absolutely sure if I understand what it is trying to do enough to rewrite it to an equivalent inconvenient sequence of edit and another git command. [1] The one feature I would like in this vein is that editing the title in the instruction-sheet would modify the commit message of the relevant commit. For some reason I try to do this every few weeks, but of course the changes are just thrown away. Every time I thought about this one, I get stopped after realizing that the title line is only a small part of the log message. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: An idea for git bisect and a GSoC enquiry
Jacopo Notarstefano jacopo.notarstef...@gmail.com writes: Does this make sense? Did I overlook some details? How does this solve the labels shown in git bisect visualize? -- 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 stash pop` UX Problem
Junio C Hamano gits...@pobox.com writes: I'd however have to say that even please resolve the conflicts manually is over-assuming. I understand your point, but in a short hint message, I still find it reasonable. Fixing conflicts is the natural way to go after a stash pop, and the user who do not want to go this way probably knows why. The stash was not dropped is the most important thing in your additional text. How about rephrasing like this? $ git stash pop Auto-merging foo.txt CONFLICT (content): Merge conflict in foo.txt The stashed change could not be replayed cleanly, leaving conflicts in the working tree. The stash was not dropped in case you need it again. After you are done with the stash, you may want to git stash drop to discard it. I'm fine with this, but it's even longer than mine which I already found too long. Perhaps the leaving conflicts in the working tree could be dropped, as the message follows CONFLICT (content): Merge conflict in foo.txt. -- 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 21/25] checkout: support checking out into a new working directory
On Tue, Feb 18, 2014 at 8:40 AM, Nguyễn Thái Ngọc Duy pclo...@gmail.com wrote:
git checkout --to sets up a new working directory with a .git file
pointing to $GIT_DIR/repos/id. It then executes git checkout again
on the new worktree with the same arguments except --to is taken
out. The second checkout execution, which is not contaminated with any
info from the current repository, will actually check out and
everything that normal git checkout does.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
diff --git a/builtin/checkout.c b/builtin/checkout.c
index 0570e41..2b856a6 100644
--- a/builtin/checkout.c
+++ b/builtin/checkout.c
@@ -806,6 +814,74 @@ static int switch_branches(const struct checkout_opts
*opts,
return ret || writeout_error;
}
+static int prepare_linked_checkout(const struct checkout_opts *opts,
+ struct branch_info *new)
+{
+ struct strbuf sb_git = STRBUF_INIT, sb_repo = STRBUF_INIT;
+ struct strbuf sb = STRBUF_INIT;
+ const char *path = opts-new_worktree;
+ struct stat st;
+ const char *name;
+ struct child_process cp;
+ int counter = 0, len;
+
+ if (!new-commit)
+ die(_(no branch specified));
+
+ len = strlen(path);
+ if (!len || is_dir_sep(path[len - 1]))
+ die(_('--to' argument '%s' cannot end with a slash), path);
What is the purpose of this restriction?
+ for (name = path + len - 1; name path; name--)
+ if (is_dir_sep(*name)) {
+ name++;
+ break;
+ }
+ strbuf_addstr(sb_repo, git_path(repos/%s, name));
+ len = sb_repo.len;
+ if (safe_create_leading_directories_const(sb_repo.buf))
+ die_errno(_(could not create leading directories of '%s'),
+ sb_repo.buf);
+ while (!stat(sb_repo.buf, st)) {
+ counter++;
+ strbuf_setlen(sb_repo, len);
+ strbuf_addf(sb_repo, %d, counter);
+ }
+ name = sb_repo.buf + len - strlen(name);
+ if (mkdir(sb_repo.buf, 0777))
+ die_errno(_(could not create directory of '%s'),
sb_repo.buf);
+
+ strbuf_addf(sb_git, %s/.git, path);
+ if (safe_create_leading_directories_const(sb_git.buf))
+ die_errno(_(could not create leading directories of '%s'),
+ sb_git.buf);
+
+ write_file(sb_git.buf, 1, gitdir: %s/repos/%s\n,
+ real_path(get_git_dir()), name);
+ /*
+* This is to keep resolve_ref() happy. We need a valid HEAD
+* or is_git_directory() will reject the directory. Any valid
+* value would do because this value will be ignored and
+* replaced at the next (real) checkout.
+*/
+ strbuf_addf(sb, %s/HEAD, sb_repo.buf);
+ write_file(sb.buf, 1, %s\n, sha1_to_hex(new-commit-object.sha1));
+ strbuf_reset(sb);
+ strbuf_addf(sb, %s/commondir, sb_repo.buf);
+ write_file(sb.buf, 1, ../..\n);
+
+ if (!opts-quiet)
+ fprintf_ln(stderr, _(Enter %s (identifier %s)), path, name);
+
+ setenv(GIT_CHECKOUT_NEW_WORKTREE, 1, 1);
+ setenv(GIT_DIR_ENVIRONMENT, sb_git.buf, 1);
+ setenv(GIT_WORK_TREE_ENVIRONMENT, path, 1);
+ memset(cp, 0, sizeof(cp));
+ cp.git_cmd = 1;
+ cp.argv = opts-saved_argv;
+ return run_command(cp);
+}
+
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] reset: Change the default behavior to use --merge during a merge
On Wed, Feb 26, 2014 at 1:21 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: But this breaks backward compatibility. I sometimes run git reset during a merge to only reset the index and then examine the changes introduced by the merge. With your changes, someone doing so would abort the merge and discard the merge resolution. I very rarely do this, but even rarely, I wouldn't like Git to start droping data silently for me ;-). I don't think it's actually dropping data though, because your changes just come from git merge. So you can also do the merge again. To examine the changes, you're saying you'd do git reset git diff. But without doing git reset, couldn't you do git diff HEAD to get the diff? This also has the advantage of keeping git in the merging state, so you can decide to continue/abort the merge later on. I'm not really convinced that this is such a good change, and if we go this way, there should be a transition to let users stop using argumentless git reset to reset the index during a merge. Yeah, this breaks compatibility, but like I said, during a merge, I don't see a good reason to do git reset --mixed, and not git reset --merge. Especially when there are local changes, --mixed would actually cause more headaches than git reset --merge, because you would lose the distinction between merge changes and unstaged changes. Andrew -- 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 stash pop` UX Problem
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: I'd however have to say that even please resolve the conflicts manually is over-assuming. I understand your point, but in a short hint message, I still find it reasonable. Fixing conflicts is the natural way to go after a stash pop, and the user who do not want to go this way probably knows why. The stash was not dropped is the most important thing in your additional text. How about rephrasing like this? $ git stash pop Auto-merging foo.txt CONFLICT (content): Merge conflict in foo.txt The stashed change could not be replayed cleanly, leaving conflicts in the working tree. The stash was not dropped in case you need it again. After you are done with the stash, you may want to git stash drop to discard it. I'm fine with this, but it's even longer than mine which I already found too long. Perhaps the leaving conflicts in the working tree could be dropped, as the message follows CONFLICT (content): Merge conflict in foo.txt. Surely. s/was not dropped/is kept/ would make the result even shorter. We can also remove the last three lines, for that matter. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 0/3] Make git more user-friendly during a merge conflict
Hi, Andrew Wong wrote: The first two patches are just about rewording a message, and adding messages to tell users to use git merge --abort to abort a merge. Sounds like a good idea. I look forward to reading the patches. We could stop here and hope that the users would read the messages, but I think git could be a bit more user-friendly. The last patch might be a bit more controversial. It changes the default behavior of git reset to default to git reset --merge during a merge conflict. I imagine that's what the user would want most of the time, and not git reset --mixed. I don't think that's a good idea. I'm not sure what new users would expect; in any case, making the command context-dependent just makes the learning process harder imho. And for experienced users, this would be a bad regression. An 'advice' message pointing the user to 'git merge --abort' might make sense, though. What do you think? Thanks, Jonathan -- 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] repack: add `repack.honorpackkeep` config var
Jeff King p...@peff.net writes: On Mon, Feb 24, 2014 at 11:10:49AM -0800, Junio C Hamano wrote: The best name I could come up with is --pack-keep-objects, since that is literally what it is doing. I'm not wild about the name because it is easy to read keep as a verb (and pack as a noun). I think it's OK, but suggestions are welcome. pack-kept-objects then? Hmm. That does address my point above, but somehow the word kept feels awkward to me. I'm ambivalent between the two. That word does make my backside somewhat itchy ;-) Would it help to take a step back and think what the option really does? Perhaps we should call it --pack-all-objects, which is short for --pack-all-objectsregardless-of-where-they-currently-are-stored, or something? The word all gives a wrong connotation in a different way (e.g. regardless of reachability is a possible wrong interpretation), so that does not sound too good, either. --repack-kept-objects? --include-kept-objects? -- 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: Doc target fails to parse user-manual.xml
On Wed, Feb 26, 2014 at 11:13 AM, Leo R. Lundgren l...@finalresort.org wrote: I'm installing git 1.9.0 from source, on a freshly installed SLES 11 SP3. The git binaries work fine to compile and install, but `make doc` fails on some XML parsing errors. The system is fully updated with the latest stable packages in the SLES 11 SP3 distribution. What I've done is: - 8 - foo@bar:~ rpm -qa|grep xml libxml2-python-2.7.6-0.23.1 php53-xmlwriter-5.3.17-0.13.7 libxml2-2.7.6-0.23.1 libxml2-32bit-2.7.6-0.23.1 php53-xmlreader-5.3.17-0.13.7 xmlcharent-0.3-403.14 python-xml-2.6.8-0.15.1 yast2-xml-2.16.1-1.23 foo@bar:~ rpm -qa|grep doc docbook_4-4.5-111.14 pam-doc-1.1.5-0.10.17 perl-doc-5.10.0-64.67.52 readline-doc-5.2-147.17.30 docbook-xsl-stylesheets-1.78.1-0.7.17 apparmor-docs-2.5.1.r1445-55.59.1 asciidoc-8.2.7-29.21 PolicyKit-doc-0.9-14.39.2 nfs-doc-1.2.3-18.29.1 bash-doc-3.2-147.17.30 postgresql91-docs-9.1.9-0.3.1 Some of these packages are pretty old and possibly buggy. The documentation builds cleanly on my Linux and Mac boxes, but they are using newer versions of these tools. For instance, I have asciidoc 8.6.7 on Linux, and 8.6.9 on Mac, whereas your version is only at 8.2.7. Perhaps try updating your toolchain. foo@bar:~/git-1.9.0 make doc make -C Documentation all make[1]: Entering directory `/home/foo/git-1.9.0/Documentation' GEN mergetools-list.made GEN cmd-list.made GEN doc.dep make[2]: Entering directory `/home/foo/git-1.9.0' make[2]: `GIT-VERSION-FILE' is up to date. make[2]: Leaving directory `/home/foo/git-1.9.0' make[1]: Leaving directory `/home/foo/git-1.9.0/Documentation' make[1]: Entering directory `/home/foo/git-1.9.0/Documentation' make[2]: Entering directory `/home/foo/git-1.9.0' make[2]: `GIT-VERSION-FILE' is up to date. make[2]: Leaving directory `/home/foo/git-1.9.0' ASCIIDOC git-add.html ASCIIDOC git-am.html ASCIIDOC git-annotate.html ASCIIDOC git-apply.html ASCIIDOC git-archimport.html ASCIIDOC git-archive.html ASCIIDOC git-bisect.html ASCIIDOC git-blame.html ASCIIDOC git-branch.html ASCIIDOC git-bundle.html ASCIIDOC git-cat-file.html ASCIIDOC git-check-attr.html ASCIIDOC git-check-ignore.html ASCIIDOC git-check-mailmap.html ASCIIDOC git-checkout-index.html ASCIIDOC git-checkout.html ASCIIDOC git-check-ref-format.html ASCIIDOC git-cherry-pick.html ASCIIDOC git-cherry.html ASCIIDOC git-citool.html ASCIIDOC git-clean.html ASCIIDOC git-clone.html ASCIIDOC git-column.html ASCIIDOC git-commit-tree.html ASCIIDOC git-commit.html ASCIIDOC git-config.html ASCIIDOC git-count-objects.html ASCIIDOC git-credential-cache--daemon.html ASCIIDOC git-credential-cache.html ASCIIDOC git-credential-store.html ASCIIDOC git-credential.html ASCIIDOC git-cvsexportcommit.html ASCIIDOC git-cvsimport.html ASCIIDOC git-cvsserver.html ASCIIDOC git-daemon.html ASCIIDOC git-describe.html ASCIIDOC git-diff-files.html ASCIIDOC git-diff-index.html ASCIIDOC git-difftool.html ASCIIDOC git-diff-tree.html ASCIIDOC git-diff.html ASCIIDOC git-fast-export.html ASCIIDOC git-fast-import.html ASCIIDOC git-fetch-pack.html ASCIIDOC git-fetch.html ASCIIDOC git-filter-branch.html ASCIIDOC git-fmt-merge-msg.html ASCIIDOC git-for-each-ref.html ASCIIDOC git-format-patch.html ASCIIDOC git-fsck-objects.html ASCIIDOC git-fsck.html ASCIIDOC git-gc.html ASCIIDOC git-get-tar-commit-id.html ASCIIDOC git-grep.html ASCIIDOC git-gui.html ASCIIDOC git-hash-object.html ASCIIDOC git-help.html ASCIIDOC git-http-backend.html ASCIIDOC git-http-fetch.html ASCIIDOC git-http-push.html ASCIIDOC git-imap-send.html ASCIIDOC git-index-pack.html ASCIIDOC git-init-db.html ASCIIDOC git-init.html ASCIIDOC git-instaweb.html ASCIIDOC git-log.html ASCIIDOC git-ls-files.html ASCIIDOC git-ls-remote.html ASCIIDOC git-ls-tree.html ASCIIDOC git-mailinfo.html ASCIIDOC git-mailsplit.html ASCIIDOC git-merge-base.html ASCIIDOC git-merge-file.html ASCIIDOC git-merge-index.html ASCIIDOC git-merge-one-file.html ASCIIDOC git-mergetool--lib.html ASCIIDOC git-mergetool.html ASCIIDOC git-merge-tree.html ASCIIDOC git-merge.html ASCIIDOC git-mktag.html ASCIIDOC git-mktree.html ASCIIDOC git-mv.html ASCIIDOC git-name-rev.html ASCIIDOC git-notes.html ASCIIDOC git-p4.html ASCIIDOC git-pack-objects.html ASCIIDOC git-pack-redundant.html ASCIIDOC git-pack-refs.html ASCIIDOC git-parse-remote.html ASCIIDOC git-patch-id.html ASCIIDOC git-prune-packed.html ASCIIDOC git-prune.html ASCIIDOC git-pull.html ASCIIDOC git-push.html ASCIIDOC git-quiltimport.html
Re: `git stash pop` UX Problem
Matthieu Moy matthieu@grenoble-inp.fr writes: Junio C Hamano gits...@pobox.com writes: I'd however have to say that even please resolve the conflicts manually is over-assuming. I understand your point, but in a short hint message, I still find it reasonable. Fixing conflicts is the natural way to go after a stash pop, and the user who do not want to go this way probably knows why. The stash was not dropped is the most important thing in your additional text. How about rephrasing like this? $ git stash pop Auto-merging foo.txt CONFLICT (content): Merge conflict in foo.txt The stashed change could not be replayed cleanly, leaving conflicts in the working tree. The stash was not dropped in case you need it again. After you are done with the stash, you may want to git stash drop to discard it. I'm fine with this, but it's even longer than mine which I already found too long. Perhaps the leaving conflicts in the working tree could be dropped, as the message follows CONFLICT (content): Merge conflict in foo.txt. All that verbosity... $ git stash pop Auto-merging foo.txt CONFLICT (content): Merge conflict in foo.txt Cowardly refusing to drop stash. $ -- David Kastrup -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] wt-status: Make conflict hint message more consistent with other hints
Hi, Andrew Wong wrote: [Subject: wt-status: Make conflict hint message more consistent with other hints] Thanks for working on this. Could you include a little more detail? What other hints is this making the message more consistent with? Ideally the commit message would include a quick sample interaction, so the reviewer could see the user going Wha? and then look at the patch to see how it resolves the confusion. [...] --- a/wt-status.c +++ b/wt-status.c @@ -899,7 +899,7 @@ static void show_merge_in_progress(struct wt_status *s, status_printf_ln(s, color, _(You have unmerged paths.)); if (s-hints) status_printf_ln(s, color, - _( (fix conflicts and run \git commit\))); + _( (fix conflicts, and use \git commit\ to conclude the merge))); Quick thoughts: - The comma just moves the message closer to the right margin. I think it makes the message less readable. - What else would git commit do other than concluding the merge? What confusion is this meant to prevent? - Would introducing a new git merge --continue command help? Advantages: (1) the name of the command makes it obvious what it does; (2) the command could check that there is actually a merge in progress, helping the user when the state is not what they think; (3) consistency with git cherry-pick --abort / git cherry-pick --continue. Disadvantage: redundancy (but see (2) above). Hope that helps, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] reset: Change the default behavior to use --merge during a merge
Andrew Wong wrote: Yeah, this breaks compatibility, but like I said, during a merge, I don't see a good reason to do git reset --mixed, and not git reset --merge. Yeah, in principle if it had a different behavior, then plain git reset could be useful during a merge, but as is, I tend to use the form with a path (git reset -- .) to avoid losing MERGE_HEAD. I really don't like the idea of making git reset modal, though. I'd rather that reset --mixed print some advice about how to recover from the mistake, which would also have the advantage of allowing scripts that for whatever reason used git reset in this situation to continue to work. Thanks, Jonathan -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] reset: Change the default behavior to use --merge during a merge
Matthieu Moy matthieu@grenoble-inp.fr writes: Andrew Wong andrew.k...@gmail.com writes: If the user wants to do git reset during a merge, the user most likely wants to do a git reset --merge. This is especially true during a merge conflict and the user had local changes, because git reset would leave the merged changes mixed in with the local changes. This makes git reset a little more user-friendly during a merge. But this breaks backward compatibility. I sometimes run git reset during a merge to only reset the index and then examine the changes introduced by the merge. H, wouldn't it a better way to do this to run git diff HEAD without any resetting of the index, though? Having said that... With your changes, someone doing so would abort the merge and discard the merge resolution. I very rarely do this, but even rarely, I wouldn't like Git to start droping data silently for me ;-). ...this indeed may be a concern that deserves a bit more thought. I'm not really convinced that this is such a good change, and if we go this way, there should be a transition to let users stop using argumentless git reset to reset the index during a merge. If the only reason somebody might want to reset --mixed is to make the next git diff behave as if it were git diff HEAD, I would be willing to say that we should: - start warning against reset (no mode specifier) and reset --mixed when the index is unmerged *and* MERGE_HEAD exists; and then - after a few releases start erroring out when such a reset is given; and then - use this patch to intelligently choose the default mode. Another downside of reset --mixed during a conflicted merge (or other mergy operations, e.g. am -3) is that new files are left in the working tree, making the next attempt to redo the mergy operation immediately fail until you remove them, so in practice, the only mode I'd use with a conflicted index (be it from a conflicted merge or any other mergy operation) is reset --hard. So forbidding reset --mixed when the index is unmerged (even when there is no MERGE_HEAD) may be a good idea in the long run. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] reset: Change the default behavior to use --merge during a merge
Andrew Wong andrew.k...@gmail.com writes: On Wed, Feb 26, 2014 at 1:21 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: But this breaks backward compatibility. I sometimes run git reset during a merge to only reset the index and then examine the changes introduced by the merge. With your changes, someone doing so would abort the merge and discard the merge resolution. I very rarely do this, but even rarely, I wouldn't like Git to start droping data silently for me ;-). I don't think it's actually dropping data though, because your changes just come from git merge. So you can also do the merge again. But you can't repeat your merge conflicts resolution. To examine the changes, you're saying you'd do git reset git diff. But without doing git reset, couldn't you do git diff HEAD to get the diff? I could. The point is, sometimes I don't. If you were to design git reset's interface from scratch, your proposal would make sense. But we're talking about a change, and you can't expect that users never use the current behavior. At the very least, there should be a warning telling the user that the behavior changed, and I'm really afraid that the warning goes along the lines of I've thought you'd prefer me to discard your unsaved changes, please rewrite them if you actually didn't want me to. I'm not really convinced that this is such a good change, and if we go this way, there should be a transition to let users stop using argumentless git reset to reset the index during a merge. Yeah, this breaks compatibility, but like I said, during a merge, I don't see a good reason to do git reset --mixed, The point with backward compatibility is not to know whether users have a good reason to, but whether you can guarantee that no one ever does 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
Branch Name Case Sensitivity
Hello, Last week I ran across a potential bug with branch names on case insensitive file systems, the complete scenario can be found here: https://groups.google.com/forum/#!topic/msysgit/ugKL-sVMiqI The tldr is because refs are stored as plain text files except when packed into packed-refs, Git occasionally cannot tell the difference between branches whose names only differ in case, and this could potentially lead to the loss of history. It sounds like this is a known issue, and after some more digging I did find some older threads related to this topic, but nothing recent. So I guess I just wanted to bring this to the attention of the Git devs and maybe restart some discussions. Thanks, -Lee -- 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 stash pop` UX Problem
David Kastrup d...@gnu.org writes:
All that verbosity...
$ git stash pop
Auto-merging foo.txt
CONFLICT (content): Merge conflict in foo.txt
Cowardly refusing to drop stash.
$
Actually, modulo Cowardly, that may be the most harmless phrasing,
as apply_stash may try to signal an error for reasons not related to
an inability to apply the change cleanly (e.g. we may have failed to
refresh the index).
Whatever phrasing we may end up choosing, the change itself should
be trivial in any case.
git-stash.sh | 10 --
1 file changed, 8 insertions(+), 2 deletions(-)
diff --git a/git-stash.sh b/git-stash.sh
index f0a94ab..4798bcf 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -512,8 +512,14 @@ apply_stash () {
pop_stash() {
assert_stash_ref $@
- apply_stash $@
- drop_stash $@
+ if apply_stash $@
+ then
+ drop_stash $@
+ else
+ status=$?
+ say The stash is kept in case you need it again.
+ exit $status
+ fi
}
drop_stash () {
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 1/3] wt-status: Make conflict hint message more consistent with other hints
On Wed, Feb 26, 2014 at 3:37 PM, Junio C Hamano gits...@pobox.com wrote: I see that you are trying to match the phrasing used in the other side of this if/else (which is outside the context of the posted patch). Over there we say ... to conclude merge while the new text says ... to conclude THE merge. Don't we want to match them? Ah, good catch. My mind just read it as conclude THE merge, even though the word wasn't there. Let's add the the in. :) For those who did not look beyond the context of the patch text, as I had to look these up to convince myself that the proposed change is a good one. This function is only called when we see MERGE_HEAD, so unmerged here can come only from a failed merge, not other mergy operations like am, cherry-pick, revert, etc. and telling the user that 'commit' will conclude the merge will not be misleading (unless you count 'git commit' will conclude a conflicted 'git pull' as misleading, and I of course do not). I'll update the commit message to explain that I'm match the other side of the if/else. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 2/3] merge: Add hints to tell users about git merge --abort
On Wed, Feb 26, 2014 at 3:38 PM, Jonathan Nieder jrnie...@gmail.com wrote: Seems reasonable, but I worry about the command growing too noisy. Could this be guarded by an advice.something setting? (See advice.* in git-config(1) for what I mean.) Ah, good idea. This seems to belong to advice.resolveConflict. I'll add it there. `status_printf_ln` already prints a newline, so the translated message shouldn't include an extra one. Good catch. Thanks! Andrew -- 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 21/25] checkout: support checking out into a new working directory
On Thu, Feb 27, 2014 at 3:06 AM, Eric Sunshine sunsh...@sunshineco.com wrote:
+ len = strlen(path);
+ if (!len || is_dir_sep(path[len - 1]))
+ die(_('--to' argument '%s' cannot end with a slash), path);
What is the purpose of this restriction?
Laziness on my part :) Because the following loop searches backward to
get the `basename $path`, trailing slash would make it return empty
base name. I could have just removed the trailing slash here instead
of dying though. Thanks for catching.
+ for (name = path + len - 1; name path; name--)
+ if (is_dir_sep(*name)) {
+ name++;
+ break;
+ }
--
Duy
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] reset: Change the default behavior to use --merge during a merge
On Wed, Feb 26, 2014 at 3:48 PM, Jonathan Nieder jrnie...@gmail.com wrote: I really don't like the idea of making git reset modal, though. I'd rather that reset --mixed print some advice about how to recover from the mistake, which would also have the advantage of allowing scripts that for whatever reason used git reset in this situation to continue to work. In the case where user had unstaged changes before running git merge, there's no way to recover from the mistake. Their worktree is left with a mix of both the merge changes and their original unstaged changes. As Junio pointed out, new files will also be left in the worktree, so the next attempt to git merge will fail until the files are removed. There's no way to recover from it except to have the user manually clean out the merge changes and new files manually. That's why git reset --mixed doesn't seem sensible during a merge. That said, I do feel it might not be a good idea to have the default behavior of git reset change depending on the context. What Junio suggested might be a better approach. To have git reset error out instead may be a better alternative, since that doesn't silently do something else and break compatibility. Andrew -- 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 10/25] Add new environment variable $GIT_COMMON_DIR
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Note that logs/refs/.tmp-renamed-log is used to prepare new reflog
entry and it's supposed to be on the same filesystem as the target
reflog file. This is not guaranteed true for logs/HEAD when it's
mapped to repos/xx/logs/HEAD because the user can put repos
directory on different filesystem. Don't mess with .git unless you
know what you're doing.
Hmph. I am puzzled.
We use TMP_RENAMED_LOG in rename_ref() in this sequence:
* First move refs/logs/$oldname to TMP_RENAMED_LOG;
* Delete refs/$oldname;
* Delete refs/$newname if exists;
* Move TMP_RENAMED_LOG to refs/logs/$newname;
* Create refs/$newname.
in rename_ref(), and TMP_RENAMED_LOG or the helper function
rename_tmp_log() that does the actual rename do not seem to be
called by any other codepath.
How would logs/HEAD get in the picture? Specifically, I am not sure
if we ever allow renaming the HEAD (which typically is a symref but
could be detached) via rename_ref() at all.
The redirection is done by git_path(), git_pathdup() and
strbuf_git_path(). The selected list of paths goes to $GIT_COMMON_DIR,
not the other way around in case a developer adds a new
worktree-specific file and it's accidentally promoted to be shared
across repositories (this includes unknown files added by third party
commands)
The list of known files that belong to $GIT_DIR are:
ADD_EDIT.patch BISECT_ANCESTORS_OK BISECT_EXPECTED_REV BISECT_LOG
BISECT_NAMES CHERRY_PICK_HEAD COMMIT_MSG FETCH_HEAD HEAD MERGE_HEAD
MERGE_MODE MERGE_RR NOTES_EDITMSG NOTES_MERGE_WORKTREE ORIG_HEAD
REVERT_HEAD SQUASH_MSG TAG_EDITMSG fast_import_crash_* logs/HEAD
next-index-* rebase-apply rebase-merge rsync-refs-* sequencer/*
shallow_*
Path mapping is NOT done for git_path_submodule(). Multi-checkouts are
not supported as submodules.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Other than the I do not understand why logs/HEAD is an issue, the
other aspect of the above design feels sound to me.
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 02bbc08..2c4a055 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -773,6 +773,14 @@ Git so take care if using Cogito etc.
an explicit repository directory set via 'GIT_DIR' or on the
command line.
+'GIT_COMMON_DIR'::
+ If this variable is set to a path, non-worktree files that are
+ normally in $GIT_DIR will be taken from this path
+ instead. Worktree-specific files such as HEAD or index are
+ taken from $GIT_DIR. This variable has lower precedence than
+ other path variables such as GIT_INDEX_FILE,
+ GIT_OBJECT_DIRECTORY...
+
We may want to add something (not necessarily with this commit) to
repository-layout and glossary to describe this new officially
supported way to implement what contrib/workdir wanted to do.
diff --git a/path.c b/path.c
index 0f8c3dc..2d757dc 100644
--- a/path.c
+++ b/path.c
@@ -90,6 +90,32 @@ static void replace_dir(struct strbuf *buf, int len, const
char *newdir)
buf-buf[newlen] = '/';
}
+static void update_common_dir(struct strbuf *buf, int git_dir_len)
+{
+ const char *common_dir_list[] = {
+ branches, hooks, info, logs, lost-found, modules,
+ objects, refs, remotes, rr-cache, svn,
+ NULL
+ };
+ const char *common_top_file_list[] = {
+ config, gc.pid, packed-refs, shallow, NULL
+ };
+ char *base = buf-buf + git_dir_len;
+ const char **p;
+ if (is_dir_file(base, logs, HEAD))
Just a style, but could you have a blank line between the series of
decls and the first statement? It would be easier to read that way.
+ return; /* keep this in $GIT_DIR */
+ for (p = common_dir_list; *p; p++)
+ if (dir_prefix(base, *p)) {
+ replace_dir(buf, git_dir_len, get_git_common_dir());
+ return;
+ }
+ for (p = common_top_file_list; *p; p++)
+ if (!strcmp(base, *p)) {
+ replace_dir(buf, git_dir_len, get_git_common_dir());
+ return;
+ }
+}
+
static void adjust_git_path(struct strbuf *buf, int git_dir_len)
{
const char *base = buf-buf + git_dir_len;
@@ -101,6 +127,8 @@ static void adjust_git_path(struct strbuf *buf, int
git_dir_len)
get_index_file(), strlen(get_index_file()));
else if (git_db_env dir_prefix(base, objects))
replace_dir(buf, git_dir_len + 7, get_object_directory());
+ else if (git_common_dir_env)
+ update_common_dir(buf, git_dir_len);
}
static void do_git_path(struct strbuf *buf, const char *fmt, va_list args)
diff --git a/t/t0060-path-utils.sh b/t/t0060-path-utils.sh
index 1d29901..f9a77e4 100755
--- a/t/t0060-path-utils.sh
+++ b/t/t0060-path-utils.sh
@@ -241,5 +241,20 @@ test_expect_success
Re: [PATCH v3 11/25] git-sh-setup.sh: use rev-parse --git-path to get $GIT_DIR/objects
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
If $GIT_COMMON_DIR is set, $GIT_OBJECT_DIRECTORY should be
$GIT_COMMON_DIR/objects, not $GIT_DIR/objects. Just let rev-parse
--git-path handle it.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
git-sh-setup.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index fffa3c7..fec9430 100644
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -343,7 +343,7 @@ then
echo 2 Unable to determine absolute path of git directory
exit 1
}
- : ${GIT_OBJECT_DIRECTORY=$GIT_DIR/objects}
+ : ${GIT_OBJECT_DIRECTORY=`git rev-parse --git-path objects`}
$(...) is the preferred way over `...` in this codebase.
fi
peel_committish () {
--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 3/3] reset: Change the default behavior to use --merge during a merge
On Wed, Feb 26, 2014 at 3:57 PM, Matthieu Moy matthieu@grenoble-inp.fr wrote: If you were to design git reset's interface from scratch, your proposal would make sense. But we're talking about a change, and you can't expect that users never use the current behavior. At the very least, there should be a warning telling the user that the behavior changed, and I'm really afraid that the warning goes along the lines of I've thought you'd prefer me to discard your unsaved changes, please rewrite them if you actually didn't want me to. I'm not really convinced that this is such a good change, and if we go this way, there should be a transition to let users stop using argumentless git reset to reset the index during a merge. Yeah, this breaks compatibility, but like I said, during a merge, I don't see a good reason to do git reset --mixed, The point with backward compatibility is not to know whether users have a good reason to, but whether you can guarantee that no one ever does it. Yeah, I do see what you mean. But the problem of using git reset --mixed during a merge is problematic too. It leaves you with a mix of merge changes and local changes. As Junio pointed out, new files will also be left in the worktree. So users would have to clean all that up manually. Perhaps what Junio suggested is a better approach. Slowly phase out this behavior by printing out warnings. Then eventually erroring out in this situation, and then finally switch to a new behavior, whatever that may be. Andrew -- 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 15/25] setup.c: detect $GIT_COMMON_DIR in is_git_directory()
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
If the file $GIT_DIR/commondir exists, it contains the value of
$GIT_COMMON_DIR.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
Documentation/gitrepository-layout.txt | 4
setup.c| 38
--
strbuf.c | 8 +++
strbuf.h | 1 +
4 files changed, 45 insertions(+), 6 deletions(-)
diff --git a/Documentation/gitrepository-layout.txt
b/Documentation/gitrepository-layout.txt
index aa03882..9bfe0f1 100644
--- a/Documentation/gitrepository-layout.txt
+++ b/Documentation/gitrepository-layout.txt
@@ -211,6 +211,10 @@ shallow::
and maintained by shallow clone mechanism. See `--depth`
option to linkgit:git-clone[1] and linkgit:git-fetch[1].
+commondir::
+ If this file exists, $GIT_COMMON_DIR will be set to the path
+ specified in this file if it is not set.
+
modules::
Contains the git-repositories of the submodules.
In a way similar to the *Note* in a very early part of this file
describes the .git-file redirected repositories, we would need to
mention that there now exist repositories borrowing from another
repository via this commondir mechanism, and what the caveats are
when using them (like, do not ever nuke the original repository
somebody else is borrowing from with 'rm -rf' when you think you are
done with the original).
+ if (file_exists(path.buf)) {
+ if (strbuf_read_file(data, path.buf, 0) = 0)
+ die_errno(_(failed to read %s), path.buf);
Do we care about the case where we cannot tell if the file exists
(e.g. stat() fails due to EPERM or something), or would it be not
worth worrying about?
+ strbuf_chomp(data);
+ strbuf_reset(path);
+ if (!is_absolute_path(data.buf))
+ strbuf_addf(path, %s/, gitdir);
+ strbuf_addbuf(path, data);
OK, so commondir can be relative to the containing gitdir
(e.g. /a/foo/.git/commondir with ../../bar/.git would name
/a/bar/.git as the common dir).
It needs to be documented in the repository-layout somehow.
@@ -188,14 +212,20 @@ int is_git_directory(const char *suspect)
int ret = 0;
size_t len;
- strbuf_addstr(path, suspect);
+ strbuf_addf(path, %s/HEAD, suspect);
+ if (validate_headref(path.buf))
+ goto done;
Is there a reason why we want to check HEAD before other stuff?
Just being curious, as I do not think of any (I am not saying that
we shouldn't change the order).
+void strbuf_chomp(struct strbuf *sb)
+{
+ while (sb-len (sb-buf[sb-len - 1] == '\n' ||
+sb-buf[sb-len - 1] == '\r'))
+ sb-len--;
+ sb-buf[sb-len] = '\0';
+}
It feels a bit yucky to ignore trailing \r on non-DOS filesystems
(if it were also removing any whitespace, then I would sort of
understand in the context of the expected caller of this function in
this series---except that it would no longer be a chomp), but I'd
let it pass.
--
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 16/25] setup.c: convert check_repository_format_gently to use strbuf
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- Nice. -- 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 stash pop` UX Problem
Junio C Hamano gits...@pobox.com writes: David Kastrup d...@gnu.org writes: All that verbosity... $ git stash pop Auto-merging foo.txt CONFLICT (content): Merge conflict in foo.txt Cowardly refusing to drop stash $ Actually, modulo Cowardly, that may be the most harmless phrasing, as apply_stash may try to signal an error for reasons not related to an inability to apply the change cleanly (e.g. we may have failed to refresh the index). Without Cowardly, the capriciosity of refusing does not make much sense. The error message is a tribute to GNU tar: dak@lola:/tmp$ mkdir x dak@lola:/tmp$ tar cfz x tar: Cowardly refusing to create an empty archive Try `tar --help' or `tar --usage' for more information. dak@lola:/tmp$ The boring variant would be $ git stash pop Auto-merging foo.txt CONFLICT (content): Merge conflict in foo.txt Not dropping stash $ -- David Kastrup -- 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 17/25] setup.c: detect $GIT_COMMON_DIR check_repository_format_gently()
Nguyễn Thái Ngọc Duy pclo...@gmail.com writes:
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
It is a good thing to do to read config from the real repository we
are borrowing from when we have .git/commondir, but it makes me
wonder if we should signal some kind of error if we find .git/config
in such a borrowing repository---which will be silently ignored.
My gut feeling is that such a check may be necessary, but may not
belong to this function.
setup.c | 6 --
1 file changed, 4 insertions(+), 2 deletions(-)
diff --git a/setup.c b/setup.c
index 282fdc9..e56ec11 100644
--- a/setup.c
+++ b/setup.c
@@ -285,6 +285,10 @@ static int check_repository_format_gently(const char
*gitdir, int *nongit_ok)
const char *repo_config;
int ret = 0;
+ get_common_dir(sb, gitdir);
+ strbuf_addstr(sb, /config);
+ repo_config = sb.buf;
+
/*
* git_config() can't be used here because it calls git_pathdup()
* to get $GIT_CONFIG/config. That call will make setup_git_env()
@@ -294,8 +298,6 @@ static int check_repository_format_gently(const char
*gitdir, int *nongit_ok)
* Use a gentler version of git_config() to check if this repo
* is a good one.
*/
- strbuf_addf(sb, %s/config, gitdir);
- repo_config = sb.buf;
git_config_early(check_repository_format_version, NULL, repo_config);
if (GIT_REPO_VERSION repository_format_version) {
if (!nongit_ok)
--
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 v2 8/8] log --remerge-diff: show what the conflict resolution changed
Thomas Rast t...@thomasrast.ch writes:
diff --git a/log-tree.c b/log-tree.c
index 30b3063..9b831e9 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -11,6 +11,8 @@
#include gpg-interface.h
#include sequencer.h
#include line-log.h
+#include cache-tree.h
+#include merge-recursive.h
struct decoration name_decoration = { object names };
@@ -723,6 +725,300 @@ static int do_diff_combined(struct rev_info *opt,
struct commit *commit)
}
/*
+ * Helpers for make_asymmetric_conflict_entries() below.
+ */
+static char *load_cache_entry_blob(struct cache_entry *entry,
+unsigned long *size)
+{
I briefly wondered if this helper need to know about contents
conversions (e.g. smudge/clean or crlf), but not doing any of that
*is* the right thing to do. IOW, I agree with what this part of the
patch does.
But it feels, at least to me, that this helper function ...
+static void strbuf_append_cache_entry_blob(struct strbuf *sb,
+struct cache_entry *entry)
+{
... and this one are overly specific. Why should they know about
(and limit themselves to operate on) cache-entry type? Isn't it too
much to ask for the caller to say entry-sha1 instead of entry?
I do not have an issue with a load_blob() helper that makes sure
what it reads is a blob, though, of course.
+static void assemble_conflict_entry(struct strbuf *sb,
+ const char *branch1,
+ const char *branch2,
+ struct cache_entry *entry1,
+ struct cache_entry *entry2)
+{
+ strbuf_addf(sb, %s\n, branch1);
+ strbuf_append_cache_entry_blob(sb, entry1);
+ strbuf_addstr(sb, ===\n);
+ strbuf_append_cache_entry_blob(sb, entry2);
+ strbuf_addf(sb, %s\n, branch2);
+}
+
+/*
+ * For --remerge-diff, we need conflicted ( ... )
+ * representations of as many conflicts as possible. Default conflict
+ * generation only applies to files that have all three stages.
+ *
+ * This function generates conflict hunk representations for files
+ * that have only one of stage 2 or 3. The corresponding side in the
+ * conflict hunk format will be empty. A stage 1, if any, will be
+ * dropped in the process.
+ */
+static void make_asymmetric_conflict_entries(const char *branch1,
+ const char *branch2)
+{
I should comment on this one in a separate message after I read it
over once again.
+}
+
+/*
+ * --remerge-diff doesn't currently handle entries that cannot be
+ * turned into a stage0 conflicted-file format blob. So this routine
+ * clears the corresponding entries from the index. This is
+ * suboptimal; we should eventually handle them _somehow_.
+*/
+static void drop_non_stage0()
static void drop_non_stage0(void)
--
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 17/25] setup.c: detect $GIT_COMMON_DIR check_repository_format_gently()
On Thu, Feb 27, 2014 at 7:22 AM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com --- It is a good thing to do to read config from the real repository we are borrowing from when we have .git/commondir, but it makes me wonder if we should signal some kind of error if we find .git/config in such a borrowing repository---which will be silently ignored. My gut feeling is that such a check may be necessary, but may not belong to this function. Just checking. Once we do this, what about .git/refs/.. that is also ignored in such a repo? I can see the point that config could be manually edited so the user may edit the file at the wrong place, so it's good the we catch this exception. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH v3 10/25] Add new environment variable $GIT_COMMON_DIR
On Thu, Feb 27, 2014 at 6:58 AM, Junio C Hamano gits...@pobox.com wrote: Nguyễn Thái Ngọc Duy pclo...@gmail.com writes: Note that logs/refs/.tmp-renamed-log is used to prepare new reflog entry and it's supposed to be on the same filesystem as the target reflog file. This is not guaranteed true for logs/HEAD when it's mapped to repos/xx/logs/HEAD because the user can put repos directory on different filesystem. Don't mess with .git unless you know what you're doing. Hmph. I am puzzled. We use TMP_RENAMED_LOG in rename_ref() in this sequence: * First move refs/logs/$oldname to TMP_RENAMED_LOG; * Delete refs/$oldname; * Delete refs/$newname if exists; * Move TMP_RENAMED_LOG to refs/logs/$newname; * Create refs/$newname. in rename_ref(), and TMP_RENAMED_LOG or the helper function rename_tmp_log() that does the actual rename do not seem to be called by any other codepath. How would logs/HEAD get in the picture? Specifically, I am not sure if we ever allow renaming the HEAD (which typically is a symref but could be detached) via rename_ref() at all. HEAD is an exception, I agree. If you rename HEAD to something else, the repo will not be recognized anymore because HEAD is part of the repo signature. There are other refs outside refs/ though that can be renamed in theory. In practice all rename_ref() callers only operate on refs/ domain so this is a false alarm. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] archive: add archive.restrictRemote option
From: Scott J. Goldman scot...@github.com
In commit ee27ca4, we started restricting remote git-archive
invocations to only accessing reachable commits. This
matches what upload-pack allows, but does restrict some
useful cases (e.g., HEAD:foo). We loosened this in 0f544ee,
which allows `foo:bar` as long as `foo` is a ref tip.
However, that still doesn't allow many useful things, like:
1. Commits accessible from a ref, like `foo^:bar`, which
is reachable
2. Arbitrary sha1s, even if they are reachable.
We can do a full object-reachability check for these cases,
but it can be quite expensive if the client has sent us the
sha1 of a tree; we have to visit every sub-tree of every
commit in the worst case.
Let's instead give site admins an escape hatch, in case they
prefer the more liberal behavior. For many sites, the full
object database is public anyway (e.g., if you allow dumb
walker access), or the site admin may simply decide the
security/convenience tradeoff is not worth it.
This patch adds a new config option to turn off the
restrictions added in ee27ca4. It defaults to on, meaning
there is no change in behavior by default.
Signed-off-by: Jeff King p...@peff.net
---
Documentation/git-archive.txt | 7 +++
archive.c | 13 +++--
t/t5000-tar-tree.sh | 9 +
3 files changed, 27 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt
index b97aaab..486cb08 100644
--- a/Documentation/git-archive.txt
+++ b/Documentation/git-archive.txt
@@ -121,6 +121,13 @@ tar.format.remote::
user-defined formats, but true for the tar.gz and tgz
formats.
+archive.restrictRemote::
+ If true, archives can only be requested by refnames. If false,
+ allows remote archive requests from arbitrary revisions. This
+ can be a security hazard, as archives could be requested for
+ unreachable commits that have been pruned from the repository.
+ Defaults to true.
+
[[ATTRIBUTES]]
ATTRIBUTES
--
diff --git a/archive.c b/archive.c
index 346f3b2..13eb23a 100644
--- a/archive.c
+++ b/archive.c
@@ -17,6 +17,7 @@ static char const * const archive_usage[] = {
static const struct archiver **archivers;
static int nr_archivers;
static int alloc_archivers;
+static int git_archive_restrict_remote = 1;
void register_archiver(struct archiver *ar)
{
@@ -257,7 +258,7 @@ static void parse_treeish_arg(const char **argv,
unsigned char sha1[20];
/* Remotes are only allowed to fetch actual refs */
- if (remote) {
+ if (remote git_archive_restrict_remote) {
char *ref = NULL;
const char *colon = strchr(name, ':');
int refnamelen = colon ? colon - name : strlen(name);
@@ -401,6 +402,14 @@ static int parse_archive_args(int argc, const char **argv,
return argc;
}
+static int git_default_archive_config(const char *var, const char *value,
+ void *cb)
+{
+ if (!strcmp(var, archive.restrictremote))
+ git_archive_restrict_remote = git_config_bool(var, value);
+ return git_default_config(var, value, cb);
+}
+
int write_archive(int argc, const char **argv, const char *prefix,
int setup_prefix, const char *name_hint, int remote)
{
@@ -411,7 +420,7 @@ int write_archive(int argc, const char **argv, const char
*prefix,
if (setup_prefix prefix == NULL)
prefix = setup_git_directory_gently(nongit);
- git_config(git_default_config, NULL);
+ git_config(git_default_archive_config, NULL);
init_tar_archiver();
init_zip_archiver();
diff --git a/t/t5000-tar-tree.sh b/t/t5000-tar-tree.sh
index 05f011d..eba285f 100755
--- a/t/t5000-tar-tree.sh
+++ b/t/t5000-tar-tree.sh
@@ -213,6 +213,15 @@ test_expect_success 'clients cannot access unreachable
commits' '
test_must_fail git archive --remote=. $sha1 remote.tar
'
+test_expect_success 'clients can access unreachable commits' '
+ test_commit unreachable1
+ sha1=`git rev-parse HEAD`
+ git reset --hard HEAD^
+ git archive $sha1 remote.tar
+ test_config archive.restrictRemote false
+ git archive --remote=. $sha1 remote.tar
+'
+
test_expect_success 'setup tar filters' '
git config tar.tar.foo.command tr ab ba
git config tar.bar.command tr ab ba
--
1.8.5.2.500.g8060133
--
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: Cygwin + git log = no pager!
On Wed, Feb 26, 2014 at 09:54:39AM -0600, Robert Dailey wrote:
That _should_ turn on the pager, but I think it does not due to a bug
with setup_pager and aliases. Something like the patch below would make
it work (but if you are having to use -p manually, there is something
to fix in your cygwin environment, which does not think you are on a
terminal).
I have tried `git -p log` and `git log` and neither use the pager.
I thought Git's behavior was a bug, but it seems to be the intended
effect that -p is just cancel --no-pager and not turn on the pager,
even if stdout is not a tty.
So the patch I sent is not something we would want to apply, but it
might help debugging your situation (if my hunch is right that isatty()
is returning false, then git -p log would work with it). Or perhaps a
simpler way to check that is just:
diff --git a/pager.c b/pager.c
index 0cc75a8..6d870ac 100644
--- a/pager.c
+++ b/pager.c
@@ -41,8 +41,10 @@ const char *git_pager(int stdout_is_tty)
{
const char *pager;
- if (!stdout_is_tty)
+ if (!stdout_is_tty) {
+ warning(disabling pager, stdout is not a tty);
return NULL;
+ }
pager = getenv(GIT_PAGER);
if (!pager) {
Should I apply the provided patch to the Git for Windows master
branch? Also I'm not sure if there is a convenient way to apply a
patch via email, so should I copy paste it to a file then apply
the file?
The usual way is to save the patch to an mbox, then use git am to
apply it. Most Unix-y mail clients have mbox support, but I suspect many
Windows ones do not.
-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 v3 21/25] checkout: support checking out into a new working directory
On Wed, Feb 26, 2014 at 6:19 PM, Duy Nguyen pclo...@gmail.com wrote:
On Thu, Feb 27, 2014 at 3:06 AM, Eric Sunshine sunsh...@sunshineco.com
wrote:
+ len = strlen(path);
+ if (!len || is_dir_sep(path[len - 1]))
+ die(_('--to' argument '%s' cannot end with a slash),
path);
What is the purpose of this restriction?
Laziness on my part :) Because the following loop searches backward to
get the `basename $path`, trailing slash would make it return empty
base name. I could have just removed the trailing slash here instead
of dying though. Thanks for catching.
Thanks for the explanation. I thought that that might be the case.
+ for (name = path + len - 1; name path; name--)
+ if (is_dir_sep(*name)) {
+ name++;
+ break;
+ }
--
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] upload-pack: allow shallow fetching from a read-only repository
Before cdab485 (upload-pack: delegate rev walking in shallow fetch to
pack-objects - 2013-08-16) upload-pack does not write to the source
repository. cdab485 starts to write $GIT_DIR/shallow_XX if it's a
shallow fetch, so the source repo must be writable.
Fall back to $TMPDIR if $GIT_DIR/shallow_XX cannot be created in
this case. Note that in other cases that write $GIT_DIR/shallow_XX
and eventually rename it to $GIT_DIR/shallow, there is no fallback to
$TMPDIR.
Signed-off-by: Nguyễn Thái Ngọc Duy pclo...@gmail.com
---
builtin/receive-pack.c | 2 +-
commit.h | 2 +-
fetch-pack.c | 2 +-
shallow.c| 13 +++--
t/t5537-fetch-shallow.sh | 13 +
upload-pack.c| 2 +-
6 files changed, 28 insertions(+), 6 deletions(-)
diff --git a/builtin/receive-pack.c b/builtin/receive-pack.c
index 85bba35..9d96f2c 100644
--- a/builtin/receive-pack.c
+++ b/builtin/receive-pack.c
@@ -936,7 +936,7 @@ static const char *unpack(int err_fd, struct shallow_info
*si)
ntohl(hdr.hdr_version), ntohl(hdr.hdr_entries));
if (si-nr_ours || si-nr_theirs) {
- alt_shallow_file = setup_temporary_shallow(si-shallow);
+ alt_shallow_file = setup_temporary_shallow(si-shallow, 0);
argv_array_pushl(av, --shallow-file, alt_shallow_file, NULL);
}
diff --git a/commit.h b/commit.h
index 16d9c43..44a40ad 100644
--- a/commit.h
+++ b/commit.h
@@ -209,7 +209,7 @@ extern int write_shallow_commits(struct strbuf *out, int
use_pack_protocol,
extern void setup_alternate_shallow(struct lock_file *shallow_lock,
const char **alternate_shallow_file,
const struct sha1_array *extra);
-extern char *setup_temporary_shallow(const struct sha1_array *extra);
+extern char *setup_temporary_shallow(const struct sha1_array *extra, int
read_only);
extern void advertise_shallow_grafts(int);
struct shallow_info {
diff --git a/fetch-pack.c b/fetch-pack.c
index 90fdd49..382b825 100644
--- a/fetch-pack.c
+++ b/fetch-pack.c
@@ -853,7 +853,7 @@ static struct ref *do_fetch_pack(struct fetch_pack_args
*args,
setup_alternate_shallow(shallow_lock, alternate_shallow_file,
NULL);
else if (si-nr_ours || si-nr_theirs)
- alternate_shallow_file = setup_temporary_shallow(si-shallow);
+ alternate_shallow_file = setup_temporary_shallow(si-shallow,
0);
else
alternate_shallow_file = NULL;
if (get_pack(args, fd, pack_lockfile))
diff --git a/shallow.c b/shallow.c
index bbc98b5..3adfbd5 100644
--- a/shallow.c
+++ b/shallow.c
@@ -216,7 +216,7 @@ int write_shallow_commits(struct strbuf *out, int
use_pack_protocol,
return write_shallow_commits_1(out, use_pack_protocol, extra, 0);
}
-char *setup_temporary_shallow(const struct sha1_array *extra)
+char *setup_temporary_shallow(const struct sha1_array *extra, int read_only)
{
struct strbuf sb = STRBUF_INIT;
int fd;
@@ -224,7 +224,16 @@ char *setup_temporary_shallow(const struct sha1_array
*extra)
if (write_shallow_commits(sb, 0, extra)) {
struct strbuf path = STRBUF_INIT;
strbuf_addstr(path, git_path(shallow_XX));
- fd = xmkstemp(path.buf);
+ if (read_only) {
+ fd = mkstemp(path.buf);
+ if (fd 0) {
+ char buf[PATH_MAX];
+ fd = git_mkstemp(buf, sizeof(buf),
shallow_XX);
+ }
+ if (fd 0)
+ die_errno(Unable to create temporary shallow
file);
+ } else
+ fd = xmkstemp(path.buf);
if (write_in_full(fd, sb.buf, sb.len) != sb.len)
die_errno(failed to write to %s,
path.buf);
diff --git a/t/t5537-fetch-shallow.sh b/t/t5537-fetch-shallow.sh
index b0fa738..171db88 100755
--- a/t/t5537-fetch-shallow.sh
+++ b/t/t5537-fetch-shallow.sh
@@ -173,6 +173,19 @@ EOF
)
'
+test_expect_success POSIXPERM 'shallow fetch from a read-only repo' '
+ cp -R .git read-only.git
+ find read-only.git -print | xargs chmod -w
+ test_when_finished find read-only.git -type d -print | xargs chmod +w
+ git clone --no-local --depth=2 read-only.git from-read-only
+ git --git-dir=from-read-only/.git log --format=%s actual
+ cat expect EOF
+add-1-back
+4
+EOF
+ test_cmp expect actual
+'
+
if test -n $NO_CURL -o -z $GIT_TEST_HTTPD; then
say 'skipping remaining tests, git built without http support'
test_done
diff --git a/upload-pack.c b/upload-pack.c
index 0c44f6b..11404b4 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -84,7 +84,7 @@ static void
Re: Cygwin + git log = no pager!
On 27/02/14 04:54, Robert Dailey wrote: On Wed, Feb 26, 2014 at 3:26 AM, Jeff King p...@peff.net wrote: On Mon, Feb 24, 2014 at 01:34:34PM -0600, Robert Dailey wrote: So I set GIT_PAGER to 'echo custom pager' as you instructed, and I noticed that wasn't being printed when I ran my git log alias. So what I did after that was set GIT_TRACE=1 and here is the output I see before my logs start printing: [...] Does using an alias have something to do with this? The aliases shouldn't matter (and I constructed a scenario like the one you showed and it starts the pager for me on Linux). It's more like git is deciding not to show a pager at all (e.g., it thinks your stdout is not a tty). Does running: git log not use a pager, but: git -p log does? In that case, I think that your stdout is not a tty for some reason. If that is the case, try: git -p lg That _should_ turn on the pager, but I think it does not due to a bug with setup_pager and aliases. Something like the patch below would make it work (but if you are having to use -p manually, there is something to fix in your cygwin environment, which does not think you are on a terminal). -Peff snip I have tried `git -p log` and `git log` and neither use the pager. Should I apply the provided patch to the Git for Windows master branch? That may be relevant (refer to my previous questions about what version you're using and how you got it). Are you using git via cygwin or Git For Windows? I believe the two are different (*caveat* I haven't used windows in years and I've never used Git For Windows, I've added the msysgit list to this email thread). If you're executing the Git For Windows installation from the cygwin bash shell that's probably why the terminal detection is getting confused. If you've installed Git For Windows you should use the Git BASH shell that comes with it. If you want to use git with other bits of cygwin I suggest uninstalling Git For Windows and installing the git package via the cygwin setup tool. Also I'm not sure if there is a convenient way to apply a patch via email, so should I copy paste it to a file then apply the file? Save the email file in your email client. Most support saving as plain text or RFC822 format. Then 'git am filename' should do the trick. I'm assuming your patch depended on -p working but not without it, so I'm not sure if you still think the patch might help. Let me know! Thanks for your help. -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Git in GSoC 2014
On 02/26/2014 08:48 PM, Junio C Hamano wrote:
Michael Haggerty mhag...@alum.mit.edu writes:
See my branch on GitHub [1] or read the appended text below.
Very nice.
## Introduction
It is strongly recommended that students who want to apply to the Git
project for the Summer of Code 2014 should submit a small code-related
patch to the Git project as part of their application. Think of these
microprojects as the Hello, world of getting involved with the Git
project; the coding aspect of the change can be almost trivial, but to
make the change the student has to become familiar with many of the
practical aspects of working on the Git project:
I'd suggest one step before all of the below.
* Here (http://thread.gmane.org/{TBD1,TBD2,TBD3...}) are a sample
set of threads that show how a change and a patch to implement it
is proposed by a developer X, the problem it attempts to solve,
the design of the proposed solution and the implementation of
that design are reviewed and discussed, and that after several
iterations it resulted in inclusion to our codebase. As a GSoC
student, you will be playing the role of X and engaging in a
similar discussion. Get familar with the flow, need for clarity
on both sides (i.e. you need to clearly defend your design, and
need to ask clarifications when questions/suggestions you are
offered are not clear enough), the pace at which the discussion
takes place, and the general tone of the discussion, to learn
what is expected of you.
That would help the later step, namely:
* Expect feedback, criticism, suggestions, etc. from the mailing list.
*Respond to it!* and follow up with improved versions of your
change. Even for a trivial patch you shouldn't be surprised if it
takes two or more iterations before your patch is accepted. *This
is the best part of the Git community; it is your chance to get
personalized instruction from very experienced peers!*
Sounds good. I suggest we make your blob a paragraph before the list of
bullet points rather than part of the list. Please suggest some TBD*
then I'll add it to the text. Would we also fill in X with the name
of the actual student involved in the conversation that is pointed to?
Michael
--
Michael Haggerty
mhag...@alum.mit.edu
http://softwareswirl.blogspot.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: GSoC idea: allow git rebase --interactive todo lines to take options
On 02/26/2014 11:52 AM, Jeff King wrote: On Wed, Feb 26, 2014 at 09:04:30AM +0100, Michael Haggerty wrote: It would be nice to support more flexibility in the todo-list commands by allowing the commands to take options. Maybe * Convert a commit into a merge commit: pick -p c0ffeee -p e1ee712 deadbab The oneline of the commit after This seems like a reasonable feature to me. All of your examples are possible with an edit and another git command, but the convenience may be worth it (though personally, most of the examples you gave are particularly interesting to me[1]). Don't forget that any of the parent commits might have been rewritten due to the earlier lines of the rebase script. Rebase has to map the specified SHA-1s to their new versions. So I don't think that this one would be very practical to implement by hand. Actually I think it is awkward to have to specify all of the parent commits. I did it this way to make it look like commit-tree's -p option. But any usage of this feature that *doesn't* include the immediately preceding commit as a parent would probably be broken anyway (for example, the preceding commit would become unreachable). So maybe a better UI would be pick --merge=e1ee712 deadbab The oneline of the commit after (even though this precludes the short form -m because it is already taken by --message). On the other hand, allowing arbitrary parents with -p might be a way to make rebase --interactive work half-sanely with parts of history that *already* include merge commits. The todo list that rebase prepares for the user would already include these -p lines. What I like about allowing options in todo lists is that is that it opens up a lot of possibilities for git rebase --interactive that, I think, have previously been hampered by the restriction that commands have to consist of a single word, and (until now) have to be abbreviable to a single distinct letter. Michael -- Michael Haggerty mhag...@alum.mit.edu http://softwareswirl.blogspot.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
