* Re: [PATCH] shell-prompt: clean up nested if-then
From: Simon Oosthoek @ 2013-02-19 8:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Martin Erik Werner, Jonathan Nieder, git, trsten,
Felipe Contreras
In-Reply-To: <7vtxp98bmx.fsf@alter.siamese.dyndns.org>
On 19/02/13 00:07, Junio C Hamano wrote:
>
> I think you are misreading a suggestion that is somewhat misguided
> (yes "[ <condition> && <another> ]" does not make sense, but that is
> not applicable to "test <conditon> && test <another>"); ignore it.
>
> It is fine to write "test <condition> && test <another>" and that
> works portably to even pre-posix systems.
(that's like doing "ls file && rm file" )
>
> But the existing code the patch touches favors [] over test
> consistently; that alone is a good reason to stick with [] in _this_
> script, even though it is against Git's overall shell script style.
>
I suppose it would be fine if a patch was sent to update the entire
git-prompt.sh code to be more in line with the Git shell script style...
My original gripe was just with doing it in one place while leaving all
the others unchanged. It makes for messy reading and leads to confusion.
Cheers
Simon
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Thomas Rast @ 2013-02-19 8:41 UTC (permalink / raw)
To: Ramkumar Ramachandra
Cc: Jonathan Nieder, Junio C Hamano, Matthieu Moy, Jeff King, git,
Shawn Pearce, Jakub Narebski, Christian Couder, Pat Thoyts,
Paul Mackerras, Carlos Martín Nieto, Thomas Gummerer,
David Barr, Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <CALkWK0nnkfrHi-0=c-bXdBHaOeBsCdccZDJZX5LDs0dT=SsReg@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Jonathan Nieder wrote:
>> Ramkumar Ramachandra wrote:
>>
>>> The short undiplomatic version of that is that our mentors suck (I'm
>>> not pointing fingers, but that's what I infer from failing projects).
>>
>> Hold on a second. I'm not remembering such a grim outcome with 100%
>> failure from prior summers of code as you're describing. Before I
>> start beating myself up, I guess I'd like a little more information
>> --- is there some specific project or statistic that you're thinking
>> of that brings you to that conclusion?
>
> In retrospect, I might have been unnecessarily harsh there.
>
> One of the main measures of a mentor's success, in my opinion, is
> having his student stick around after the Summer of Code: the mentor
> is the student's primary link to the community. There have been 4~5
> students every year, times 6 years (is that how long we've been
> participating?). How many of those students have felt part of the
> community?
In defense of Thomas, whose project was mentioned earlier as a prime
example of something that is "too big":
He's in fact still working on the index-API angle, as part of a thesis
at university.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Google Summer of Code 2013 (GSoC13)
From: Ramkumar Ramachandra @ 2013-02-19 9:00 UTC (permalink / raw)
To: Jeff King
Cc: Thomas Rast, git, Shawn Pearce, Jakub Narebski, Christian Couder,
Pat Thoyts, Paul Mackerras, Carlos Martín Nieto,
Thomas Gummerer, David Barr, Jens Lehmann, Nguyen Thai Ngoc Duy
In-Reply-To: <20130218211321.GD27308@sigill.intra.peff.net>
Jeff King wrote:
> On Tue, Feb 19, 2013 at 01:15:49AM +0530, Ramkumar Ramachandra wrote:
>
>> Take what I'm about to say with a pinch of salt, because I've never mentored.
>>
>> Mentors often don't provide much technical assistance: students should
>> just post to the list with queries, or ask on #git-devel. Mentors
>> serve a different purpose; their primary responsibility, in my
>> opinion, is to teach the student a sustainable productive workflow.
>> This means: profiling them to figure out where they're losing out. Do
>> they have the habit of:
>> - posting to the list regularly?
>> - CC'ing the right people?
>> - iterating quickly after reviews?
>> - using gdb efficiently to quickly understand parts?
>> - using git efficiently for the rebase/ patch workflow?
>
> I think you are spot-on. Those are the things that students need to
> learn to do, and what mentors should be pushing them towards. But it
> seems like we have the same problems with it year after year, and I know
> mentors have worked on it. I'm not sure where the problem is.
I essentially have a couple of suggestions:
- Be more thorough about discussing proposals; pick mentors from those
who are deeply involved in the discussion, and are interested in the
student.
- Increase the visibility of every GSoC project in the community.
Like I suggested earlier, a set of GSoC branches in-tree would be a
great start: it's easy to go through the `log`, and tell if the
student has been idle for a while. We can put up links to the GitHub
graphs for each of these branches.
>> > I very much agree with you here. One problem is that those smaller
>> > projects often do not sound as grand or as interesting, and so students
>> > do not propose them. We have to work with the applicants we get.
>>
>> We have to post well-crafted proposals like this to pique their interest.
>
> True. I think we can bear some of the blame in the proposal writing. But
> if you look at the applications each year, they tend to cluster around
> one or two projects, and most projects get no hits at all. It could be
> because they're badly written. But I think it is also that they are not
> in areas that are as flashy (and the flashiness often correlates with
> complexity).
We need to collaborate on proposal writing, I think (which is why I
suggested one-thread-per-proposal in a different email). In the past,
it has mostly been one person writing the entire thing.
>> There is one easy way to fight spam: don't expose a web-based editing
>> interface at all. It's mainly going to be maintained by the
>> community, and we're all much more comfortable in our editors and git.
>> We can give the regulars direct commit access and ask the rest to
>> submit pull requests. Make it cost pennies, so any of us can easily
>> afford it: just a cheap domain, DNS, and static HTML hosting.
>
> I'd be totally fine with that. You'd need to pick a static generator
> framework (I don't think it is a good idea for everybody to be writing
> raw html). I suspect kernel.org would be happy to host the static pages,
> but if not, GitHub can pick up the hosting tab (and we could probably do
> it as a subdomain under git-scm.com, too, if people want).
Ofcourse. Nobody wants to write raw HTML. Additionally, I'd love it
if we could post new posts via email, since we already have the habit
of writing emails.
^ permalink raw reply
* Proposal: sharing .git/config
From: Ramkumar Ramachandra @ 2013-02-19 9:25 UTC (permalink / raw)
To: Git List
Hi,
I have this itch where I want to share my remotes config between
machines. In my fork, I should be able to specify where my upstream
sources are, so remotes get set up automatically when I clone. There
are also other things in .git/config that would be nice to share, like
whether to do a --word-diff (why isn't it a configuration variable
yet?) on the repository. The only problem is that I have no clue how
to implement this: I'm currently thinking a special remote ref?
Ram
^ permalink raw reply
* Re: [RFC/PATCH] Introduce branch.<name>.pushremote
From: Ramkumar Ramachandra @ 2013-02-19 9:27 UTC (permalink / raw)
To: Blind; +Cc: Git List
In-Reply-To: <CAGL0X-rKnWBy-Ff=YmEdqgo8RFb40FXTxvUM5X77YaQvhAGHYg@mail.gmail.com>
Blind wrote:
> If I understand correctly,
> in your scenario the branches with branch.<name>.pushremote
> will be still included in the $git push <remote> --all?
Yes, this is correct.
> Are you considering some way to exclude a branch from "push --all"
> (branch.<name>.push = always, explicit, never... for example)?
No. I don't see why push.default is limiting.
> Or maybe, if the branch is already marked as special
> with branch.<name>.pushremote,
> then it could be logical to push it only when is explicitly specified
> on the command line (excluded from --all)?
Huh? Why would I treat this as a special case?
^ permalink raw reply
* RE: Is this a bug?
From: David Wade @ 2013-02-19 9:32 UTC (permalink / raw)
To: git@vger.kernel.org
Hi,
I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m "#ifdef ...." '
Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message.
Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ?
Thanks!
David Wade
Analyst, Seismic Imaging Development
ITC SUB RES
Statoil ASA
Mobile: +47 97572157
Email: dawad@statoil.com
Visitor address: Vassbotnen 23, Forus, Norway
Incorporation number: NO 923 609 016 MVA
www.statoil.com
Please consider the environment before printing this e-mail.
-------------------------------------------------------------------
The information contained in this message may be CONFIDENTIAL and is
intended for the addressee only. Any unauthorised use, dissemination of the
information or copying of this message is prohibited. If you are not the
addressee, please notify the sender immediately by return e-mail and delete
this message.
Thank you
^ permalink raw reply
* Re: [PATCH v3 0/9] User manual updates
From: W. Trevor King @ 2013-02-19 9:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git, Jonathan Nieder
In-Reply-To: <20130210223632.GF8377@odin.tremily.us>
[-- Attachment #1: Type: text/plain, Size: 974 bytes --]
On Mon, Feb 18, 2013 at 07:27:50AM -0500, W. Trevor King wrote:
> On Mon, Feb 18, 2013 at 12:56:07AM -0800, Junio C Hamano wrote:
> > I've taken the following to 'maint'…
>
> Should I rebase v4 onto maint so I don't accidentally collide with any
> of the previous patches which have already been merged there?
I tried this, but the backtick patch shouldn't move to maint due to:
On Sun, Feb 10, 2013 at 05:36:32PM -0500, W. Trevor King wrote:
> I based my changes on `master` to avoid colliding with 2de9b711
> (Documentation: the name of the system is 'Git', not 'git',
> 2013-01-21), but if you shifted them already I suppose you've fixed
> any conflicts ;).
I'll drop it for now, and revive it after the next release syncs
master and maint. I've rebased the remaining patches onto `maint`.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Re: [PATCH v3 8/9] user-manual: Flesh out uncommitted changes and submodule updates
From: W. Trevor King @ 2013-02-19 9:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git, Jonathan Nieder
In-Reply-To: <7vfw0ucoxk.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 861 bytes --]
On Sun, Feb 17, 2013 at 06:53:59PM -0800, Junio C Hamano wrote:
> > +If you did not commit your submodule changes, the changes will *not*
> > +be silently overwritten. Instead, you get the usual warning about not
> > +being able switch from a dirty branch.
>
> The scenario this talks about is to commit changes in the
> superproject and then to run "submodule update". I think the above
> clarification is still incomplete. You may have committed in the
> submodule some changes but not all.
>
> If you have uncommitted changes in your submodule working
> tree, "git submodule update" will not overwrite them.
> Instead...
>
> would be an improvement, I think.
Will do in v4.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Ramkumar Ramachandra @ 2013-02-19 9:40 UTC (permalink / raw)
To: Ævar Arnfjörð Bjarmason; +Cc: Git List, Junio C Hamano
In-Reply-To: <CACBZZX6BVuQWtrLuTVXZo+77sT4yZQ3pvN=_fMma24-zd0NNqA@mail.gmail.com>
Ævar Arnfjörð Bjarmason wrote:
> On Fri, Feb 8, 2013 at 10:10 PM, Ramkumar Ramachandra
> <artagnon@gmail.com> wrote:
>> For large repositories, many simple git commands like `git status`
>> take a while to respond. I understand that this is because of large
>> number of stat() calls to figure out which files were changed. I
>> overheard that Mercurial wants to solve this problem using itnotify,
>> but the idea bothers me because it's not portable. Will Git ever
>> consider using inotify on Linux? What is the downside?
>
> There's one relatively easy sub-task of this that I haven't seen
> mentioned: Improving the speed of interactive rebase on large (as in
> lots of checked out files) repositories.
>
> That's the single biggest thing that bothers me when I use Git with
> large repos, not the speed of "git status". When you "git rebase -i
> HEAD~100" re-arrange some patches and save the TODO list it takes say
> 0.5-1s for each patch to be applied, but at least 10x less than that
> on a small repository. E.g. try this on linux-2.6.git v.s. some small
> project with a few dozen files.
>
> I looked into this a long while ago and remembered that rebase was
> doing something like a git status for every commit that it made to
> check the dirtyness.
What is it really doing? I think the main culprit is
require_clean_work_tree() from git-sh-setup.sh, and that is only run
in the `--continue` and `exec` codepaths.
^ permalink raw reply
* Re: Is this a bug?
From: Andreas Ericsson @ 2013-02-19 9:42 UTC (permalink / raw)
To: David Wade; +Cc: git@vger.kernel.org
In-Reply-To: <937BB05095F39E46B969256AA776205322B2CF15C7@ST-EXCL29.statoil.net>
On 02/19/2013 10:32 AM, David Wade wrote:
> Hi,
>
> I wrote a commit message beginning with a hash (#) character, like
> this: 'git commit -m "#ifdef ...." '
>
> Everything went okay when committing, but then I tried 'git commit
> -amend' and without editing the commit message I was told I had an
> empty commit message.
>
> Is this a problem with my text editor (vim 7.2) or git itself? (git
> version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do
> ;-) ?
>
Lines starting with a hash sign are considered comments by git commit.
If you fire it up without '-m' you'll see that git puts all its own
notes about the commit in commented-out lines.
While empty commit messages aren't really unacceptable by git's model,
they're considered "almost certainly user errors". I expect the -m
flag being present when running 'git commit' causes the check for empty
message to be skipped, which isn't the case when amending the commit.
Btw, when I write messages probably similar to the one you just did, I
tend to write:
Use compat-layer __builtin_clz() #ifndef __GNUC__
precisely to avoid this issue. It also puts the imperative first,
which I find makes for smoother reading. Putting the condition first
screams for a comma and a slight stagger in reading flow, like so:
Unless built with gcc, use compat-layer __builtin_clz()
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
Considering the successes of the wars on alcohol, poverty, drugs and
terror, I think we should give some serious thought to declaring war
on peace.
^ permalink raw reply
* Re: Is this a bug?
From: Erik Faye-Lund @ 2013-02-19 9:47 UTC (permalink / raw)
To: David Wade; +Cc: git@vger.kernel.org
In-Reply-To: <937BB05095F39E46B969256AA776205322B2CF15C7@ST-EXCL29.statoil.net>
On Tue, Feb 19, 2013 at 10:32 AM, David Wade <DAWAD@statoil.com> wrote:
> Hi,
>
> I wrote a commit message beginning with a hash (#) character, like this: 'git commit -m "#ifdef ...." '
>
> Everything went okay when committing, but then I tried 'git commit -amend' and without editing the commit message I was told I had an empty commit message.
>
> Is this a problem with my text editor (vim 7.2) or git itself? (git version 1.7.2.2 under RedHat 5.8) Or something I'm not supposed to do ;-) ?
The problem is that when doing interactive editing of messages (like
'git commit --amend' does), git considers '#' as a comment-character.
You can disable this by using the --cleanup=verbatim switch (or some
other suiting cleanup-setting, see 'git help commit').
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Ramkumar Ramachandra @ 2013-02-19 9:49 UTC (permalink / raw)
To: blees; +Cc: Duy Nguyen, kusmabite, Robert Zeh, Junio C Hamano, Git List,
finnag
In-Reply-To: <511AAA92.4030508@gmail.com>
Karsten Blees wrote:
> Am 11.02.2013 04:53, schrieb Duy Nguyen:
>> On Sun, Feb 10, 2013 at 11:58 PM, Erik Faye-Lund <kusmabite@gmail.com> wrote:
>>> Karsten Blees has done something similar-ish on Windows, and he posted
>>> the results here:
>>>
>>> https://groups.google.com/forum/#!topic/msysgit/fL_jykUmUNE/discussion
>>>
>
> The new hashtable implementation in fscache [1] supports O(1) removal and has no mingw dependencies - might come in handy for anyone trying to implement an inotify daemon.
>
> [1] https://github.com/kblees/git/commit/f7eb85c2
Thanks! I'm cherry-picking this. Why didn't you propose replacing
hash.{c,h} with this in git.git though?
>>> I also seem to remember he doing a ReadDirectoryChangesW version, but
>>> I don't remember what happened with that.
>>
>> Thanks. I came across that but did not remember. For one thing, we
>> know the inotify alternative for Windows: ReadDirectoryChangesW.
>>
>
> I dropped ReadDirectoryChangesW because maintaining a 'live' file system cache became more and more complicated. For example, according to MSDN docs, ReadDirectoryChangesW *may* report short DOS 8.3 names (i.e. "PROGRA~1" instead of "Program Files"), so a correct and fast cache implementation would have to be indexed by long *and* short names...
>
> Another problem was that the 'live' cache had quite negative performance impact on mutating git commands (checkout, reset...). An inotify daemon running as a background process (not in-process as fscache) will probably affect everyone that modifies the working copy, e.g. running 'make' or the test-suite. This should be considered in the design.
Yes, an external daemon would report creation of *.o files, from the
compile, for instance. We need a way for it to be filtered at the
daemon itself, so git isn't burdened with the filtering.
^ permalink raw reply
* Re: inotify to minimize stat() calls
From: Ramkumar Ramachandra @ 2013-02-19 9:57 UTC (permalink / raw)
To: Robert Zeh; +Cc: Duy Nguyen, Junio C Hamano, Git List
In-Reply-To: <CAKXa9=pCSWtXq+5x_LcZ9gsSpa1yT0QD5DsBguTqosoH0cj-nw@mail.gmail.com>
Robert Zeh wrote:
> On Sun, Feb 10, 2013 at 9:21 PM, Duy Nguyen <pclouds@gmail.com> wrote:
>> On Mon, Feb 11, 2013 at 2:03 AM, Robert Zeh <robert.allan.zeh@gmail.com> wrote:
>>> On Sat, Feb 9, 2013 at 1:35 PM, Junio C Hamano <gitster@pobox.com> wrote:
>>>> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>>>>
>>>>> This is much better than Junio's suggestion to study possible
>>>>> implementations on all platforms and designing a generic daemon/
>>>>> communication channel. That's no weekend project.
>>>>
>>>> It appears that you misunderstood what I wrote. That was not "here
>>>> is a design; I want it in my system. Go implemment it".
>>>>
>>>> It was "If somebody wants to discuss it but does not know where to
>>>> begin, doing a small experiment like this and reporting how well it
>>>> worked here may be one way to do so.", nothing more.
>>>
>>> What if instead of communicating over a socket, the daemon
>>> dumped a file containing all of the lstat information after git
>>> wrote a file? By definition the daemon should know about file writes.
>>>
>>> There would be no network communication, which I think would make
>>> things more secure. It would simplify the rendezvous by insisting on
>>> well known locations in $GIT_DIR.
>>
>> We need some sort of interactive communication to the daemon anyway,
>> to validate that the information is uptodate. Assume that a user makes
>> some changes to his worktree before starting the daemon, git needs to
>> know that what the daemon provides does not represent a complete
>> file-change picture and it better refreshes the index the old way
>> once, then trust the daemon.
>>
>> I think we could solve that by storing a "session id", provided by the
>> daemon, in .git/index. If the session id is not present (or does not
>> match what the current daemon gives), refresh the old way. After
>> refreshing, it may ask the daemon for new session id and store it.
>> Next time if the session id is still valid, trust the daemon's data.
>> This session id should be different every time the daemon restarts for
>> this to work.
>
> I think we could do this without interactive communication,
> if we did the following:
> 1) The Daemon waits to see $GIT_DIR/lstat_request, and atomically
> writes out $GIT_DIR/lstat_cache. By atomically I mean that it writes
> things out to a temporary file, and then does a rename.
>
> 2) The client erases $GIT_DIR/lstat_cache, and writes
> $GIT_DIR/lstat_request
>
> I think this is better than socket based communication because there
> are fewer places to check
> for failures.
My main problem with file-based solutions is this: how will the daemon
accumulate inotify change events over time, and report it in a batch
to a git application that is spawned? Will it append to the
.git/inotify_changes file everytime there's a change? Wouldn't you
prefer to accumulate the events in-memory and report it over a socket
upon explicit request, to minimize IO?
^ permalink raw reply
* Feature idea : notes to track status of a commit, which remotes it is shared to
From: Mildred Ki'Lya @ 2013-02-19 9:38 UTC (permalink / raw)
To: git
Hi,
This is my first time on this list (and by the way, I'm not subscribed,
so please Cc me to the replies). I have an idea that could be useful to
make rewriting history safer and easier to new users (I'm training some
of them). I thought I could share this idea, but perhaps someone already
thought about it. And I'm not providing code.
The idea is to basically track automatically (in notes, either in the
notes namespace or in another namespace) which repository/remote
contains a commit. When doing git log, we'd see lines with each commit,
something like:
commit b044e6d0f1a1782820b052348ab0db314e2db3ca
Author: Myself <myself@localhost.localdomain>
Date: Tue Nov 20 16:46:38 2012 +0100
This is the commit description
Published on:
origin
git@git.host.com:pub/repo.git
Then, we could have all the history rewriting commands (such as rebase
or pull --rebase) die when rewriting commits that are already published
anywhere. We could make an exception for a --force/-f flag or
configuration option, or commits published in another local repository
owned by the same user.
In most setups, it could be useful to tell users they can safely rebase
without worrying about published commits as Git is tracking it for them.
Of course this is not an absolute security, but it's a good start.
What do you think?
Mildred
^ permalink raw reply
* Re: Proposal: sharing .git/config
From: Thomas Rast @ 2013-02-19 10:03 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0npW6TLdMNd5_zw-RAB0bjF9DDoyAVSx4Zx=7AmvdEo3w@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> I have this itch where I want to share my remotes config between
> machines. In my fork, I should be able to specify where my upstream
> sources are, so remotes get set up automatically when I clone.
Note that you need to carefully pick only certain bits of the config, as
otherwise there are big security headaches.
> There are also other things in .git/config that would be nice to
> share, like whether to do a --word-diff (why isn't it a configuration
> variable yet?)
Because that would break pretty much every script that uses git-diff?
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH v4 2/3] user-manual: Use request-pull to generate "please pull" text
From: W. Trevor King @ 2013-02-19 10:05 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, W. Trevor King
In-Reply-To: <cover.1361267945.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
Less work and more error checking (e.g. does a merge base exist?).
Add an explicit push before request-pull to satisfy request-pull,
which checks to make sure the references are publically available.
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 14 +++++---------
1 file changed, 5 insertions(+), 9 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index a4dbd9e..3aab106 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2305,17 +2305,13 @@ branch and then merge into each of the test and release branches. For
these changes, just apply directly to the "release" branch, and then
merge that into the "test" branch.
-To create diffstat and shortlog summaries of changes to include in a "please
-pull" request to Linus you can use:
+After pushing your work to `mytree`, you can use
+linkgit:git-request-pull[1] to prepare a "please pull" request message
+to send to Linus:
-------------------------------------------------
-$ git diff --stat origin..release
--------------------------------------------------
-
-and
-
--------------------------------------------------
-$ git log -p origin..release | git shortlog
+$ git push mytree
+$ git request-pull origin mytree release
-------------------------------------------------
Here are some of the scripts that simplify all this even further.
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v4 0/3] User manual updates
From: W. Trevor King @ 2013-02-19 10:04 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, W. Trevor King
In-Reply-To: <20130219093429.GA4024@odin.tremily.us>
From: "W. Trevor King" <wking@tremily.us>
Changes since v3 (v3 numbering):
* 1: user-manual: Use 'remote add' to setup push URLs
- Dropped (graduated into 'maint', e9b4908)
* 2: user-manual: Reorganize the reroll sections, adding 'git rebase -i'
- Added some comments giving example uses of 'commit --amend'. This
should make the section less lonely.
- Fix s/preferred/needed/
- Call interactive rebase commands "instructions" and "steps"
- Reworded interactive rebase return-to-shell description following
Junio's suggestions.
* 3: user-manual: Give 'git push -f' as an alternative to +master
- Dropped (graduated into 'maint', d1471e0)
* 4: user-manual: Mention 'git remote add' for remote branch config
- Dropped (graduated into 'maint', 47adb8a)
* 5: user-manual: Standardize backtick quoting
- Temporarily dropped (not rebased onto maint, due to conflicts with
2de9b71 (Documentation: the name of the system is 'Git', not
'git', 2013-01-21))
* 6: user-manual: Use 'git config --global user.*' for setup
- Dropped (graduated into 'maint', 632cc3e)
* 7: user-manual: Use request-pull to generate "please pull" text
- Reworded request-pull introduction based on Junio's suggestions.
* 8: user-manual: Flesh out uncommitted changes and submodule updates
- Adopt Junio's “did not commit” → “have uncommitted changes”
rephrasing.
* 9: user-manual: Use -o latest.tar.gz to create a gzipped tarball
- Dropped (graduated into 'maint', 7ed1690)
W. Trevor King (3):
user-manual: Reorganize the reroll sections, adding 'git rebase -i'
user-manual: Use request-pull to generate "please pull" text
user-manual: Flesh out uncommitted changes and submodule updates
Documentation/user-manual.txt | 133 ++++++++++++++++++++++++------------------
1 file changed, 77 insertions(+), 56 deletions(-)
--
1.8.1.336.g94702dd
^ permalink raw reply
* [PATCH v4 3/3] user-manual: Flesh out uncommitted changes and submodule updates
From: W. Trevor King @ 2013-02-19 10:05 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, W. Trevor King
In-Reply-To: <cover.1361267945.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
If you try and update a submodule with a dirty working directory, you
get an error message like:
$ git submodule update
error: Your local changes to the following files would be overwritten by checkout:
...
Please, commit your changes or stash them before you can switch branches.
Aborting
...
Mention this in the submodule notes. The previous phrase was short
enough that I originally thought it might have been referring to the
reflog note (obviously, uncommitted changes will not show up in the
reflog either ;).
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 3aab106..df7524a 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -3739,7 +3739,9 @@ module a
NOTE: The changes are still visible in the submodule's reflog.
-This is not the case if you did not commit your changes.
+If you have uncommitted changes in your submodule working tree, `git
+submodule update` will not overwrite them. Instead, you get the usual
+warning about not being able switch from a dirty branch.
[[low-level-operations]]
Low-level git operations
--
1.8.1.336.g94702dd
^ permalink raw reply related
* [PATCH v4 1/3] user-manual: Reorganize the reroll sections, adding 'git rebase -i'
From: W. Trevor King @ 2013-02-19 10:05 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, Jonathan Nieder, W. Trevor King
In-Reply-To: <cover.1361267945.git.wking@tremily.us>
From: "W. Trevor King" <wking@tremily.us>
I think this interface is often more convenient than extended cherry
picking or using 'git format-patch'. In fact, I removed the
cherry-pick section entirely. The entry-level suggestions for
rerolling are now:
1. git commit --amend
2. git format-patch origin
git reset --hard origin
...edit and reorder patches...
git am *.patch
3. git rebase -i origin
Signed-off-by: W. Trevor King <wking@tremily.us>
---
Documentation/user-manual.txt | 115 +++++++++++++++++++++++++-----------------
1 file changed, 69 insertions(+), 46 deletions(-)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 52c8523..a4dbd9e 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2556,6 +2556,12 @@ return mywork to the state it had before you started the rebase:
$ git rebase --abort
-------------------------------------------------
+If you need to reorder or edit a number of commits in a branch, it may
+be easier to use `git rebase -i`, which allows you to reorder and
+squash commits, as well as marking them for individual editing during
+the rebase. See <<interactive-rebase>> for details, and
+<<reordering-patch-series>> for alternatives.
+
[[rewriting-one-commit]]
Rewriting a single commit
-------------------------
@@ -2569,72 +2575,89 @@ $ git commit --amend
which will replace the old commit by a new commit incorporating your
changes, giving you a chance to edit the old commit message first.
+This is useful for fixing typos in your last commit, or for adjusting
+the patch contents of a poorly staged commit.
-You can also use a combination of this and linkgit:git-rebase[1] to
-replace a commit further back in your history and recreate the
-intervening changes on top of it. First, tag the problematic commit
-with
-
--------------------------------------------------
-$ git tag bad mywork~5
--------------------------------------------------
+If you need to amend commits from deeper in your history, you should
+use <<interactive-rebase,interactive rebase's `edit` instruction>>.
-(Either gitk or `git log` may be useful for finding the commit.)
+[[reordering-patch-series]]
+Reordering or selecting from a patch series
+-------------------------------------------
-Then check out that commit, edit it, and rebase the rest of the series
-on top of it (note that we could check out the commit on a temporary
-branch, but instead we're using a <<detached-head,detached head>>):
+Sometimes you want to edit a commit deeper in your history. One
+approach is to use `git format-patch` to create a series of patches,
+then reset the state to before the patches:
-------------------------------------------------
-$ git checkout bad
-$ # make changes here and update the index
-$ git commit --amend
-$ git rebase --onto HEAD bad mywork
+$ git format-patch origin
+$ git reset --hard origin
-------------------------------------------------
-When you're done, you'll be left with mywork checked out, with the top
-patches on mywork reapplied on top of your modified commit. You can
-then clean up with
+Then modify, reorder, or eliminate patches as needed before applying
+them again with linkgit:git-am[1]:
-------------------------------------------------
-$ git tag -d bad
+$ git am *.patch
-------------------------------------------------
-Note that the immutable nature of git history means that you haven't really
-"modified" existing commits; instead, you have replaced the old commits with
-new commits having new object names.
+[[interactive-rebase]]
+Using interactive rebases
+-------------------------
-[[reordering-patch-series]]
-Reordering or selecting from a patch series
--------------------------------------------
+You can also edit a patch series with an interactive rebase. This is
+the same as <<reordering-patch-series,reordering a patch series using
+`format-patch`>>, so use whichever interface you like best.
-Given one existing commit, the linkgit:git-cherry-pick[1] command
-allows you to apply the change introduced by that commit and create a
-new commit that records it. So, for example, if "mywork" points to a
-series of patches on top of "origin", you might do something like:
+Rebase your current HEAD on the last commit you want to retain as-is.
+For example, if you want to reorder the last 5 commits, use:
-------------------------------------------------
-$ git checkout -b mywork-new origin
-$ gitk origin..mywork &
+$ git rebase -i HEAD~5
-------------------------------------------------
-and browse through the list of patches in the mywork branch using gitk,
-applying them (possibly in a different order) to mywork-new using
-cherry-pick, and possibly modifying them as you go using `git commit --amend`.
-The linkgit:git-gui[1] command may also help as it allows you to
-individually select diff hunks for inclusion in the index (by
-right-clicking on the diff hunk and choosing "Stage Hunk for Commit").
-
-Another technique is to use `git format-patch` to create a series of
-patches, then reset the state to before the patches:
+This will open your editor with a list of steps to be taken to perform
+your rebase.
-------------------------------------------------
-$ git format-patch origin
-$ git reset --hard origin
--------------------------------------------------
+pick deadbee The oneline of this commit
+pick fa1afe1 The oneline of the next commit
+...
-Then modify, reorder, or eliminate patches as preferred before applying
-them again with linkgit:git-am[1].
+# Rebase c0ffeee..deadbee onto c0ffeee
+#
+# Commands:
+# p, pick = use commit
+# r, reword = use commit, but edit the commit message
+# e, edit = use commit, but stop for amending
+# s, squash = use commit, but meld into previous commit
+# f, fixup = like "squash", but discard this commit's log message
+# x, exec = run command (the rest of the line) using shell
+#
+# These lines can be re-ordered; they are executed from top to bottom.
+#
+# If you remove a line here THAT COMMIT WILL BE LOST.
+#
+# However, if you remove everything, the rebase will be aborted.
+#
+# Note that empty commits are commented out
+-------------------------------------------------
+
+As explained in the comments, you can reorder commits, squash them
+together, edit commit messages, etc. by editing the list. Once you
+are satisfied, save the list and close your editor, and the rebase
+will begin.
+
+The rebase will stop where `pick` has been replaced with `edit` or
+when a step in the list fails to mechanically resolve conflicts and
+needs your help. When you are done editing and/or resolving conflicts
+you can continue with `git rebase --continue`. If you decide that
+things are getting too hairy, you can always bail out with `git rebase
+--abort`. Even after the rebase is complete, you can still recover
+the original branch by using the <<reflogs,reflog>>.
+
+For a more detailed discussion of the procedure and additional tips,
+see the "INTERACTIVE MODE" section of linkgit:git-rebase[1].
[[patch-series-tools]]
Other tools
--
1.8.1.336.g94702dd
^ permalink raw reply related
* Re: Feature idea : notes to track status of a commit, which remotes it is shared to
From: Thomas Rast @ 2013-02-19 10:13 UTC (permalink / raw)
To: Mildred Ki'Lya; +Cc: git
In-Reply-To: <51234801.5050208@mildred.fr>
Mildred Ki'Lya <mildred-ml@mildred.fr> writes:
> The idea is to basically track automatically (in notes, either in the
> notes namespace or in another namespace) which repository/remote
> contains a commit. When doing git log, we'd see lines with each
> commit, something like:
>
> commit b044e6d0f1a1782820b052348ab0db314e2db3ca
> Author: Myself <myself@localhost.localdomain>
> Date: Tue Nov 20 16:46:38 2012 +0100
>
> This is the commit description
>
> Published on:
> origin
> git@git.host.com:pub/repo.git
The problem here is that doing this in notes is unreliable: you'd have
to identify all places where the set of "publishes" can change for any
commit, and update them there.
It's much easier, if a bit slower, to just run
git branch -r --contains $commit
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: Proposal: sharing .git/config
From: Ramkumar Ramachandra @ 2013-02-19 10:24 UTC (permalink / raw)
To: Thomas Rast; +Cc: Git List
In-Reply-To: <87ip5otybp.fsf@pctrast.inf.ethz.ch>
Thomas Rast wrote:
> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>
>> I have this itch where I want to share my remotes config between
>> machines. In my fork, I should be able to specify where my upstream
>> sources are, so remotes get set up automatically when I clone.
>
> Note that you need to carefully pick only certain bits of the config, as
> otherwise there are big security headaches.
Right. So, we can just start with remotes for the moment? Ideally,
there should be a way to specify which configuration options to
publish.
>> There are also other things in .git/config that would be nice to
>> share, like whether to do a --word-diff (why isn't it a configuration
>> variable yet?)
>
> Because that would break pretty much every script that uses git-diff?
diff.c already makes a differentiation between git_diff_ui_config()
and git_diff_basic_config(); there are configuration options that
should only be applied when the command is called interactively.
^ permalink raw reply
* Re: Feature idea : notes to track status of a commit, which remotes it is shared to
From: W. Trevor King @ 2013-02-19 10:30 UTC (permalink / raw)
To: Mildred Ki'Lya; +Cc: git
In-Reply-To: <51234801.5050208@mildred.fr>
[-- Attachment #1: Type: text/plain, Size: 804 bytes --]
On Tue, Feb 19, 2013 at 10:38:09AM +0100, Mildred Ki'Lya wrote:
> Then, we could have all the history rewriting commands (such as
> rebase or pull --rebase) die when rewriting commits that are already
> published anywhere. We could make an exception for a --force/-f flag
> or configuration option, or commits published in another local
> repository owned by the same user.
You might want to look into extending the sample pre-rebase hook,
which prevents topic branches that are already merged to 'next' branch
from getting rebased. You'd just have to loop over all remote
references instead of only checking the local 'next' branch.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Feature idea : notes to track status of a commit, which remotes it is shared to
From: W. Trevor King @ 2013-02-19 10:34 UTC (permalink / raw)
To: Thomas Rast, Mildred Ki'Lya; +Cc: git
In-Reply-To: <87bobgtxvk.fsf@pctrast.inf.ethz.ch>
[-- Attachment #1: Type: text/plain, Size: 369 bytes --]
On Tue, Feb 19, 2013 at 11:13:19AM +0100, Thomas Rast wrote:
> It's much easier, if a bit slower, to just run
>
> git branch -r --contains $commit
Ah, this would be better than looping in your hook ;).
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Proposal: sharing .git/config
From: Duy Nguyen @ 2013-02-19 10:34 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Git List
In-Reply-To: <CALkWK0npW6TLdMNd5_zw-RAB0bjF9DDoyAVSx4Zx=7AmvdEo3w@mail.gmail.com>
On Tue, Feb 19, 2013 at 4:25 PM, Ramkumar Ramachandra
<artagnon@gmail.com> wrote:
> Hi,
>
> I have this itch where I want to share my remotes config between
> machines. In my fork, I should be able to specify where my upstream
> sources are, so remotes get set up automatically when I clone. There
> are also other things in .git/config that would be nice to share, like
> whether to do a --word-diff (why isn't it a configuration variable
> yet?) on the repository. The only problem is that I have no clue how
> to implement this: I'm currently thinking a special remote ref?
If you check out the config file, then include.path should work. You
could add include.ref to point to a ref, but you need to deal with the
attached security implications. This has been proposed before (and
turned down, I think).
--
Duy
^ permalink raw reply
* Re: Proposal: sharing .git/config
From: Thomas Rast @ 2013-02-19 10:39 UTC (permalink / raw)
To: Ramkumar Ramachandra; +Cc: Thomas Rast, Git List
In-Reply-To: <CALkWK0m--MbtNzGH9hNPCCLJWhv6rjF9Y=WQ4qnHUFnE61p6kw@mail.gmail.com>
Ramkumar Ramachandra <artagnon@gmail.com> writes:
> Thomas Rast wrote:
>> Ramkumar Ramachandra <artagnon@gmail.com> writes:
>>> There are also other things in .git/config that would be nice to
>>> share, like whether to do a --word-diff (why isn't it a configuration
>>> variable yet?)
>>
>> Because that would break pretty much every script that uses git-diff?
>
> diff.c already makes a differentiation between git_diff_ui_config()
> and git_diff_basic_config(); there are configuration options that
> should only be applied when the command is called interactively.
It still breaks every other use of diff unless you make the diff output
depend on whether the user runs directly at the terminal (possibly using
git's own paging).
For example, if you just say something like 'git diff >file' for
inclusion in an email, you expect that to be a git-apply compatible
diff.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox