how often do you check in and with what tool(s)?
Hello, i use Git Bash and check in very frequently.
it appears there is a range from "extreme often" to "extreme very seldom".
Examples:
{me, extreme often, Windows} very granular, with a brief yet appropriate
comment [like narrating a story] per commit-i change a few
lines of code,
Alt+Tab to Git Bash, Git Add/Commit,
Alt+Tab back to some coding tool (example LINQPad).
[generally, i check in one source file before moving to the next source file]
{not me, very extreme seldom} in some project, not at all granular, in batches
such as 50 of 75 files that have been modified, all
are checked in with a single detailed comment as to the overall purpose of the
batched changes.
QUESTION: how often do you check in and with what tool(s)?
Thank you.
gerry (lowry)
wasaga beach. ontario, canada
gerry.lo...@abilitybusinesscomputerservices.com
if YOU use a Windows GUI for Git, i would appreciate knowing which one and why
PREAMBLE [START] - please feel free to skip this first section Forgive me for asking this question on a mailing list. stackoverflow would probably kill such a question before the bits were fully saved to a server drive. Let me explain why i am asking and why i am not being a troll. [a] i'm "old school", i.e., > 50% on my way to being age 72 [born 1947] [b] when i started programming in 1967, most of my work input was via punched cards [c] punching my own cards was cool [d] IBM System/360 mainframe assembler was cool and patching previously punched card encoded machine code output was a fun risky but at times necessary challenge. [e] using command windows and coding batch files for Gary Kildall's CP/M and the evil empire's PC/MS-DOS was how i accomplished many tasks for early non-GUI environments (i still continue this practice even in Windows 10 (a.k.a. please don't update my PC O/S behind my back again versions of MS Windows)). [f] my introduction to Git was via a command line based awesome video that has disappeared (i asked this community about that in a previous thread). BOTTOM LINE: virtually 100% of my Git use has been via Git Bash command line [probably downloaded from https://git-scm.com/] For me, and i suspect even for most people who live with GUI platforms, [a well kept secret fact] using the keyboard is faster than using the mouse [especially when one's fingers are already over one's keyboard-example, closing one or more "windows" via Alt+F4. Also for me, i am happy to change some code and/or write some new code, Alt+Tab to Git Bash frequently, ADD/COMMIT, then Alt+Tab back to whatever IDE i'm using [mostly LINQPad and vs2017]; i know that's quite a bit schizophrenic of me-command line Git but GUI IDE. PREAMBLE [END] QUESTION: if YOU use a Windows GUI for Git, i would appreciate knowing which one and why i have been asked to look at GUI versions of Git for Windows. https://git-scm.com/download/gui/windows currently lists 22 options. if i had more time left in my life and the option, because of my own nature, i'd likely download and evaluate all 22 - Mr.T would pity the fool that i often can be. CAUTION: i am not looking for anyone to disparage other Git Windows GUIs. Let me break down the question into 4 parts: [1a] Which do you prefer: Git GUI, Git command line? [1b] What is your reason for your [1a] preference? [2a] if applicable, which Git GUI do you prefer? [2b] What is your reason for your [2a] preference? if you are uncomfortable replying to git@vger.kernel.org please feel free to reply directly to my e-mail address. i look forward to hearing from members of this Git community. Thank you for reading and thank you for your valuable time. gerry (lowry)-wasaga beach-ontario-canada gerry.lo...@abilitybusinesscomputerservices.com
hunting for lost highly interactive browser based git tutorial
Help, please and thank you. i have spent > one hour searching via Google and by visiting git-scm, BitBucket, github, et cetera, for an excellent tutorial for beginners and refresher for one who has not touched git for quite a while. if you've done the same tutorial, you will recognize its features: -- browser based -- highly interactive (use commands that are not necessarily "the next step", i.e., spontaneous self-guided review and trying variations not necessarily in the tutorial's script) -- teaches Git command line not GUI The tutorial "may" have be called something like "Try Git"; however, I can not find it at try.github.io and other places where i have looked. it's out there somewhere. The good news is i have found many of my favourite Git resources-if only i could find my favourite Git beginner's interactive tutorial, i'd be one happy homo sapiens (probably i need a life). Thank you for taking time to read this request. B-) Gerry (Lowry) Wasaga Beach Ontario Canada
Re: [PATCH 1/2] introduce "banned function" list
On Thu, Jul 19, 2018 at 09:08:08PM -0400, Jeff King wrote: > Ditto for sprintf, where you should _always_ be using at least xsnprintf > (or some better tool, depending on the situation). And for strncpy, > strlcpy (or again, some better tool) is strictly an improvement. Nitpick: this may be true for git, but it's not strictly true in all cases. I actually have a (non-git) case where strncpy *is* the right tool. And this is one where I'm copying a NUL-terminated string into a fixed-length charater array (in the ext4 superblock) which is *not* NUL-terminated. In that case, strncpy works(); but strlcpy() does not do what I want. So I used strncpy() advisedly, and I ignore people running Coccinelle scripts and blindly sending patches to "fix" ext4. But perhaps that's also a solution for git? You don't have to necessarily put them on a banned list; you could instead have some handy, pre-set scripts that scan the entire code base looking for "bad" functions with cleanups automatically suggested. This could be run at patch review time, and/or periodically (especially before a release). - Ted
Re: de-alphabetizing the documentation
On Fri, Jul 06, 2018 at 04:21:47PM -0700, frede...@ofb.net wrote: > I don't think that it's really important to find a "best" ordering for > commands or glossary terms; it's more a matter of finding someone who > is willing to take responsibility for choosing a reasonable ordering. > Presumably the head maintainer of this project could delegate the task > to a qualified volunteer, not a newbie like myself but not necessarily > someone with expert knowledge either. It's too bad that a policy of > not listing things alphabetically wasn't adopted from the beginning of > this project, but I guess that's life. That wasn't that portion of the man page, for better or for worse. We can debate whethher using a non-alphabetical order would be better or worse for everyone; personally, I think the much better pointer is at the very beginning of the git man page, which points people at "man gittutorial" and "man giteveryday". It seems to me that for your stated goal, "git everyday" has a good list of commands that people should learn, complete with a proposed workflow. That's probably the biggest stumbling block of finding an ideal ordering. What's reasonable really depends on your workflow, and there are many different workflows depending on what a particular developer is trying to do. Consider carpentry; for some use cases, a screwdriver is an absolutely critical tool. For others, they might never use it, and instead almost exclusively join two pieces of woods using mortise and tenon joint. Others might use a butt joint, plus glue and nails. All of these different techniques can be used to make a wooden box, and they all involve a very different set of tools. Regards, - Ted
Re: GDPR compliance best practices?
On Tue, Jun 12, 2018 at 09:12:19PM +0200, Peter Backes wrote: > This incorrect claim is completely inverting the logic of Art. 17. > > The logic is clarly that if ANY of lit (a) to (f) is satisfied, the > data must be deleted. > > It is not necessary for ALL of them to be satisfied. > > In particular, if the data is no longer necessary for the purpose for > which it was collected, then THAT ALONE is grounds for erasure ((1) > lit. a). It does not matter at all whether processing was consent-based > or whether such consent was withdrawn. Sure, but given that you are the one trying to claim that people need to do all sorts of extra development work (I don't see any patches from you) and suffer performance degredation, the burden of proof is on _you_ to show that this is a problem that github, et. al., are likely run into. In particular, keep in mind that distribution of open source code can only be done under the terms of an open source license --- and a license is a contract. So in particular, your claim that the data is no longer necessary (point a) is at the very least going to be subject to dispute and is a legal question. I can think of any number of ways that this could considered necessary in order to assure open source license compliance, the public interest in terms of allowing forking, etc. The bottom line is I'm sure the lawyers at github and Microsoft have very carefully done their due diligence, and if they are concerned, I'm sure we'll see patches from them, since after all, they would not be interested in seeing the imperial European bureaucrats trying to assess 4% of Microsoft's world-wide revenues --- that's $3.6 billion dollars, by the way. I'm sure if they think it's a concern, their programmers will be right on it. - Ted
Re: GDPR compliance best practices?
On Sat, Jun 09, 2018 at 11:50:32PM +0100, Philip Oakley wrote: > I just want to remind folks that Gmane disappeared as a regular list because > of a legal challenge, the SCO v IBM Unix court case keeps rumbling on, so > clarifying the legal case for: > a) holding the 'personal git meta data', and > b) disclosing (publishing) 'personal git meta data' > under various copyright and other legal issue scenarios relative to GDPR is > worth clarifying. And I suspect the best way of clarifying things is for laywers at the major corporations (e.g., Red Hat, Microsoft now that it owns github, Google since it publishes Android sources at sources.android.com, Canonical, etc.) to figure it out. Those situations may very well differ depend on whether they have a CLA or Copyright Assignment Agreement which they require of contributors. But fortunately, those organizations are also best set up to send patches. :-) If those organizations are not choosing to send patches, I suspect that might be a strong hint as to what those lawyers have concluded. - Ted
Re: GDPR compliance best practices?
On Fri, Jun 08, 2018 at 08:26:57AM +0200, Peter Backes wrote: > > If you run a website where the world can access a repository, you are > responsible for obeying the GDPR with respect to that repository. If > you receive a request to be forgotten, you have to make sure you stop > publishing that author's identity as part of the repository. > *Anyone* can run a repository. It's not just github and gitlab. The hobbiest in New Zealand, who might never visit Europe (so she can't be arrested when she visits the fair shores of Europe) and who has no business interests in Europe, can host such a web site. So the person trying to engage in censorship would need to contact *everyone*. And someone who has a git note in their private repo who then pushes to github/gitlab would end up pushing that note back up to the web server. > You do NOT need to > > - delete it from a private copy you have > - care about others who publish that data > - or even make sure the data is deleted from private copies others may > have, even if the number of copies is in the thousands. Great, so you can get github and gitlab to get rid of the information. But it's *pointless*. And given that real developers really do care about who authored a patch, and regularly will do operations that reference the authorship information, the fact that it is stored somewhere else (e.g., in a git note, per your proposal), *will* slow down those operations. > In practical terms, if someone wishes to exercise his right to be > forgotten, he will usually send the request to the maintainer and stop > him from distributing the information, and perhaps to a third party he > might use as a platform for publication, such as github. Your problem is in the word: "a" - Ted
Re: GDPR compliance best practices?
On Fri, Jun 08, 2018 at 01:21:29AM +0200, Peter Backes wrote: > On Thu, Jun 07, 2018 at 03:38:49PM -0700, David Lang wrote: > > > Again: The GDPR certainly allows you to keep a proof of copyright > > > privately if you have it. However, it does not allow you to keep > > > publishing it if someone exercises his right to be forgotten. > > someone is granting the world the right to use the code and you are claiming > > that the evidence that they have granted this right is illegal to have? > > Hell no! Please read what I wrote: > > - "allows you to keep a proof ... privately" > - "However, it does not allow you to keep publishing it" The problem is you've left undefined who is "you"? With an open source project, anyone who has contributed to open source project has a copyright interest. That hobbyist in German who submitted a patch? They have a copyright interest. That US Company based in Redmond, Washington? They own a copyright interest. Huawei in China? They have a copyright interest. So there is no "privately". And "you" numbers in the thousands and thousands of copyright holders of portions of the open source code. And of course, that's the other thing you seem to fundamentally not understand about how git works. Every developer in the world working on that open source project has their own copy. There is fundamentally no way that you can expunge that information from every single git repository in the world. You can remote a git note from a single repository. But that doesn't affect my copy of the repository on my laptop. And if I push that repository to my server, it git note will be out there for the whole world to see. So someone could *try* sending a public request to the entire world, saying, "I am a European and I demand that you disassociate commit DEADBEF12345 from my name". They could try serving legal papers on everyone. But at this point, it's going to trigger something called the "Streisand Effect". If you haven't heard of it, I suggest you look it up: http://mentalfloss.com/article/67299/how-barbra-streisand-inspired-streisand-effect Regards, - Ted
Re: GDPR compliance best practices?
On Mon, Jun 04, 2018 at 12:16:16AM +0200, Peter Backes wrote: > > Verifying the commit ID by itself wouldn't be any less efficient than > before. Admitteldly, it wouldn't verify the author and authordate > integrity anymore without additional work. That would be some overhead, > sure, and could be done on demand, and would mostly affect clones. For people who are doing real work on git repos, other commands that we very much care about include "git log --author=", "git tag --contains", "git blame", etc. At least for any repo that *I* control, slow those down, and I wouldn't downgrade my git binary/repo just to make some imperialistic European bureaucrats happy. Cheers, - Ted
Re: GDPR compliance best practices?
On Sun, Jun 03, 2018 at 10:52:33PM +02h00, hPeter Backes wrote: > But I will take your message as saying you at least don't see any > obvious criticism leading to complete rejection of the approach. If you don't think a potential 2x -- 10x performance hit isn't a blocking factor --- sure, go ahead and try implementing it. And good luck to you. And this is not a guarantee that it won't get rejected. I certainly don't have the power to make that guarantee. If you don't have time to implement, why do you think it's fair to inflict on everyone else the request for time to do a design review for something for which the need hasn't even been established? Regards, - Ted
Re: GDPR compliance best practices?
On Sun, Jun 03, 2018 at 09:24:17PM +0200, Peter Backes wrote: > > He said: It would be a tyranny of lawyers. > > Let's not have a tyranny of lawyers. Let us, the engineers and hackers, > exercise the necessary control over those pesky lawyers by defining and > redefining the state of the art in technology, and prevent them from > defining it by themselves. For a hammer, everything looks like a nail. > What is the better options: To suggest people to pay for legal advice > by lawyers, who only offer lengthy disclaimers and such for bypassing > the right to be forgotten, or simply discuss technical changes for git > which enable its easy implementation, without legal excuses for not > doing supporting it? Why don't you try to implement your proposal then, and then benchmark it. After you find out how much of a performance disaster it's going to be, especially for large git repos, we can discuss who is being tyrannical. It may very well be that different people and companies will get different legal advice, and one of the interesting things about many git repos for open source project is that it is not owned by any one company. A change in the git repo format is one that has to be adopted by the entire open source project, and if a portion of the community isn't interesting in paying the overhead cost, and sticks with the existing git repo format, I wonder what the "imperialistic" (your word, not mine) EU will do --- try to lock up or sue everyone from outside the EU that refuses to pay the 2x-10x performance overhead and sticks with the original repo format, such that anyone who wants to interoperate has to send git pushes in the orignial format? But in any case, way don't you send a patch and we can discuss? As the old saying goes, "code talks, bullshit walks". :-) Regards, - Ted
Re: GDPR compliance best practices?
On Sun, Jun 03, 2018 at 07:46:17PM +0200, Peter Backes wrote: > > Let's be honest: We do not know what legitimization exactly in each > specific case the git metadata is being distributed under. It seems like you are engaging in something even more dangerous than a hardware engineering pretending they know how program, or a software engineer knowing how to use as oldering iron --- and that's a programmer pretending they know enough that they can speculate on the law. I would gently suggest that if you really want to engage in something practical than speculating how the GPDR compliance will work out in actual practice, that you contact a lawyer and get official legal advice? After getting that advice, if you or your company wants to implemnt, you can then send patches, and those can get debated using the usual patch submission process. Cheers, - Ted
[Feature request] Add config option to gpgsign IFF key is present
Currently, `commit.gpgsign` allows you to give either 'true' or 'false' as a value. If the key is not present, commits will fail: ```sh $ git commit -m "example" error: gpg failed to sign the data fatal: failed to write commit object ``` I like to reuse my config file across several machines, some of which do not have my GPG key. Would it be possible to add an option to sign the commit only if the private key for `user.signingkey` is present? It could be named something like `commit.gpgsign=default-yes`. Thank you for your time, Joshua Nelson
[PATCH 1/4] teach log --no-walk=unsorted, which avoids sorting
From: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
When 'git log' is passed the --no-walk option, no revision walk takes
place, naturally. Perhaps somewhat surprisingly, however, the provided
revisions still get sorted by commit date. So e.g 'git log --no-walk
HEAD HEAD~1' and 'git log --no-walk HEAD~1 HEAD' give the same result
(unless the two revisions share the commit date, in which case they
will retain the order given on the command line). As the commit that
introduced --no-walk (8e64006 (Teach revision machinery about
--no-walk, 2007-07-24)) points out, the sorting is intentional, to
allow things like
git log --abbrev-commit --pretty=oneline --decorate --all --no-walk
to show all refs in order by commit date.
But there are also other cases where the sorting is not wanted, such
as
command producing revisions in order |
git log --oneline --no-walk --stdin
To accomodate both cases, leave the decision of whether or not to sort
up to the caller, by allowing --no-walk={sorted,unsorted}, defaulting
to 'sorted'.
Signed-off-by: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
---
builtin/log.c| 2 +-
builtin/revert.c | 2 +-
revision.c | 18 +++---
revision.h | 6 +-
t/t4202-log.sh | 10 ++
5 files changed, 32 insertions(+), 6 deletions(-)
diff --git a/builtin/log.c b/builtin/log.c
index ecc2793..20838b1 100644
--- a/builtin/log.c
+++ b/builtin/log.c
@@ -456,7 +456,7 @@ int cmd_show(int argc, const char **argv, const char
*prefix)
init_revisions(rev, prefix);
rev.diff = 1;
rev.always_show_header = 1;
- rev.no_walk = 1;
+ rev.no_walk = REVISION_WALK_NO_WALK_SORTED;
rev.diffopt.stat_width = -1;/* Scale to real terminal size */
memset(opt, 0, sizeof(opt));
diff --git a/builtin/revert.c b/builtin/revert.c
index 82d1bf8..42ce399 100644
--- a/builtin/revert.c
+++ b/builtin/revert.c
@@ -193,7 +193,7 @@ static void parse_args(int argc, const char **argv, struct
replay_opts *opts)
struct setup_revision_opt s_r_opt;
opts-revs = xmalloc(sizeof(*opts-revs));
init_revisions(opts-revs, NULL);
- opts-revs-no_walk = 1;
+ opts-revs-no_walk = REVISION_WALK_NO_WALK_SORTED;
if (argc 2)
usage_with_options(usage_str, options);
memset(s_r_opt, 0, sizeof(s_r_opt));
diff --git a/revision.c b/revision.c
index 9e8f47a..2faf675 100644
--- a/revision.c
+++ b/revision.c
@@ -1298,7 +1298,7 @@ static int handle_revision_opt(struct rev_info *revs, int
argc, const char **arg
!strcmp(arg, --no-walk) || !strcmp(arg, --do-walk) ||
!strcmp(arg, --bisect) || !prefixcmp(arg, --glob=) ||
!prefixcmp(arg, --branches=) || !prefixcmp(arg, --tags=) ||
- !prefixcmp(arg, --remotes=))
+ !prefixcmp(arg, --remotes=) || !prefixcmp(arg, --no-walk=))
{
unkv[(*unkc)++] = arg;
return 1;
@@ -1693,7 +1693,18 @@ static int handle_revision_pseudo_opt(const char
*submodule,
} else if (!strcmp(arg, --not)) {
*flags ^= UNINTERESTING;
} else if (!strcmp(arg, --no-walk)) {
- revs-no_walk = 1;
+ revs-no_walk = REVISION_WALK_NO_WALK_SORTED;
+ } else if (!prefixcmp(arg, --no-walk=)) {
+ /*
+* Detached form (--no-walk X as opposed to --no-walk=X)
+* not allowed, since the argument is optional.
+*/
+ if (!strcmp(arg + 10, sorted))
+ revs-no_walk = REVISION_WALK_NO_WALK_SORTED;
+ else if (!strcmp(arg + 10, unsorted))
+ revs-no_walk = REVISION_WALK_NO_WALK_UNSORTED;
+ else
+ return error(invalid argument to --no-walk);
} else if (!strcmp(arg, --do-walk)) {
revs-no_walk = 0;
} else {
@@ -2116,10 +2127,11 @@ int prepare_revision_walk(struct rev_info *revs)
}
e++;
}
- commit_list_sort_by_date(revs-commits);
if (!revs-leak_pending)
free(list);
+ if (revs-no_walk != REVISION_WALK_NO_WALK_UNSORTED)
+ commit_list_sort_by_date(revs-commits);
if (revs-no_walk)
return 0;
if (revs-limited)
diff --git a/revision.h b/revision.h
index cb5ab35..a95bd0b 100644
--- a/revision.h
+++ b/revision.h
@@ -41,6 +41,10 @@ struct rev_cmdline_info {
} *rev;
};
+#define REVISION_WALK_WALK 0
+#define REVISION_WALK_NO_WALK_SORTED 1
+#define REVISION_WALK_NO_WALK_UNSORTED 2
+
struct rev_info {
/* Starting list */
struct commit_list *commits;
@@ -62,7 +66,7 @@ struct rev_info {
/* Traversal flags */
unsigned intdense:1,
prune:1,
- no_walk:1,
+
[PATCH 2/4] revisions passed to cherry-pick should be in default order
From: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
'git cherry-pick' internally sets the --reverse option while walking
revisions, so that 'git cherry-pick branch@{u}..branch' will apply the
revisions starting at the oldest one. If no uninteresing revisions are
given, --no-walk is implied. Still, the documentation for 'git
cherry-pick --stdin' uses the following example:
git rev-list --reverse master -- README | git cherry-pick -n --stdin
The above would seem to reverse the revisions in the output (which it
does), and then pipe them to 'git cherry-pick', which would reverse
them again and apply them in the wrong order. The same problem occurs
when supplying revisions explicitly on the command line instead of
sending them to stdin.
Because of the sorting-by-date that is done by the revision walker
(even with the implied --no-walk), the ordering in the output from
'git rev-list' in the example above is effectively ignored, and the
above actually works most of the time. However, if revisions share a
commit date (as can easily happen as a result of rebasing), they do
get applied out-of-order.
Update the documentation not to suggest reversing the input to 'git
cherry-pick'. Also update test cases where the inputs are reversed.
Signed-off-by: Martin von Zweigbergk martin.von.zweigbe...@gmail.com
---
Documentation/git-cherry-pick.txt | 2 +-
t/t3508-cherry-pick-many-commits.sh | 2 +-
t/t3510-cherry-pick-sequence.sh | 4 ++--
3 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-cherry-pick.txt
b/Documentation/git-cherry-pick.txt
index 0e170a5..454e205 100644
--- a/Documentation/git-cherry-pick.txt
+++ b/Documentation/git-cherry-pick.txt
@@ -181,7 +181,7 @@ EXAMPLES
are in next but not HEAD to the current branch, creating a new
commit for each new change.
-`git rev-list --reverse master -- README | git cherry-pick -n --stdin`::
+`git rev-list master -- README | git cherry-pick -n --stdin`::
Apply the changes introduced by all commits on the master
branch that touched README to the working tree and index,
diff --git a/t/t3508-cherry-pick-many-commits.sh
b/t/t3508-cherry-pick-many-commits.sh
index 75f7ff4..020baaf 100755
--- a/t/t3508-cherry-pick-many-commits.sh
+++ b/t/t3508-cherry-pick-many-commits.sh
@@ -164,7 +164,7 @@ test_expect_success 'cherry-pick --stdin works' '
git checkout -f master
git reset --hard first
test_tick
- git rev-list --reverse first..fourth | git cherry-pick --stdin
+ git rev-list first..fourth | git cherry-pick --stdin
git diff --quiet other
git diff --quiet HEAD other
check_head_differs_from fourth
diff --git a/t/t3510-cherry-pick-sequence.sh b/t/t3510-cherry-pick-sequence.sh
index f4e6450..9e28910 100755
--- a/t/t3510-cherry-pick-sequence.sh
+++ b/t/t3510-cherry-pick-sequence.sh
@@ -400,7 +400,7 @@ test_expect_success '--continue of single-pick respects -x'
'
test_expect_success '--continue respects -x in first commit in multi-pick' '
pristine_detach initial
- test_must_fail git cherry-pick -x picked anotherpick
+ test_must_fail git cherry-pick -x anotherpick picked
echo c foo
git add foo
git cherry-pick --continue
@@ -430,7 +430,7 @@ test_expect_success '--signoff is not automatically
propagated to resolved confl
test_expect_success '--signoff dropped for implicit commit of resolution,
multi-pick case' '
pristine_detach initial
- test_must_fail git cherry-pick -s picked anotherpick
+ test_must_fail git cherry-pick -s anotherpick picked
echo c foo
git add foo
git cherry-pick --continue
--
1.7.11.1.104.ge7b44f1
--
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 3/4] cherry-pick/revert: respect order of revisions to pick
From: Martin von Zweigbergk martin.von.zweigbe...@gmail.com 'git cherry-pick A B' implicitly sends --no-walk=sorted to the revision walker, which means that the older of A and B will be applied first, which is most likely surprising to most. Fix this by instead sending --no-walk=unsorted to the revision walker. Signed-off-by: Martin von Zweigbergk martin.von.zweigbe...@gmail.com --- This has actually been reported before, in http://thread.gmane.org/gmane.comp.version-control.git/164794/focus=164807, where I apparently replied myself. Incidentally, it seems like the unrelated bug in 'git show' I reported in that thread is the one that Junio mentioned got fixed recently. builtin/revert.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/revert.c b/builtin/revert.c index 42ce399..98ad641 100644 --- a/builtin/revert.c +++ b/builtin/revert.c @@ -193,7 +193,7 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts) struct setup_revision_opt s_r_opt; opts-revs = xmalloc(sizeof(*opts-revs)); init_revisions(opts-revs, NULL); - opts-revs-no_walk = REVISION_WALK_NO_WALK_SORTED; + opts-revs-no_walk = REVISION_WALK_NO_WALK_UNSORTED; if (argc 2) usage_with_options(usage_str, options); memset(s_r_opt, 0, sizeof(s_r_opt)); -- 1.7.11.1.104.ge7b44f1 -- 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 4/4] cherry-pick/revert: default to topological sorting
From: Martin von Zweigbergk martin.von.zweigbe...@gmail.com When 'git cherry-pick' and 'git revert' are used with ranges such as 'git cherry-pick A..B', the order of the commits to pick are determined by the default date-based sorting. If a commit has a commit date before the commit date of its parent, it will therfore be applied before its parent. In the context of cherry-pick/revert, this is most likely not what the user expected, so let's enable topological sorting by default. Signed-off-by: Martin von Zweigbergk martin.von.zweigbe...@gmail.com --- builtin/revert.c | 1 + 1 file changed, 1 insertion(+) diff --git a/builtin/revert.c b/builtin/revert.c index 98ad641..6880ce5 100644 --- a/builtin/revert.c +++ b/builtin/revert.c @@ -194,6 +194,7 @@ static void parse_args(int argc, const char **argv, struct replay_opts *opts) opts-revs = xmalloc(sizeof(*opts-revs)); init_revisions(opts-revs, NULL); opts-revs-no_walk = REVISION_WALK_NO_WALK_UNSORTED; + opts-revs-topo_order = 1; if (argc 2) usage_with_options(usage_str, options); memset(s_r_opt, 0, sizeof(s_r_opt)); -- 1.7.11.1.104.ge7b44f1 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] Re: cherry-pick and 'log --no-walk' and ordering
From: Martin von Zweigbergk martin.von.zweigbe...@gmail.com This series adds supports for 'git log --no-walk=unsorted', which should be useful for the re-roll of my mz/rebase-range series. It also addresses the bug in cherry-pick/revert, which makes it sort revisions by date. On Fri, Aug 10, 2012 at 11:28 PM, Junio C Hamano gits...@pobox.com wrote: Range limited revision walking, e.g. git cherry-pick A..B D~4..D, fundamentally implies sorting and you cannot assume B would appear before D only because B comes before D on the command line (B may even be inside D~4..D range in which case it would not even appear in the final output). Sorry, I probably wasn't clear; I mentioned revision walking, but I only meant the no-walk case. I hope the patches make sense. Martin von Zweigbergk (4): teach log --no-walk=unsorted, which avoids sorting revisions passed to cherry-pick should be in default order cherry-pick/revert: respect order of revisions to pick cherry-pick/revert: default to topological sorting Documentation/git-cherry-pick.txt | 2 +- builtin/log.c | 2 +- builtin/revert.c| 3 ++- revision.c | 18 +++--- revision.h | 6 +- t/t3508-cherry-pick-many-commits.sh | 2 +- t/t3510-cherry-pick-sequence.sh | 4 ++-- t/t4202-log.sh | 10 ++ 8 files changed, 37 insertions(+), 10 deletions(-) -- 1.7.11.1.104.ge7b44f1 -- 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: 2.6.12 hangs on boot
On Saturday 25 June 2005 02:20, Linus Torvalds wrote: On Wed, 22 Jun 2005, Alexander Y. Fomichev wrote: I've been trying to switch from 2.6.12-rc3 to 2.6.12 on Dual EM64T 2.8 GHz [ MoBo: Intel E7520, intel 82801 ] but kernel hangs on boot right after records: Booting processor 2/1 rip 6000 rsp 8100023dbf58 Initializing CPU#2 Hmm.. Since you seem to be a git user, maybe you could try the git bisect thing to help narrow down exactly where this happened (and help test that thing too ;). [skiped] Ok, as i can see [and as Andi guessed http://bugme.osdl.org/show_bug.cgi?id=4792] issue have been introduced by new TSC sync algorithm git id: dda50e716dc9451f40eebfb2902c260e4f62cf34. And, yes, seems like it depends of timings... In my case kludge with insertion of low delay (e.g. printk) between cpu_set/mb and tsc_sync_wait() makes kernel bootable. diff -urN b/arch/x86_64/kernel/smpboot.c a/arch/x86_64/kernel/smpboot.c --- b/arch/x86_64/kernel/smpboot.c 2005-07-17 21:55:55.0 +0400 +++ a/arch/x86_64/kernel/smpboot.c 2005-07-17 21:57:56.0 +0400 @@ -451,6 +451,7 @@ cpu_set(smp_processor_id(), cpu_online_map); mb(); + printk(KERN_INFO We're still here!\n); /* Wait for TSC sync to not schedule things before. We still process interrupts, which could see an inconsistent time in that window unfortunately. */ -- Best regards. Alexander Y. Fomichev [EMAIL PROTECTED] Public PGP key: http://sysadminday.org.ru/gluk.asc - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.12 hangs on boot
On Saturday 25 June 2005 02:20, Linus Torvalds wrote: On Wed, 22 Jun 2005, Alexander Y. Fomichev wrote: I've been trying to switch from 2.6.12-rc3 to 2.6.12 on Dual EM64T 2.8 GHz [ MoBo: Intel E7520, intel 82801 ] but kernel hangs on boot right after records: Booting processor 2/1 rip 6000 rsp 8100023dbf58 Initializing CPU#2 Hmm.. Since you seem to be a git user, maybe you could try the git bisect thing to help narrow down exactly where this happened (and help test that thing too ;). You can basically use git to find the half-way point between a set of known good points and a known bad point (bisecting the set of commits), and doing just a few of those should give us a much better view of where things started going wrong. For example, since you know that 2.6.12-rc3 is good, and 2.6.12 is bad, you'd do git-rev-list --bisect v2.6.12 ^v2.6.12-rc3 where the v2.6.12 ^v2.6.12-rc3 thing basically means everything in v2.6.12 but _not_ in v2.6.12-rc3 (that's what the ^ marks), and the --bisect flag just asks git-rev-list to list the middle-most commit, rather than all the commits in between those kernel versions. You should get the answer 0e6ef3e02b6f07e37ba1c1abc059f8bee4e0847f, but before you go any further, just make sure your git index is all clean: git status should not print anything else than nothing to commit. If so, then you're ready to try the new mid-point head: git-rev-list --bisect v2.6.12 ^v2.6.12-rc3 .git/refs/heads/try1 git checkout try1 which will create a new branch called try1, where the head is that mid-point, and it will switch to that branch (this requires a fairly recent git, btw, so make sure you update your git first). Then, compile that kernel, and try it out. Now, there are two possibilities: either try1 ends up being good, or it still shows the bug. If it is a buggy kernel, then you now have a new bad point, and you do git-rev-list --bisect try1 ^v2.6.12-rc3 .git/refs/heads/try2 git checkout try2 which is all the same thing as you did before, except now we use try1 as the known bad one rather than v2.6.12 (and we call the new branch try2 of course). However, if that try1 is _good_, and doesn't show the bug, then you shouldn't replace the other known good case, but instead you should add it to the list of good commits (aka commits we don't want to know about): git-rev-list --bisect v2.6.12 ^v2.6.12-rc3 ^try1 .git/refs/heads/try2 git checkout try2 ie notice how we now say: want to get the bisection of the commits in v2.6.12 (known bad) but _not_ in either of v2.6.12-rc3 or the 'try1' branch (which are known good). After compiling and testing a few kernels, you will have narrowed the range down a _lot_, and at some point you can just say git-rev-list --pretty try4 ^v2.6.12-rc3 ^try1 ^try3 (or however the success/failure pattern ends up being - the above example line assumes that try1 didn't have the bug, but try2 did, and then try3 was ok again but try4 was buggy), and you'll get a fairly small list of commits that are the potential bad ones. After the above four tries, you'd have limited it down to a list of 95 changes (from the original 1520), so it would really be best to try six or seven different kernels, but at that point you'd have it down to less than 20 commits and then pinpointing the bug is usually much easier. And when you're done, you can just do git checkout master and you're back to where you started. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ Thank you for your answer, i've been on vacations last two weeks, and i didn't have an access to my mail account. Hmmm... it seems that 'bisect' method not applicable to this host, this is production server, not so critical to one or two reboots but 'bisect' will require much more, i suspect. I've another host, nearly the same as of hardware and non-critical where such tests could be done , but i haven't a serial console on it as now. It takes some time to link console because both of this are remote hosts. -- Best regards. Alexander Y. Fomichev [EMAIL PROTECTED] Public PGP key: http://sysadminday.org.ru/gluk.asc - To unsubscribe from this list: send the line unsubscribe git in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
