Am I missing something?
I guess the next best solution would be to also have a pre-push hook
that performs the same checks again, just in case the bad code managed
to get past the pre-commit hook for some reason or other. This feels
very redundant, but I guess it would work well.
Any other sugges
Junio C Hamano wrote:
> li...@haller-berlin.de (Stefan Haller) writes:
>
> > I guess the next best solution would be to also have a pre-push hook
> > that performs the same checks again, just in case the bad code managed
> > to get past the pre-commit hook for some rea
What is unique at the time of creating the commit might no longer be
unique a few years later.
So one strategy would be to add one or two digits to what %h returns, to
give some future leeway; or rely on the user to configure core.abbrev
appropriatly for their project; or just make the hard-coded v
Junio C Hamano wrote:
> Another thing to consider is that the proposed workflow would not
> scale if your team becomes larger. Requiring each and every commit
> on the trunk to be a merge commit, whose second parent (i.e. the tip
> of the feature branch) fast-forwards to the first parent of the
ng the "fixup" or "squash" commands in
the todo sheet.)
Will dropping commits work?
Does it make sense to insert "exec" commands, or will they run at
arbitrary times?
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
st attempts to rearrange patches"). I'm interested in more
details as to exactly what kind of attempts do or don't work. In
particular, I'm interested in fixup/squash commands (without reordering
anything else), or dropping (non-merge) commits.
I could of course experiment with these and try to find out myself, but
I was hoping someone would just know the answer off the top of their
head, saving me some time.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
ich I guess means
"use the initially given todo sheet unchanged". I don't see any tests
that do an interactive rebase and actually change the todo list.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
Junio C Hamano wrote:
> li...@haller-berlin.de (Stefan Haller) writes:
>
> > Thanks, this is interesting; I'm having trouble understanding the tests
> > though. Some of them use rebase -p -i, but I don't understand why they
> > use -i, or why that even works i
Lars Schneider wrote:
> An engineer works on a task branch and runs incremental builds — all
> is good. The engineer switches to another branch to review another
> engineer's work. This other branch changes a low-level header file,
> but no rebuild is triggered. The engineer switches back to t
Jeff King wrote:
> On Sun, Apr 09, 2017 at 10:38:42AM +0200, Stefan Haller wrote:
>
> > I think it's wrong to think about these leases as something that you
> > take before you start a rewindy operation. That's the wrong time to take
> > the lease; by that ti
Jacob Keller wrote:
> On Sun, Apr 9, 2017 at 4:00 AM, Stefan Haller wrote:
>
> > Maybe I wasn't clear enough about that in my proposal, but I propose to
> > always store the commit hash of the remote tracking branch as a new
> > lease after push and pull, not the lo
the one you described later in your mail. I
think it's fine if you have to fall back to using --force-with-lease
with explicit arguments in these cases. The suggestion is really only to
make the common case easier, which (for me) is working with a tracking
branch, and using push and pull with
Jeff King wrote:
> On Tue, Apr 11, 2017 at 02:37:27PM +0200, Stefan Haller wrote:
>
> > Are you talking about the case where the user doesn't say git pull, but
> > instead says "git fetch && git merge --ff @{u}"? Just so that I
> > understand the
Stefan Haller wrote:
> Then, every command that either integrates the remote tracking branch
> into the local branch, or updates the remote tracking branch to the
> local branch, will update the value of the "lease" entry. The most
> obvious ones are "git pull&quo
tically. I'd be interested in your
thoughts about that proposal, Junio; you didn't say anything about that
at all yet.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
certainly never want to.
What I'm getting at is that there's a lot of things that you have to
remember to not do in order to make --force-with-lease without parameter
a useful tool.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
more than one
branch at a time, because doing "git pull" on one branch will do an
implicit "git fetch" on the other.
I like the idea of git maintaining a separate "last integrated" commit
for each branch, I think this could solve it in a nice way. I'm probably
no
an then investigate the situation and either use push -f
or manually update branch.*.integrated when they have convinced
themselves that everything is fine.
I find it essential that --force-with-lease might fail erroneously, but
never succeed erroneously, and I think this proposal would guarantee
that.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
ht word here. The point of
--force-with-lease is to provide a guarantee, so if you can't trust the
guarantee, it makes the feature rather pointless.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
Ævar Arnfjör? Bjarmason wrote:
> On Sat, Apr 8, 2017 at 5:03 PM, Stefan Haller wrote:
>
> > Here's a rough proposal for how I would imagine this to work.
> >
> > For every local branch that has a remote tracking branch, git maintains
> > a new config entry bra
ize new commits as
ones that you haven't seen before. But what if the other party has
rewritten the branch and squashed improvements into commits in the
middle of it? The head commit will then look the same as before, and the
only way to tell whether you are overwriting something new is by
comparing
> And I think that may be converging on the "integrate" refs that Stefan is
> talking about elsewhere (or some isomorphism of it).
Does it make things clearer if we don't use the term "integrate", but
call the config value in my proposal simply "branch.*.lease"?
--
Stefan Haller
Ableton
http://www.ableton.com/
that in my proposal, but I propose to
always store the commit hash of the remote tracking branch as a new
lease after push and pull, not the local branch. This way it works
nicely with pull --rebase and a branch that has extra local commits.
--
Stefan Haller
Ableton
http://www.ableton.com/
571f6852.1070...@qt.io/T/#u>,
which doesn't explain *why* gitk shows the boundary commits in the first
place.)
In my opinion, when saying "gitk --author=foo", the list of commits in
the top pane should look the same as the ouput of
"git log --oneline --author=foo".
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
d 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
h
scrolling. I never posted this patch because I bet many people like the
current behaviour. Just so you know that such a change might be
controversial.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
--
To unsubscribe from this list: send the line "unsubscribe git" in
th
his for years now, as we still run
into it once in a while, and it's pretty annoying; but I still didn't
get around to it yet.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
not selecting the search hint is an option: the
selection is used to keep track of where to search next.
Can't we just raise the currentsearchhit tag above the sel tag?
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
--
To unsubscribe from this list: send the li
would like, but it
works well (except when you already took some time to selectively stage
hunks or lines for the next commit). So yes, a context menu for this
would be very welcome.
--
Stefan Haller
Berlin, Germany
http://www.haller-berlin.de/
--
To unsubscribe from this list: send the line &quo
ly I'm using my own gitk with
my patch applied, and I do use the "First parent" checkbox rather often.
--
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
Sometimes it's desirable to see what changes were introduced by a
merge commit, rather than how conflicts were resolved. This adds
a checkbox which, when turned on, makes gitk show the equivalent
of "git show --first-parent " for merge commits.
Signed-off-by: Stefan Haller
---
T
hether we want to ship the glue script too, and how.
Any opinions?
-Stefan
>From 80acb168ef13a55521e9b821450800450660769d Mon Sep 17 00:00:00 2001
From: Stefan Haller
Date: Thu, 18 Jul 2013 18:55:11 +0200
Subject: [PATCH] gitk: Add options --select-file and --select-line
These can be used in
d implicitly, like the
window size.
I don't have good suggestions how to solve this; just pointing out
problems.
--
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...@
>
However, looking at git://ozlabs.org/~paulus/gitk.git it's not there.
Paul?
--
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
way.
Would you also consider Tair Sabirgaliev's v2 patch for not launching
gitk in the background on Mac? This fixes a very serious usability
problem.
<http://permalink.gmane.org/gmane.comp.version-control.git/43>
Thanks,
Stefan
--
Stefan Haller
Berlin, Germany
http://www.hal
of the startup sequence are actually seen by the user.
Signed-off-by: Stefan Haller
---
git-gui.sh | 13 +
1 file changed, 13 insertions(+)
diff --git a/git-gui.sh b/git-gui.sh
index e11..c464928 100755
--- a/git-gui.sh
+++ b/git-gui.sh
@@ -29,6 +29,19 @@ Foundation, Inc., 59
Pat Thoyts wrote:
> On 6 June 2013 09:17, Stefan Haller wrote:
> > +## On Mac, bring the current Wish process window to front
> > +
> > +if {[tk windowingsystem] eq "aqua"} {
> > + exec osascript -e [format {
> > +
of the startup sequence are actually seen by the user.
Signed-off-by: Stefan Haller
---
Changes since the first patch:
- add catch
- specify full path to /usr/bin/osascript
git-gui.sh | 15 +++
1 file changed, 15 insertions(+)
diff --git a/git-gui.sh b/git-gui.sh
index e11
Junio C Hamano wrote:
> Stefan (as your name appears in 76bf6ff93e, I am assuming that you
> were the OSX-osascript guru in that commit) could you keep an eye on
> the list traffic to see if users of latest gitk have issues with
> that change, please?
Sure, will do.
--
Stefan H
bring our process to the front. One way to achieve this would be:
if {[tk windowingsystem] eq "aqua"} {
exec osascript -e [format {
tell application "System Events"
set frontmost of processes whose unix id is %d to true
end tell
} [pid] ]
}
(Not sure a
they have to do is scroll the diff pane.
Signed-off-by: Stefan Haller
---
gitk | 27 ---
1 file changed, 16 insertions(+), 11 deletions(-)
diff --git a/gitk b/gitk
index d93bd99..9e3ec71 100755
--- a/gitk
+++ b/gitk
@@ -7947,10 +7947,9 @@ proc changediffdisp {} {
$
they have to do is scroll the diff pane.
Signed-off-by: Stefan Haller
---
The only change from v1 is the addition of the "$difffilestart eq {}"
condition, this should fix the flickering problem reported by Peter.
I didn't do anything about the search problem yet, will look into th
all to scrolltext; a bit ugly, but does
the job.
Signed-off-by: Stefan Haller
---
Here's one way how to address your concern. When pressing the search button
it will highlight the file that contains the current search hit; if you then
scroll from there though, the normal mechanism kicks in
: Stefan Haller
---
gitk | 26 +++---
1 file changed, 23 insertions(+), 3 deletions(-)
diff --git a/gitk b/gitk
index 16832a9..e2c0f1c 100755
--- a/gitk
+++ b/gitk
@@ -2361,6 +2361,7 @@ proc makewindow {} {
$ctext tag conf mresult -font textfontbold
$ctext tag conf
When typing in the "Search" field, select the current search result (so
that it gets highlighted in orange). This makes it easier to understand
what will happen if you then type Ctrl-S.
Signed-off-by: Stefan Haller
---
gitk | 5 -
1 file changed, 4 insertions(+), 1 deletion(-)
di
Here's something that has been bugging me for a long time: when using
the incremental search feature, it's hard to tell what happens when
clicking the Search button (or type Ctrl-S) repeatedly. It does have
the concept of a "current" search hit, and Ctrl-S advances to the next
one; however, you can
l/V-nW1JBq0eU>.
To work around this, we explicitly provide gray images for the disabled
state; I think this looks better than the default stipple effect that you
get on Windows as well, but that may be a matter of taste.
Signed-off-by: Stefan Haller
---
gitk | 17 +++--
1 file c
Paul Mackerras wrote:
> On Wed, Sep 19, 2012 at 08:17:27PM +0200, Stefan Haller wrote:
> > Here's one way how to address your concern. When pressing the search button
> > it will highlight the file that contains the current search hit; if you then
> > scroll fro
Sorry, I didn't realize that there is a display mode where the
list of files is empty, not even showing a "Comments" entry.
Here's a patch that fixes it, plus another patch that is only related
in so far as the bug that it fixes was introduced by the same commit.
[PATCH 1/2] gitk: Fix error messa
When clicking on the line that connects two commit nodes, gitk
would bring up an error dialog saying "can't read "cflist_top":
no such variable".
This fixes a regression that was introduced with b967135 ("gitk:
Synchronize highlighting in file view when scrolling
This fixes another regression that was introduced in b967135 ("gitk:
Synchronize highlighting in file view when scrolling diff"): when
searching for a string in tree mode, jumping to the next search hit
would highlight the "Comments" entry in the file list.
Signed-off-by: Stef
idx ne $ctext_last_scroll_pos} {
if {![info exists suppress_highlighting_file_for_this_scrollpos]
|| $topidx ne $suppress_highlighting_file_for_this_scrollpos} {
highlightfile_for_scrollpos $topidx
}
set ctext_last_scroll_pos $topidx
}
-Stefan
ld not introduce such
> options.
I would use it.
--
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
53 matches
Mail list logo
