Quoth Paul Lalonde <[email protected]>:
> Ah, yes, my dev history involves git in very large repos with too many
> committers. The probability that you won't have to rebase to catch up to
> main was approximately zero, so that just becomes part of the workflow. If
> you're the only person working in a section of the tree then it's trivial
> and just runs automatically.
>
> You may well have fixed it. I realized that I hadn't done an update after
> installing this cpu/disk server, so did that. I'll report if I run into
> the grief again.
>
> Also, is there a reason why git/rebase -i doesn't have a "drop" option? I
> use it frequently when I find myself with a duplicate change from messing
> up my github fork synchronizations.
>
here's a quick diff I haven't yet tested for implementing drop -- let me know
if it does the job for you:
diff 2339cfc51541b3f62a7a92d67885b1918f8570c1 uncommitted
--- a/sys/src/cmd/git/rebase
+++ b/sys/src/cmd/git/rebase
@@ -59,6 +59,8 @@
echo $item
c=$item(2)
switch($item(1)){
+ case d drop
+ # nothing to do
case p pick
git/export $c | git/import
case r reword
------------------------------------------
9fans: 9fans
Permalink:
https://9fans.topicbox.com/groups/9fans/Tc30944502958e1a0-Mda165161b1e8700d788c4fac
Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
